Do not render railway crossings if only tramways are involved (#4559). #4579
Conversation
There was a problem hiding this comment.
Thanks for the pull request. This is in principle the correct approach to implement rendering of railway crossings differentiated by type or railway.
My assessment of the idea from #4559 (comment) is unchanged:
Considering how widely these are mapped and how significant they are often for navigation i would be skeptical about removing rendering. But adjusting the starting zoom level or the symbol specifically for tram crossings might be a good idea.
I would encourage you to try modifying your PR along these lines, i.e. instead of dropping rendering of railway crossings when they are located on a tram track to render those in a distinct styling with a later starting zoom level and a less massive symbol. Starting at z16/z17 and using the smaller symbol currently used for z14/z15 would be a starting point but you can also try different symbol variants.
| crossing.access AS access, | ||
| crossing.railway AS type, | ||
| crossing.railway AS railway, | ||
| track.railway AS int_lc_type |
There was a problem hiding this comment.
These appear to be unused so should be removed.
| JOIN planet_osm_line track | ||
| ON ST_DWithin(crossing.way, track.way, 0.1) -- Assumes Mercator | ||
| WHERE crossing.railway IN ('crossing', 'level_crossing') | ||
| AND track.railway IS NOT NULL AND track.railway <> 'tram' |
There was a problem hiding this comment.
That means all railway crossings that are wrongly mapped not on any kind of railway (tram or otherwise) are hidden and not visible to the map user. That is incompatible with our goal of providing constructive mapper feedback i think. We - as a general rule - do not hide features from rendering based on spatial analytics telling us that they are mapped incorrectly. If a mapper maps a railway crossing in the middle of nowhere we show that because the mapper either has a good reason for that or it is an error and should be corrected and showing it helps mappers in seeing such errors.
| ON ST_DWithin(crossing.way, track.way, 0.1) -- Assumes Mercator | ||
| WHERE crossing.railway IN ('crossing', 'level_crossing') | ||
| AND track.railway IS NOT NULL AND track.railway <> 'tram' | ||
| ORDER BY crossing.way |
There was a problem hiding this comment.
Although this is not a newly introduced problem i would like to mention that we generally want to use explicit ordering in queries where the order of features returned matters (which is the case here because the symbols are blocking each other). It would therefore be advisable to order also by (a) priority based on railway type and (b) osm_id to always have a defined drawing order.
| <<: *extents | ||
| Datasource: | ||
| <<: *osm2pgsql | ||
| table: &railway-crossing_sql |- |
There was a problem hiding this comment.
The &railway-crossing_sql is unused and therefore should be removed.
| @@ -1471,7 +1471,8 @@ | |||
| } | |||
| } | |||
|
|
|||
| #amenity-low-priority { | |||
| #amenity-low-priority, | |||
| #railway-crossings { | |||
There was a problem hiding this comment.
Since there is no overlap in style rules between the amenity-low-priority and railway-crossings layers the style rules for those should be separate.
|
@joto Is there any functionality in the flex input of My understanding is that the only "connections" that can be made between OSM objects are between relations and their member ways? But there are a few contexts where it would be useful to "mark" nodes and subsequently extract tag values from their "parent" ways e.g. fords on waterways. Other cases may be too awkward, e.g. mini roundabouts generally link multiple ways. |
|
@dch0ph Your understanding is right, currently there is no way to look at tags of way nodes in some special way in osm2pgsql flex. This is certainly something where osm2pgsql could and should do better. Details are probably off-topic here though. |
|
Many thanks for confirming. It would better to avoid these spatial searches if alternatives were available. But, in the end, cases where we need to "cross-refer" between nodes and intersecting ways are pretty rare; generally all the information needed to render a node is tagged on the node itself. |
|
Lets not intermix discussion of data preprocessing strategy with a concrete pull request. We have developing a data preprocessing strategy in #5027 - for more detailed discussion a new issue can be opened. To avoid confusing @johsin18 - the requests for changes in the review remain, if you need advice/help with any of them please ask. |
Fixes #4559
Changes proposed in this pull request:
Do not render railway crossings if only tramways are involved.
Test rendering with links to the example places:
https://www.openstreetmap.org/#map=16/47.5403/7.5733
Before
After
