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

Variable width line features at high zooms #1290

Closed
imagico opened this issue Feb 4, 2015 · 14 comments
Closed

Variable width line features at high zooms #1290

imagico opened this issue Feb 4, 2015 · 14 comments

Comments

@imagico
Copy link
Collaborator

imagico commented Feb 4, 2015

Linear features that are rendered with varying width at different zoom levels, most notably highways and aeroways but also a few other things like man_made=cutline are currently usually rendered significantly thinner than their real size at the highest zooms (18/19).

At low zooms such features are of course rendered wider than their natural width to make them clearly visible and the width on screen is increased slowly with zoom levels with the break-even-point (i.e. where the shown width matches the real width) usually around z=14-16 for aeroway=runway and around 16-18 for roads depending on latitude and individual situation.

The question is if it makes sense to adjust the width for high zooms to make sure the shown width is not significantly less than the real width. IMO this would have the following advantages:

  • more intuitive rendering results at high zooms with better sense of the scale.
  • discouraging the trend to map everything as areas which has serious disadvantages since directionality of features is lost.

The key problem is to make a realistic assessment of the width of those features since this is rarely tagged. For aeroway=runway this is relatively easy, a simple formula based on the runway length would be quite an accurate estimate, like min(max(length/50,8),80). For highways this is more difficult since a primary road in a dense urban centre will be significantly less wide than in rural areas but a lower limit should be possible to specify and this would still be relevant in a lot of cases at z=18/19.

In addition for highways it might be a good idea to limit the increase in width at z=14+ in comparison to z=13 in cases where the would-be width on the ground is significantly larger (like 2-3 times) than the estimated actual with of this type of road. The effect would be that in low latitude regions the width of roads at z=14+ would be smaller than at high latitudes and this would avoid situations like here.

Note this is only suggested for features that are already shown with variable width right now. Things drawn with a fixed width line signature independent of the zoom level like highway=track are a different matter.

@mboeringa
Copy link

In addition for highways it might be a good idea to limit the increase in width at z=14+ in comparison to z=13 in cases where the would-be width on the ground is significantly larger (like 2-3 times) than the estimated actual with of this type of road. The effect would be that in low latitude regions the width of roads at z=14+ would be smaller than at high latitudes and this would avoid situations like here.

I guess you mean to illustrate that the relative width and density of highways compared to other features in a rendered tile increases at lower latitudes, and the potential density of highways decreases at higher latitudes as a consequence of 1) the default projection (Web Mercator) used by most webservices which has a strongly varying scale across latitudes, and 2) using a constant line width? (as is now the case, as pixel width is constant across latitudes, and lower latitude rendered tiles cover a much larger real world surface area than higher latitude ones in Web Mercator)

Or are you really suggesting implementing a varying line-width (in pixels) for highways depended on latitude?

@imagico
Copy link
Collaborator Author

imagico commented Feb 5, 2015

OK - i have probably been somewhat cryptic in my explanation, i will try to make it clearer:

Roads are currently drawn at a constant line width (in pixel) at each zoom level and this width increases slowly with increasing zoom level (from 13 until 17 - numbers here) leading to a decreasing width of the drawn line relative to the other features on the map like buildings (i.e. the width on the ground as it appears on the map). This leads to the roads being drawn less wide than they are in reality at the highest zoom levels. My suggestion is to make sure the line width is always large enough so the width of the road relative to the other elements is always at least the typical minimum width of a road of this class.

In addition due to the variable scale of the Mercator projection the width of the roads as drawn relative to the other features in the map is larger at low latitudes and smaller at high latitudes leading among other things to the effect i linked to, i.e. when the width the roads are drawn in exceeds the width of the city blocks between the roads the whole area is covered by roads and nothing is visible in between.

To counteract this i suggest to dampen the increase in line width (in pixel) with increasing zoom level in cases where the normal width would, relative to other features on the map, exceed the typical maximum width of a road of this class by a factor of 2-3.

Both suggestions would - when implemented - lead to varying line width (in pixel) at a certain zoom level depending on latitude. The first suggestion only at the highest zooms (mostly z>=17), the second also at the lower levels (z>=14).

@mboeringa
Copy link

To counteract this i suggest to dampen the increase in line width (in pixel) with increasing zoom level in cases where the normal width would, relative to other features on the map, exceed the typical maximum width of a road of this class by a factor of 2-3.

Both suggestions would - when implemented - lead to varying line width (in pixel) at a certain zoom level depending on latitude. The first suggestion only at the highest zooms (mostly z>=17), the second also at the lower levels (z>=14).

I understand and appreciate the problem you pose, what I still don't see is how the bold part would work.

Why would a change to the zoom levels' pixel width of highway classes, automatically lead to a "varying line width (in pixel) at a certain zoom level depending on _latitude_"?

I don't see the relation with latitude. If the road width is defined in pixel width or points, it wil stay the same regardless of latitude. Limiting the maximum width a road can have at a certain zoom level, by simply reducing the pixel width, _will_ of course ameliorate the issues with overlapping roads, but it doesn't make it latitude depended (if that is even desirable).

But I may still be misunderstanding your suggestion...

@kocio-pl
Copy link
Collaborator

kocio-pl commented Feb 5, 2015

I guess any automatic estimation can be wrong - I prefer micromapping of the highways, since they can be of variable width and geometry in real world and now we have good enough aerial/satellite imagery to do this right in many cases. In reality highways are more like a rivers (areas) than lines - it's only easier to draw them like this and the routing is quite happy with such a model.

@imagico
Copy link
Collaborator Author

imagico commented Feb 5, 2015

@mboeringa - i see - latitude dependency will not come automatically, it comes from limiting the drawing width to a certain range in meters on the ground which translates to a different width in pixels depending on latitude.

@kocio-pl - highways are completely different from rivers, they have a constant width by design (if they are well built of course). Mapping highways as polygons would have absolutely no gain in comparison to mapping as line and tagging the width.

But this is of course beside the point here - improving the rendering of highway lines would decrease the apparent need to map them differently but it would not hinder this in any way.

And yes, estimations of typical widths can be wrong - but it is no big deal if it is off by like 20 percent or so. And if a width tag exists this should of course be used instead.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Feb 5, 2015

Width is not the same all the time, of course - (turn) lanes appear and disappear, bus turnouts and traffic islands happen in some places, two (or more!) roads junctions can have arbitrary design and geometry... Sometimes it's even hard for me to just follow the middle line.

I fear of rendering road thicker than in reality - we would have the road over the buildings or footway/pedestrian. Or this proposition just has no such side effects?

@imagico
Copy link
Collaborator Author

imagico commented Feb 5, 2015

I fear of rendering road thicker than in reality - we would have the road over the buildings or footway/pedestrian. Or this proposition just has no such side effects?

This suggestion would not increase the rendered width except for the highest zooms where the rendered width is currently less than in reality.

@pnorman
Copy link
Collaborator

pnorman commented Feb 6, 2015

I would be against variable road with, or turning it into an expression.

I'd be okay with increasing road widths at high zooms, but not by a factor of two per zoom.

@pnorman
Copy link
Collaborator

pnorman commented Feb 6, 2015

And if a width tag exists this should of course be used instead

I believe we have rejected using the width tag to determine the width of rendered roads. I found #967 (comment) mentions the decision, but I can't find the original.

@imagico
Copy link
Collaborator Author

imagico commented Feb 6, 2015

I would be against variable road with, or turning it into an expression.

Any particular reason besides the additional complexity?

Are there alternative ideas how to solve the problem of too large/too small road widths?

I believe we have rejected using the width tag to determine the width of rendered roads.

If there has been such a decision this probably was against using the width directly (which is obviously not a good idea at lower zooms). What i am suggesting here is using it as bounds for the line width selection. The roads would never be drawn thinner than their current minimum width at z=13.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Feb 6, 2015

@imagico: I am still not sure enough that your proposition will not obscure anything outside the road - can you guarantee this situation won't occur or it's just your wild guess that it practically shouldn't happen?

It's always better if the road is thinner than in reality, because you can make an area to cover what's missing and you can't do the reverse. I still feel the right - and realistic by today standards - way to fix current shortcomings of road rendering at high zoom levels is to generally adopt scheme like this:

http://wiki.openstreetmap.org/wiki/Street_area

@imagico
Copy link
Collaborator Author

imagico commented Feb 6, 2015

By using a conservative estimate for the road width you can pretty much make sure the road is not drawn too wide. The priorities at the highest zooms would be:

  1. Make sure the road is not drawn wider than it is in reality
  2. Make sure the road is not drawn too much thinner than in reality

The net result would probably be that roads are typically drawn something like 20-30 percent thinner than they are in reality which would be a huge improvement compared to now - see for example:

http://www.openstreetmap.org/#map=19/-6.24665/106.87607
http://www.openstreetmap.org/#map=19/59.43925/17.92812

(notice the difference in map scale on the bottom left - you can't do this both right without variable width rendering)

http://wiki.openstreetmap.org/wiki/Street_area

No one seriously wants to map a hundred kilometers of road this way.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Feb 6, 2015

The priorities at the highest zooms would be:

  1. Make sure the road is not drawn wider than it is in reality
  2. Make sure the road is not drawn too much thinner than in reality

Hm, is there a way to really "make sure"? From what you said it will be just a global estimation. However if there will be enough examples to test it, I would not object to such a conservative take.

No one seriously wants to map a hundred kilometers of road this way.

"640K ought to be enough for anybody" would be the best reply here =} , but seriously speaking:

  1. In some key places (like big cities or complex junctions at motorways - your links show good examples of them) it's a no-brainer to use it. First of all - people would love to see the real geometry to recognize how the space is really organized (just look at this comparison: http://wiki.openstreetmap.org/wiki/Street_area#Possible_rendering_with_use_of_other_map_elements ).
  2. Why?

When Nupedia started nobody expected the poor-man dirty spin-off (namely Wikipedia =} ) will emerge at all and - cough! - it will be that huge and important for the whole planet. Similarly - when OSM started 11 years ago probably nobody (including the creator - see the project name =} ) expected it to be much more than road maps in UK. Yet, they are and both are still growing.

Now we have a lot of OSM contributors all around the world, many places are generally good represented on the map, lanes are tagged, we have even the trash bins, street lamps and trees in our database, buildings are drawn even in some remote places - so why not to get real with the roads? How hard it is to draw their outlines comparing to buildings complex, sometimes covered by the trees (from my experience with big city mapping - the first one is a piece of cake, no matter how many kilometers)?

@matthijsmelissen
Copy link
Collaborator

Closed as per #1853: I think we should try to keep the complexity of the stylesheet down. Therefore I'm not in favour of variable width rendering. It adds relatively a lot of complexity for a small gain. Perhaps something that supports this in Mapnik would be useful?

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

No branches or pull requests

6 participants