Rendering order buildings / roads / highway-area #172
Comments
The layer order used to be as follows. (bridges) B I classified all layers between and including the bridge-layers and the tunnels-layer with one of the following classifications: B Bridge level. R/B Above roads but below bridges. R Road level. T/R Above tunnels but below roads. T Tunnel level. I grouped all of the layers within one class together, without changing the order within the classes. For now, I ignored the buildings-layers, due to the difficulties with ordering buildings, highways and highway-areas described in gravitystorm#172. This change causes a couple of changes in the rendering, which mainly occur in rare cases. - Casings of turning circles are now drawn above foot/bike/track tunnels (they were already drawn above other tunnels), and above cliffs and barriers (just like other roads are drawn above cliffs and barriers). - Landuse-overlays (i.e., military and national park), castlewalls, and citywalls are now drawn above foot/bike/track tunnels (they were already drawn above other tunnels). - Ferry-routes are now drawn below roads (highways, tracks, turning-circles, and highway-areas). - Railways on level 12 (due to the #roads-low-zoom layer), aerialways, and waterway-bridges are now drawn above access and directions markers of roads (they were already drawn above the roads themselves).
The layer order used to be as follows. (bridges) B direction-pre-bridges.directions R access-pre-bridges.access R waterway-bridges R/B roads-low-zoom R/B aerialways R/B ferry-routes T/R turning-circle-fill R roads-fill R tracks-notunnel-nobridge R buildings ??? buildings-lz ??? highway-area-fill R roads-casing R highway-area-casing R area-barriers.barriers T/R cliffs T/R line-barriers.barriers T/R tracks-tunnels T footbikecycle-tunnels T turning-circle-casing R landuse-overlay T/R castlewalls-poly.castlewalls T/R castlewalls.castlewalls T/R citywalls T/R tunnels T I classified all layers between and including the bridge-layers and the tunnels-layer with one of the following classifications: B Bridge level. R/B Above roads but below bridges. R Road level. T/R Above tunnels but below roads. T Tunnel level. I grouped all of the layers within one class together, without changing the order within the classes. For now, I ignored the buildings-layers, due to the difficulties with ordering buildings, highways and highway-areas described in gravitystorm#172. This change causes a couple of changes in the rendering, which mainly occur in rare cases. - Casings of turning circles are now drawn above foot/bike/track tunnels (they were already drawn above other tunnels), and above cliffs and barriers (just like other roads are drawn above cliffs and barriers). - Landuse-overlays (i.e., military and national park), castlewalls, and citywalls are now drawn above foot/bike/track tunnels (they were already drawn above other tunnels). - Ferry-routes are now drawn below roads (highways, tracks, turning-circles, and highway-areas). - Railways on level 12 (due to the #roads-low-zoom layer), aerialways, and waterway-bridges are now drawn above access and directions markers of roads (they were already drawn above the roads themselves).
|
2013/9/17 math1985 [email protected]
IMHO a problem in our data model, this is something that bothered me for a |
|
This is step II of #162. |
|
@gravitystorm @pnorman Do you have an opinion on this issue? |
This is necessary from a routing perspective too. I'm trying to tackle buildings too, and running into issues in downtown Seattle That being said, I'd like to keep buildings above areas and roads above buildings, so I think we're stuck with the current option for that. I have tried changing the colour, and didn't find the gaps to be a particular issue. |
|
Similar intersection query as in #565 for place_of_worship may solve the 3 inequalities - if buildings intersecting highway areas are identified, the rendering order could be: |
Tunnels under buildings are currently hard to see, because buildings are only partially transparent. Removal of the transparency, such as in gravitystorm#565, would even cause tunnels under buildings to become invisible. Because tunnels are dashed, it is still clear that they are tunnels. This solves gravitystorm#172. This change has a couple of side effects: - Buildings are now rendered behind highway-areas. This is an issue with areas with buildings in the middle. They might not all have correctly been tagged as multipolygon. Areas with buildings in the middle that are not tagged as multipolygon need to be retagged, and as long as they are not retagged, the houses will be hidden. Note that retagging would in any case be an improvement, as the building is not part of the area, and retagging is needed for routing (the building cannot be crossed for routing purposes). - Buildings are now rendered behind citywalls, castlewalls, castlewalls-poly, cliffs, area-barriers, and tree-rows. This is probably a slight improvement. - Buildings are now also rendered behind landuse-overlay (currently only military), which is not ideal, but probable acceptable. If this is a problem, we can push landuse-overlay further down, below tunnels. - Buildings are now also rendered behind ferry-routes, which probably does not occur often. - Buildings are now rendered behind roads-casing and turning-circle-casing, which is an improvement as buildings are already rendered behind roads-fill and turning-circle-fill.
|
what would be the current status of this issue? |
|
The status of this issue is that is is closed after the objectives were - as far as it is possible in the framework we use - accomplished. The fundamental issue of layering of road polygons still exists of course, manifested in various forms like: And we have discussed various possibilities of changing things in light of these: None of these, however, will resolve the fundamental problem that
Solving this is hard to do in our current technical framework because it would require either
We have not definitely given up on improving the style on this front (hence the last two issues linked to above are open) but there is no clear perspective or consensus so far how to do that. |
|
Hi, Sorry, it's not clear. Why can't you downgrade "area=yes, highway=pedestrian" and "area=yes, highway=footpath" to level of "amenity=parking"? This will solve the issue/ |
|
@Sirorezka that would violate constraint 3, which means the road casings will appear on top of the pedestrian areas. Example rendering |
|
Sorry, what do you mean by 'road casings'? Tunnels or "end of lines rounds?" In case of tunnels it is very much ok to see tunnels if they underneath pedestrian area. In case of end of way rounds - I would say that you don't see often roads that clash directly in pedestrian area. And having this small clashes is much better than not rendering anything on pedestrian area. |
Casings are the dark outlines around roads - for example visible at round lines at the end of lines.
I'd expect you have such roads for most pedestrian areas. To me these clashes look quite bad, but that's a choice for the maintainers to make. |
I am not sure what is the best rendering order for buildings, roads, and highway-areas, and would like your input.
In terms of rendering order, it seems to make sense to have the following three requirements:
Buildings should be rendered above highway-areas. If buildings are rendered lower than highway-areas, then buildings in the middle of a square become invisible. For example, the kiosk in the middle of this square would not be rendered.
Buildings should be rendered below roads. If buildings are rendered higher than roads, then roads are difficult to see in dense built-up areas, as can be seen here. Alternatively, buildings can be rendered below the fill of roads, but above the casing of roads. This leads, however, to gaps in the casing of roads, as can be seen in this example, where the casing is made a bit wider and given a red colour.
Highway-areas should be rendered above roads (at least above their casings). When highway-areas are rendered below the casing of road, the places where a road runs in an area become ugly.
Unfortunately, requirements 1, 2, and 3 are not compatible.
Violating 1. is an option, but is undesirable as it would require large-scale re-tagging. All the highway-areas with a building in the middle to be tagged should be tagged as multipolygons if we decide to violate this requirement.
Violating 2., in the version where buildings are rendered below the fill but above the casing of roads, is currently used. In the current style, the gaps in the road casing are not a major problem because buildings and road casings have a visually similar colour. However, if someone decides to adapt the colours, this might become a problem.
The version where buildings are also rendered above the casing of roads seems no option for a map that is meant to focus on roads.
Violating 3. seems not an option, because of the ugly rendering.
Or are there any ideas to avoid this problem altogether?
The text was updated successfully, but these errors were encountered: