-
Notifications
You must be signed in to change notification settings - Fork 819
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
Use ST_PointOnSurface for stations #3690
Conversation
It's not necessary that this gets returned as a column
railway, | ||
aerialway, | ||
tags->'station' AS station | ||
FROM planet_osm_polygon |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't you need a way && !bbox!
here as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good now.
Note that this adds rendering of railway=subway_entrance on polygons - i am not sure this is a good idea since railway=subway_entrance is meant to be a node on a footway/stairs and i am not sure if applications typically also consider polygons here. This differs from railway=halt/railway=station where no connectivity is usually expected.
I'd prefer the ST_PointOnSurface changes not to have impact on rendering output. If there is something in the rendering we want to change, we can do so afterwards in a separate pull request. That way we can keep the technical discussion separate from the discussion on how we want things to render. |
This also adds an ordering to the statements, which was previously missing.
I've fixed it to mostly match the existing rendering. Where it doesn't match is the ordering which was previously undefined. It now also orders by type of station before geometry type, because that's possible now. |
Use ST_PointOnSurface for stations
Also a minor code cleanup to prio generation