Openstreetmap-carto: Scrub overlaps danger area

Created on 16 Oct 2018  Â·  15Comments  Â·  Source: gravitystorm/openstreetmap-carto

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

map

landcover

Most helpful comment

@uswoods

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

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.

All 15 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):

The style is large enough that no one person can understand it all. I know I can’t and I’m a maintainer. There are too many parts, and too many interdependencies between them.

http://paulnorman.ca/blog/2015/11/openstreetmap-carto-complexity/

If there’s one thing I’ve learned in open source, it’s this: the more work you do, the more work gets asked of you. There is no solution to that problem that I’m aware of.

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 project.mml so we probably need to move military_ query (l.132) after natural_ and wetland_ (l.133 & 134).

It seems fine on wetland though. So if order was the issue, you would think it wouldn't be.
https://www.openstreetmap.org/#map=16/39.1482/-121.3907
wetland

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?
https://www.openstreetmap.org/#map=17/39.13584/-121.35397
scrub

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.
Mapnik then sorts all features by size (Painter's algorithm
.

Normaly this is intended so we have an playground painted after/over the park in which it is.
The example from matthijsmelissen is a larger scrub than the military.

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?

danger_area

@uswoods

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

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.

Was this page helpful?
0 / 5 - 0 ratings