Consistent road widths on all zoom levels

[Rovastar]

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]

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]

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]

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]

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]

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]

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]

2013/11/18 vincentdephily notifications@github.com

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]

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]

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]

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]

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]

2013/11/18 Rovastar notifications@github.com

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]

2013/11/18 Martin Koppenhoefer dieterdreist@gmail.com

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]

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]

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]

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]

2013/11/18 cquest notifications@github.com

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]

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]

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]

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]

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]

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]

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

[JohnBakerRI]

@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]

@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]

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]

2014-05-23 2:46 GMT+02:00 math1985 notifications@github.com:

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]

"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]

Closed by #571.

[Rovastar]

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]

What does still need fixing? Did I miss something?

[thor]

@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.