Skip to content

Loading…

Should landcover be ordered by z_order? #53

Open
gravitystorm opened this Issue · 10 comments

5 participants

@gravitystorm
Owner

At the moment the query orders by both z_order and way_area. Ordering by area makes sure small polygons end up on top (where there's no holes in a larger polygon). I guess z_order will help if the features are on separate layers, since there's no fine control over landcover ordering required.

But is this necessary? Are overlapping features with different z_orders - and the larger one on top - either common or wanted?

@pnorman
Collaborator

Something small under a big field comes to mind, although I'm not 100% certain what landcover would be underneath.

@math1985 math1985 added the landcover label
@math1985
Collaborator

The most common case is probably underground parking.

Not sure what else this is relevant for?

@math1985
Collaborator

Piers are another example, see #330.

This was referenced
@math1985
Collaborator

See also #685.

@math1985
Collaborator

Are there any other examples for which this is relevant?

@math1985 math1985 added this to the Bugs and improvements milestone
@daganzdaanda

Similar to the examples in #685 are subway stations in Munich:
Stachus https://www.openstreetmap.org/#map=19/48.13970/11.56587&layers=N and to the east, at the Marienplatz.
Berlin Hauptbahnhof is pretty complicated:
https://www.openstreetmap.org/#map=18/52.52447/13.36974

@fgregg

Here's another example: Big buildings above a large underground railway platform in Chicago:

https://www.openstreetmap.org/#map=19/41.87848/-87.63955

@math1985
Collaborator

In fact I think it's an example of #688. Neither buildings nor railway platforms are rendered by the landcover layer.

@math1985
Collaborator

Given that we haven't seen any usecase for ordering landcover by z_order in 2 years time, I will close this. Ordering of railway platforms etc. will still be considered, but these are not landcover.

@math1985 math1985 closed this
@math1985 math1985 reopened this
@math1985
Collaborator

Now I look at this issue again, I see that my statement does not correspond to my action. I thought the current situation was that z_order (or layer) is not taken into account, but in fact it is. I still think it would be better not to take it into account, so the correct action, I think, would be to remove the layer column from the ORDER BY.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.