-
Notifications
You must be signed in to change notification settings - Fork 820
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
Scrub overlaps danger area #3454
Comments
Strange, could anybody investigate this problem? |
Strange indeed. This forest also gets rendered incorrectly: https://www.openstreetmap.org/way/134745853 Example of scrub/military rendered correctly: https://www.openstreetmap.org/#map=17/52.11047/4.31424 |
@kocio-pl @matthijsmelissen You have taken over this style – and then you don't know any reason for such behaviour? Are you maybe a little bit overchallenged by your work? |
@uswoods, instead of just criticizing people it might be better to pose a solution to the problem if you know of one, because everyone is at their own level and rendering priority issues are especially hard to deal with. Even for the seasoned people here. |
In case these are not just rhetorical questions - yes, I don't know and it sometimes is overwhelming, but I see nothing strange about this. And this is why the teamwork matters a lot and you can help too. More detailed answers were already written by others (I recommend them, both are worth reading):
http://paulnorman.ca/blog/2015/11/openstreetmap-carto-complexity/
https://nolanlawson.com/2017/03/05/what-it-feels-like-to-be-an-open-source-maintainer/ |
@uswoods This is a volunteer’s project. The contributors sacrifice part of their spare free time to improve this rendering style. Please be more polite. |
I suppose that order in queries is important in |
Text from jragusa as a permalink: openstreetmap-carto/project.mml Lines 132 to 134 in 6d259ca
|
It seems fine on wetland though. So if order was the issue, you would think it wouldn't be. |
Here's a place with scrub that's fine also. I think it might have something to do with how it overlays outside of the military area or maybe that its a relation. Although the sand doesn't seem to be. Maybe something mapped under them that's screwing the rendering order up? |
The order in project.mml is only the sql query. This build only the query, without an order. The problem is that the military is rendered "at the same time" (in the same layer) as the other landuse. Normaly this is intended so we have an playground painted after/over the park in which it is. |
I see the cause of this issue now. My example was a landuse=military while this is a military=danger_area. The tag military=danger_area should be rendered from landuse-overlay (just like landuse=military already is), rather than from the landcover layer. Good catch, @momu. This requires changes to project.mml and landcover.mss. Following the example of landuse=military for military=danger_area should work. Is anybody willing to try? |
It is preferable to not comment at all rather than leave hostile comments. See https://github.com/gravitystorm/openstreetmap-carto/blob/master/CODE_OF_CONDUCT.md for details. In addition: "weird, I have no idea why it is happening" is something completely normal during developing or maintaining software and it is reaction that typical programmer encounters frequently Nobody is obligated to spend any time maintaining this project. One of main reason for stopping contributing to projects like this is repeated negative feedback and lack of positive (basically, where everything goes OK noone comments, where anything goes poor in any way someone will complain). Adding hostility to that is not helpful. |
I suspect this issue might have the same problem: #1285. |
Expected behavior
The danger area[1] should be above the beach and scrub[2].
Actual behavior
Scrub and beach are above the danger area.
Links and screenshots illustrating the problem
[0]: https://www.openstreetmap.org/#map=18/54.15019/13.82067
[1]: https://www.openstreetmap.org/way/307904554/
[2]: https://www.openstreetmap.org/way/578224669
The text was updated successfully, but these errors were encountered: