Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consistent road widths on all zoom levels #265

Closed
Rovastar opened this issue Nov 14, 2013 · 32 comments
Closed

Consistent road widths on all zoom levels #265

Rovastar opened this issue Nov 14, 2013 · 32 comments
Labels

Comments

@Rovastar
Copy link
Contributor

One of my biggest annoyances of the OSM carto style is the lack of roads widths correctly rendered. So we have the same road widths for a motorway for levels 17,18 and 19.

I have been looking at adding all these and noticed a few anomalies.

Here are a few highlights.


@motorway-width-z12: 2; // shouldn't be narrower than trunk!

@trunk-width-z12: 2.5; // shouldn't be same as primary

@primary-width-z12: 2.5;

@secondary-width-z12: 2;

@motorway-width-z13: 5; // shouldn't be narrower than trunk!

@trunk-width-z13: 7; // shouldn't be narrower than secondary

@primary-width-z13: 7; // shouldn't be narrower than secondary

@secondary-width-z13: 8;

@tertiary-width-z13: 4.5;

@residential-width-z13: 2;

@tertiary-width-z14: 6;

@residential-width-z14: 3;

@motorway-width-z15: 8.5; // shouldn't be narrower than trunk!

@trunk-width-z15: 11; // shouldn't be same as primary

@primary-width-z15: 11; // shouldn't be same as secondary

@secondary-width-z15: 11;

@tertiary-width-z15: 9.4;

@residential-width-z15: 6.5;

@residential-width-z16: 9.4;

@motorway-width-z17: 11; // shouldn't be narrower than trunk!

@trunk-width-z17: 15.5; // shouldn't be same as primary

@primary-width-z17: 15.5; // shouldn't be same as secondary

@secondary-width-z17: 15.5;

@tertiary-width-z17: 13; // shouldn't be same as residential

@residential-width-z17: 13;

motorway zoom 9 = 1.4
trunk zoom 9 = 2


There are loads more some when you include he casing offset and probably more with brides,tunnels, etc.

I have started a spreadsheet

https://skydrive.live.com/redir?resid=A59A1247F72580DF!141&authkey=!AE02QYDyFPwP0PM

Really we need to get all roads defined for all zoom levels and never have a more senior type of road drawn thicker than a junior type of road. Or even the same size.

So to do

Get a complete list of all the road types and styles in a sheetsheet
Define explicit widths for each zoom level
Change the sizes of the road widths, cases, etc so they are in a width to importance of road ratio hierarchy
(then once I have done all that I am going to try to get my wok on lanes included ;-) )

@matthijsmelissen
Copy link
Collaborator

Yes, I also noticed that.

I'm currently reworking the entire roads layer. After I have finished with that, differences in road width will be much easier to spot, and corrections can be made easier, especially considering bridges and tunnels etc. It might save time to wait with looking at the road widths until I have send a pull request for the rework of the road layer.

I'm not sure if more senior roads always should be drawn thicker, by the way. Some colors attract more attention than others, and perhaps roads in that color can be drawn thinner while still being visually more prominent. Not sure if that's the case, just saying that we shouldn't blindly accept the principle that more senior roads should be drawn thicker without testing how it looks like.

@Rovastar
Copy link
Contributor Author

Ok if you are working on the roads.css I can hold fire a little.

I have linked to the speadsheet now.

https://skydrive.live.com/redir?resid=A59A1247F72580DF!141&authkey=!AE02QYDyFPwP0PM

I disagree with the widths for more senior roads could in some cases be thinner than the junior roads because if they are senior then they should be more prominent. Also it will be more simple to logically understand and implement and colours could in theory change. They are all at the moment constants in the CSS so they can be change easily for other styles.

@matthijsmelissen
Copy link
Collaborator

Thanks for the link! What does 'default lanes' mean?

I agree that letting road width depend on color makes changing colors much harder, so perhaps we should indeed avoid that. Still, I think we should make sure that road widths are not only 'logically understandable', but also look nice :).

@Rovastar
Copy link
Contributor Author

ah I agree part of the carto style is to make things look nice as well as understandable. :)

Ah "Default lanes" is my definition of how many lanes they will have by default. Really it is only motorways that I have changed from the default and I would class this as 3 lanes. I need to look more at primary and trunk links roads they might be 1.

It is to assess the width of the roads easily and make sensible decisions (together with the importance) for the width of the line in carto.

Really it is part of my next enhancement the renderer so the roads so they have realistic widths.
An eight lane motorway should probably be more prominent that a 2 lane motorway (or 1 lane motorway link). More people use it, it is more "important", it likely deserves more of the map, mostly this is for higher level stuff so they fit more realistically with the other features like the building, etc.

And we have the data (3.5 million tags for lanes) I thought we could actually use it. :)

I have done a proof of concept but really much more work needs to be done of the road.css

@Rovastar
Copy link
Contributor Author

Updated the spreadsheet to include tunnels and bridges. There is a bit of work to do there too, some are wider than the normal roads, some narrower, some don't display at all on certain zoom levels when the normal roads do. I need to give some thoughts and experimentation over the weekend.

Just need to add primary link, secondary link and tertiary link roads to the list.

@vincentdephily
Copy link

This may be a bit offtopic and deserve a dedicated issue, but at high zoom levels it would be great to have roads rendered using their tagged width. In other words, whatever the zoom level, if a road has width=10 and the current zoom renders 5 pixels per meter, the road should be 50 pixels wide.

@dieterdreist
Copy link

2013/11/18 vincentdephily [email protected]

This may be a bit offtopic and deserve a dedicated issue, but at high zoom
levels it would be great to have roads rendered using their tagged width.
In other words, whatever the zoom level, if a road has width=10 and the
current zoom renders 5 pixels per meter, the road should be 50 pixels wide.

in order to do the conversion meters to pixels right, you would have to
take latitude into account in EPSG:3857

@matthijsmelissen
Copy link
Collaborator

That's not that easy to implement, because the number of pixels per meter is smaller (or larger? I always forget) near the equator than towards the piles.

@Rovastar
Copy link
Contributor Author

Yeah I have thought about width but I think this should come after I do lanes. As with have more roads with lanes info rather than width and it is easier for a mapper to give the amount of lanes rather than the width.

Regarding the conversion system to be done perfectly yes (although not looked into in any detail) you would need to do that (but the overhead would be huge IMHO a load of CPU math heavy operations to do this)

However remember at the moment we do nothing and all road no matter where in the world have a set pixel width.
Adding width no matter where in the world would (likely/often) improve it to be more realistic size even if we didn't do any formula conversions to it.

@vincentdephily
Copy link

I thought that mapnik handled the projection issues automatically ? JOSM has paint styles that implement that (and more). I never verified that it got the projection correct, but it looks fine.

@matthijsmelissen
Copy link
Collaborator

What do you mean exactly with 'handle the projection issues automatically'?
On a given zoom level, 10px is rendered as 10px everywhere on the planet. Therefore, 10px does not correspond to the same amount of meters everywhere.

@dieterdreist
Copy link

2013/11/18 Rovastar [email protected]

Regarding the conversion system to be done perfectly yes you would need to
do that (but the overhead would be huge IMHO a load of CPU math heavy
operations to do this)

if you did it perfectly yes, this would probably be a lot of overhead, but
my guess is, you could do something basic and sufficiently well with some
few simple precalculated factors like
lat -20 - 20 = 1
lat -30 - -20 or lat 20-30 = 1+x
....

cheers,
Martin

@dieterdreist
Copy link

2013/11/18 Martin Koppenhoefer [email protected]

if you did it perfectly yes, this would probably be a lot of overhead, but
my guess is, you could do something basic and sufficiently well with some
few simple precalculated factors

if the single elements aren't spanning very wide and if you don't mind some
inconsistencies at the borders from one lat-group to the next of course ;-)

@vincentdephily
Copy link

What do you mean exactly with 'handle the projection issues automatically'?
On a given zoom level, 10px is rendered as 10px everywhere on the planet. Therefore, 10px does not correspond to the same amount of meters everywhere.

Since mapnik handles projection for lat/lon values, I imagined that you could give the width in a real-life unit (degrees, or even meters) and that mapnik would translate this to pixels, after the projection pass.

But maybe mapnik only accepts line widths in pixels (what's the unit for svg ?). If so, supporting exact width rendinging in the style would be very cumbersome indeed. Sorry for my poor knowledge of the tools.

@cquest
Copy link

cquest commented Nov 18, 2013

I did some rendering test of lanes=* and width=* tags.

Exact width in meter was not the main problem.

The problem I faced was how to draw a clean transition between a way with lanes=3 and the next one with lanes=2

The result was looking very bad and the solution I imagine was to generate fake "joint" geometries at postgis level to have clean transitions. Of course this is not obvious and will lead to a lot of pre-processing.

Don't forget the !pixel_width! and !pixel_height! that may be used at postgis level to deal with exact pixel size.

@Rovastar
Copy link
Contributor Author

HI Christian,

The shrinkage of lanes is a bit of an issue. I am aware of that. I suppose I am balancing it out with the current "issue" (even though we are completely complacent with it) where we no do reflect of how large the lanes are and cases like merging three 2 lane roads into 1 single 6 lane one makes it look the same size.

I am curious did your experiments look any worse than what we have now where a more "senior" road has a transition into a more "junior" road. Like, for example, when a trunk road has a transition into a unclassified road? Or residential into a service road?
Or is it the casing rounding issue you had issues with?

It might need some more thought. However it is a goal I think can be achieved.

@dieterdreist
Copy link

2013/11/18 cquest [email protected]

The result was looking very bad and the solution I imagine was to generate
fake "joint" geometries at postgis level to have clean transitions. Of
course this is not obvious and will lead to a lot of pre-processing.

for a perfect result those lane-transitions should be mapped according to
the real world situation. Currently we have no tags or scheme for this, it
is also a problem for waterways. We could have tags to describe a smooth
transition of an attribute between two nodes (maybe even others than
"linear", different transition functions), or a tag to say: "this way is
smoothly curved in reality" or "this way is really angular".

@mrwojo
Copy link
Contributor

mrwojo commented Nov 18, 2013

Inconsistencies were also mentioned in January 2012 with the old Mapnik style. A reply noted that motorways are thinner probably because they're usually side-by-side.

#180 is a related issue for rendering the actual highway extent with the area:highway tag.

@Rovastar
Copy link
Contributor Author

Thanks that was a useful diagram. I hadn't seen that before.

I am not sure I buy the reasons fro the motorways being smaller than the other roads as they can be dual roads too. But it is nice to know someone thought about it at least initially.

@matthijsmelissen
Copy link
Collaborator

I'm working on this issue now.

The first step will be to have the widths of bridges and tunnels correspond automatically to the widths of regular roads of the same type and zoomlevel.

@Rovastar You say that two highway types subsequent in importance, like trunk and primary, should not have the same width. I'm not sure if I agree with that. Why should all highway types have a different width?

@sb12
Copy link
Contributor

sb12 commented Mar 26, 2014

Actually I like the current rendering of motorways at least on the higher zoom levels (>= 15), because motorways are one-way roads in most cases and therefore it's easier to distinguish between the two separated roadways when they are rendered smaller. At least in Germany this also applies to most of the trunk roads and some primary and secondary roads.
I prefer if we can differ, whether a road is oneway or not and then draw all oneway roads a little bit smaller than two-way roads. I also prefer to render trunk_link, primary_link, secondary_link and tertiary_link a bit smaller, similar to motorway_link.
This could make large crossings and intersections as well as one lane dual carriageways look more tidy. It also has a quality assurance advantage as roads with missing oneway tags or inconsistent links can be found easier.

For smaller zoom levels and two-way roads I agree that more important roads should not be rendered smaller than less important roads, though I do not have a problem with primary and trunk being rendered the same size.

A side note about trunk: There's a difference between trunk roads in the UK and e.g. Germany. In the UK all important A-Roads are tagged as trunk independent of the actual road layout, while in Germany trunk is only used for dual carriageways.

@vincentdephily
Copy link

Any hope of rendering the actual tagged width of the road when the zoom is high enough ? The josm paint styles "Lane and road attributes" is an example implementation, althoug we probably don't want to do somthing that complex yet.

@matthijsmelissen
Copy link
Collaborator

That would be nice to have, but it is outside of the scope of my current plans.

@JohnBakerRI
Copy link

@math1985

"@Rovastar You say that two highway types subsequent in importance, like trunk and primary, should not have the same width. I'm not sure if I agree with that. Why should all highway types have a different width?"

Well the main thing is they are not thicker/more prominent. Logically they should be smaller were pos IMHO. Motorways are wider than residential as a rule and in general and as you go down the scale they should get thinner. I mean you could have trunk and primary the same size but you should have secondary wider than trunk for example. In all countries (it should be) that the ordering of classification reflects the importance.

Link roads should be smaller too then there respective type as they imply smaller and often one-way.

Ideally we should look at one way tag too to represent different widths. It is a crying shame there is no proper logic in the CSS style. If variables acted like variables and not constants then you could have a nice formula for all this (I initially did one but could not implement it). One line for all zoom levels for each way classification but I digress.

Lanes and width would be nice but there could be problems there. Mainly going from big to small width but that is discussed else where about lanes (even more problematic with widths...).

I have thought about most of these issues before but not fleshed them out in this topic as I hadn't had much time to do anything on this.
:(

@Rovastar
Copy link
Contributor Author

@math1985

"@Rovastar You say that two highway types subsequent in importance, like trunk and primary, should not have the same width. I'm not sure if I agree with that. Why should all highway types have a different width?"

Well the main thing is they are not thicker/more prominent. Logically they should be smaller were pos IMHO. Motorways are wider than residential as a rule and in general and as you go down the scale they should get thinner. I mean you could have trunk and primary the same size but you should have secondary wider than trunk for example. In all countries (it should be) that the ordering of classification reflects the importance.

Link roads should be smaller too then there respective type as they imply smaller and often one-way.

Ideally we should look at one way tag too to represent different widths. It is a crying shame there is no proper logic in the CSS style. If variables acted like variables and not constants then you could have a nice formula for all this (I initially did one but could not implement it). One line for all zoom levels for each way classification but I digress.

Lanes and width would be nice but there could be problems there. Mainly going from big to small width but that is discussed else where about lanes (even more problematic with widths...).

I have thought about most of these issues before but not fleshed them out in this topic as I hadn't had much time to do anything on this.
:(

FFS logged in with the wrong account ....stupid work account...grumble, grumble..

matthijsmelissen added a commit to matthijsmelissen/openstreetmap-carto that referenced this issue Mar 28, 2014
There is currently not much logic behind the width of bridges and
tunnels. This commit gives bridges and tunnels consistent widths.

Changing the widths of regular roads, i.e. roads that are not in a
tunnel or on a bridge, is out of the scope of this commit, and will be
dealt with later. Highways other than motorway, trunk, primary,
secondary, tertiary, residential/unclassified and their links are also
out of scope.

The width of bridges and tunnels after this commit is either inherited
from, or defined in terms of the width of regular roads. This will make
the widths of tunnels and bridges easier to maintain.

The widths have been changed based on the following three principles.

1. Make the casing of bridges just as wide as the casing of regular
   roads.
   > Currently, the casing of bridges is a mess. Some bridges are
     narrower than regular roads, up to 1.8 pixel (trunk and primary
     roads on z15/z16). On the other hand, motorway links are 1.5 pixel
     wider on bridges on z12. There are also all kinds of cases in
     between.
     When the casing of bridges is narrower than the casing of regular
     roads, itwith too much of the background, especially when two roads
     run closely in parallel. Therefore, I have chosen to make the casing
     of bridges and regular roads equal.

2. Make the diffence between bridgecasing and bridgefill, i.e. the black
   outline of bridges, per zoomlevel the same for all road types.
   > Currently the black outline of bridges (casing minus fill) is
     thicker for some roads (z13: tertiary roads; z14: tertiary roads
     and tertiary link roads; z17: motorway roads, motorway links,
     residential/unclassified roads) compared to other roads on the same
     zomolevel. This is because they have a bit smaller bridgefill, and
     thus a larger black outline, compared to the other roads.
     The black outline (casing minus fill) should be a bit narrower than
     the regular outline, because the black stands out much more out
     than the regular casing which blends in with the fill of the road.
     As we keep bridges and regular roads the same width, consequently
     the fill on bridges needs to be a bit wider than the fill on
     regular roads.

3. Keep the casing and fill of tunnels the same as the casing and fill
   of regular roads.
   > Again there are currently large and inconsistent differences. Trunk
     and primary on z17 and larger are even 4 pixels narrower in tunnels.
     On the other hand, tertiary on z17 and larger are 0.5 pixel wider
     in tunnels. I see no reason to give tunnels a different width.
     Therefore, I have made tunnels equally wide as regular roads.

As the new definitions keep the casing constant, rather than the fill,
the most basic definition is now the width of the casing of roads,
instead the width of the fill. All other widths are now derived from
that.

This commit solves 3834 on trac and part of gravitystorm#265 on Github.
matthijsmelissen added a commit to matthijsmelissen/openstreetmap-carto that referenced this issue Apr 9, 2014
Render oneway roads narrower than twoway roads for the types motorway, trunk, primary, secondary and tertiary.
This is accomplished by making twoway motorways wider and oneway trunk/primary/secondary/tertiary roads narrower.
More important road types are now always rendered wider than less important road types.

Changes:
- Twoway motorways are rendered wider
- Oneway trunk/primary/secondary/tertiary roads are rendered narrower
- Secondary is now narrower on z13/z14
- Tertiary_link is now rendered just like tertiary
- Round line caps on tertiary and larger are removed on regular roads to prevent gravitystorm#83
All other road types are rendered as before.

Further changes to the width of link roads are left for a future pull request.

I tried to achieve the goal of making more important road types wider than less important ones while at the same time making as little changes to the roadsizes as possible. I think it would be worth for if someone with feeling for design has a closer look at the sizes as we have them now. It should be very easy to adapt now: one can just change the variables in the beginning of the style.

I put the road sizes in a kind of table to make them more legible. If people think that's not practical, I can change it back to a list again.

This pull request resolves gravitystorm#265 and gravitystorm#83 on Github and 1952 on trac.
@matthijsmelissen
Copy link
Collaborator

The proposal to render oneway roads smaller has been rejected. We cannot in general assume that motorways are oneway and trunks bidirectional. I will therefore proceed to make motorways (which are currently too narrow) wider, and trunks narrower.

@dieterdreist
Copy link

2014-05-23 2:46 GMT+02:00 math1985 [email protected]:

We cannot in general assume that motorways are oneway and trunks
bidirectional.

indeed according to the tagging rules in Italy and Germany a highway has to
be grade separated (and not a motorway) in order to become trunk, so at
least there all or most trunks are oneways.

@matkoniecz
Copy link
Contributor

"We cannot in general assume that motorways are oneway"

Developers of iD editor consider that there is "assumed default of oneway=yes on things like junction=roundabout and highway=motorway"

See openstreetmap/iD#2220

See https://github.com/bhousel/iD/blob/master/js/id/core/oneway_tags.js for set of tags that according to iD editor implies onewayness.

@matthijsmelissen
Copy link
Collaborator

Closed by #571.

@Rovastar
Copy link
Contributor Author

This issue road widths for all classifications for all zoom levels. But another can be opened for that now.
get start to getting this fixed.

@matthijsmelissen
Copy link
Collaborator

What does still need fixing? Did I miss something?

@thor
Copy link

thor commented Oct 25, 2014

@math1985 I believe @Rovastar could be referring to rendering the width of the road as defined by key:width.

Regarding that, the width of the road wouldn't need to be extremely accurate - but an estimate width rendering based on the key:width would be better than shrinking the size relative to the zoom level, as it creates odd things where you have a highway:service with area:yes going towards a highway:* that isn't area:yes, but simply a way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants