Open sb12 opened 10 years ago
2014-07-02 19:19 GMT+02:00 sb12 notifications@github.com:
Is this a wanted behaviour or an error?
it is desired for buildings, as something is either a highway area or a building (mappers should create a multipolygon to cut out the building), but it is a bug for roofs.
We will be removing the building transparency, and therefore this change was necessary.
In general it is desired behaviour, see #623 and https://lists.openstreetmap.org/pipermail/tagging/2014-June/018043.html.
But I agree the results for building=roof (first example) and platforms in buildings (second example) might be improved, so I think we can leave this issue open.
In general it is desired behaviour, see #623 and https://lists.openstreetmap.org/pipermail/tagging/2014-June/018043.html.
Thanks for the explanation, I somehow didn't find this commit.
as something is either a highway area or a building (mappers should create a multipolygon to cut out the building)
Not necessarily. Sometimes a building can cross over a highway area. Example: http://www.openstreetmap.org/#map=19/49.00904/8.40940 (Picture: http://presse.karlsruhe.de/db/stadtzeitung/gemeinderat_sorgenkind_kronenplatz/13073/sz13_11.jpg)
Same problem for arcades in regions that are mapped very detailed.
Maybe the layer or the covered tag could help with distinguishing between missing multipolygons and overlapping buildings/highways?
I thought again about this and found a simple solution to this issue:
What about having a second half transparent (opacity=0.3 or similar) building layer on top of the highway layer. Example rendering:
Note that this only works after removing transparency and adjusting the colors for the main building layer.
It looks nice but might make the map more complicated and less readable.
Nice idea, seems to be quite readable. But IMHO it would be probably better with transparency reduced a bit.
2014-07-03 9:43 GMT+02:00 Mateusz Konieczny notifications@github.com:
Nice idea, seems to be quite readable. But IMHO it would be probably better with transparency reduced a bit.
agree that this works nicely here, but it is still a hack and will not work for more complicated situations. Honoring the layer tag for buildings and highway-areas would resolve more universally the issue.
I agree for the consideration of the "layer"-Tag. Here is an example for this situation: http://osm.org/go/0GGmPABd5 The area partially reaches below the buildings which are standing on columns: (The photo shows a different part of the building but with the same architecture.)
EDIT: Original link to image (http://www.loaditup.de/821249-8u5ftpqg37.html) broken, replaced.
Thank you for the additional example.
I also gave similar example here: https://github.com/gravitystorm/openstreetmap-carto/issues/685#issuecomment-48529496
@dieterdreist a pedestrian area that is partly covered by a building is IMHO a valid situation (just as it would be if it was mapped as a way)
This also affects the Eiffel tower: http://www.openstreetmap.org/#map=17/48.85740/2.29346
Another partly overlapped building. This one is more covered than hidden. I'm pretty sure you can't use a multipolygon here.
And this is how it looks in real life.
@Circeus Maybe mapping pedestal as a separate building:part that would be inner part of multipolygon would slightly help. Unfortunately I found no usable data that would allow this.
FWIW I should mention I don't have local knowledge. I sort of randomly mapped the Plaza a few years ago (IIRC, because I was adding churches from Wikipedia NRHP articles in the area and the Plaza was a poorly tagged mess).
Even with this proposed change display of roof would be still really bad.
There are multiple issues here really.
One that keeps coming up is that on pedestrian streets/areas there are often buildings, walls, etc and none of these are rendered, often these pedestrian areas will contain notable/famous buildings/landmarks. (I am not sure people have mentioned they are mostly pedestrian areas this is an issue)
I would argue that the roof one over other highways (you know the ones with cars, etc) is a different issue and more of noticeable in even more micro-mapping scenarios.
Could we do something for pedestrian streets and render these differently? Thinking about a messy separate section for pedestrian streets in the project that will render before the buildings and all other highways done later and rendered as normal.
Eiffel Tower has been cleverly "hacked" (by not rendering part of the pedestrian area: http://www.openstreetmap.org/relation/4114062), but the problem still exists. Do we need to tweak everything affected or there are some plans to resolve such issues in a more clean and general way?
The Eiffel tower solution looks nice, but likely breaks routing across the square, so that's not a solution.
Now the building changes have been merged, we can start thinking about a change to the stylesheet that solves this issue.
So - are there any ideas how to change the stylesheet? I think it's getting serious after such a long time because such places (with complicated buildings/highways layers) are probably important.
IMHO we could start by rendering anything that is tagged covered=yes with 50% opacity. No need to change rendering order then. It might still look weird, but it should make it more clear what's going on.
Later, other changes may be smarter, like interpreting 3D-tags or the reative layers, or "location".
Could someone make a test renderings of it? I suggest Berlin Hauptbahnhof as a great example of complex multilevel building, but I'm also very interested in Dworzec Centralny in Warsaw (my hometown).
Is this building (http://www.openstreetmap.org/way/23691951) being under rather over a railway=platform layer/level=-3 the same problem or a different issue?
It is over the platform asn the building is on the surface and the platform is a subway platform with 2 moving stairways leading down.
It looks like the hack with render=no stopped working and Eiffel Tower is now broken too.
@gravitystorm Andy, so what about such important places? Do we still accept this class of problems as unavoidable cost of better showing the pedestrian areas (as we do it now) or maybe we should have kind of workaround for such exceptions?
"render=no" never had any effect on whatever something will be rendered.
So maybe that was something else - I just know that building was visible back then, but the problem is what in general should we do with such things?
Every time I see an amenity=fuel with a building=roof and layer=1 with service highways going over them I sigh inwardly. Now I even bothered to search for this issue to write this comment. A solution would be nice.
@malenki tag the service roads with covered=yes and they will look nicer.
Edit: i just added this "hint" to the English and German fuel wikipage
Edit: i just added this "hint" to the English and German fuel wikipage
No, not yet. This is undiscussed since layer=* is technically speaking enough. This is a shortcoming of the renderer. See #1710
covered is Status: Approved And it is not wrong from the data point of view. If it helps current rendering it is good to add it to the fuel documentation!
Please readd it (and access, as it prevent often shortcuts in routing)
I opened a topic on the talk page: https://wiki.openstreetmap.org/wiki/Talk:Key:covered#What_to_do_with_building.3Droof.3F
This is undiscussed since layer=* is technically speaking enough.
I think it is more appropriate to say that it is _theoretically_ speaking enough.
The technical implications of having to properly render buildings or other polygons over or under roads, or any other line feature, based on the layer=x tag, is far more complicated, and AFAIK, hasn't been really implemented in any renderer yet, except maybe those fully focusing on 3D, like F4Map...
I don't think this can be batted away on the basis of requiring layer=x, as the Effiel Tower (with layer=4) demonstrates:
I find the Eiffel Tower to be a major bug of a new policy (highways always on top of buildings) cartographically wise.
In case of the Eiffel Tower, the highway=pedestrian with covered=yes http://www.openstreetmap.org/way/308077768 should be rendered differently. Since transparency is evil, we could introduce another solid colour (darker?). Following this with all the other things that could be covered, we would need a lot of new colours!! Seems unlikely to be possible without conflicts with existing colours.
So what about @mboeringa s idea of a hatching / chessboard pattern of 100% solid colour? (He does it with roofs, can't find a link) In the "empty" areas between the solid colour, one will see the thing that is physically on top of the covered area. This way, one could see the pedestrian area and the Eiffel Tower at the same time. It may be a bit noisy visually, depending on the size of the pattern.
Interesting idea to test. I would like to see this example link very much.
I guess this is done in ArcGIS. Is it possible to do with osm-carto tools?
Yes, this was ArcGIS, but why wouldn't a simple fine cross-hatch be possible in carto? There are already single line (non-cross) hatches in use for danger areas and so...
The feature is as @daganzdaanda pointed out based on the building=roof tag, often employed at railway stations.
I was thinking rather about chessboard, because I haven't seen something like this on osm-carto yet. Hatching is obviously possible.
And I don't get the details how it could be done with Eiffel Tower?
And I don't get the details how it could be done with Eiffel Tower?
The pedestrian area under the tower is tagged correctly with "covered=yes". Because it's a "highway", we render it on top of the building. So my idea is to render the area with a crosshatch, so that the building will show through. That way, all highways can still be rendered on top of buildings, because we can make the parts that are "covered=yes" fake-transparent.
2016-02-18 19:00 GMT+01:00 mboeringa notifications@github.com:
Yes, this was ArcGIS, but why wouldn't a simple fine cross-hatch be possible?
AFAIK you can't currently do vector based hatches in mapnik, but have to use the PolygonPatternSymbolizerto do it.
If it works, a crosshatch might also be useful for showing that platforms are "covered" or underground though this will still be more complicated I guess...
AFAIK you can't currently do vector based hatches in mapnik, but have to use the PolygonPatternSymbolizerto do it.
I don't know if "hatch" is the right word to use in the context of mapnik and carto, but in ArcGIS, this is indeed a vector based 'polygon' symbol type, actually a "Line Fill Symbol" to be precise, and two of these stacked on top of each other to create the final cross-hatch polygon fill symbol. So you can't define a cross-hatch directly in ArcGIS, but use a multi-layer symbol instead.
There are following situations
Rendering buildings above highway areas would fix the first issue (at cost of hiding highway area), give unexpected results for the second case and mask data error in a third case. It may also cause buildings to cover linear highway=* objects.
@daganzdaanda, what I don't quite follow here is that 50%/50% cross-hatching stippling exists because the world wasn't able to do proper transparency and blending. And now that we have systems, tools, and file-formats that support proper transparency people are going out of their way to avoid using it.
For solving this we have metadata in the form of the layer= tag, and we have tools in the form of transparency and layering. What I'm unclear about is why everyone appears to be going out of their way to avoid using the two together.
we have tools in the form of transparency and layering. What I'm unclear about is why everyone appears to be going out of their way to avoid using the two together.
Because layering multiple transparent objects gives unclear, unpredictable and ugly results in at least some cases. See for example https://github.com/gravitystorm/openstreetmap-carto/pull/590#issuecomment-44815238 https://github.com/gravitystorm/openstreetmap-carto/pull/590#issuecomment-44787176 and https://github.com/gravitystorm/openstreetmap-carto/pull/792
Transparency has some uses like text halo but it works poorly for polygon fill.
I am not against the change in way layers are defined, but there is no reason to render it the same way is the layer of one object has higher positive value than the other one. That is the core meaning of the layer parameter anyway. I can not imagine any argument against this. What would be the meaning of layer otherwise?
Example way: http://www.openstreetmap.org/way/104978884 Other example area: http://www.openstreetmap.org/#map=19/52.52496/13.36941
This happened after the recent style changes a few days ago. Before buildings and roofs were rendered on top of the highway areas (and highway ways with covered=yes/tunnel=yes) and you could still see the highways because of the building transparency. Now you can't see the buildings anymore when there's a highway area inside. Is this a wanted behaviour or an error?