Open lakedistrictOSM opened 5 years ago
I would also render them with lower priority than bus stops.
or maybe the shelters with shelter_type=public_transport can also be rendered in blue instead of brown, to show that they are related to public transport?
It would help resolve issues like #2431 if they were rendered at z19.
his make them look like prominent, important places when really they're not.
In rural areas they can be the only shelters available in case of bad weather.
@maraf24 I can agree, but IMO it's still not a reason to render them at z17, I think z18 would be ok.
Just wanted to provide two additional examples to make the problem clear. The shelters are rendered while the bus stops are not:
Zoom 16:
Zoom 17:
[Following on from new discussion on #2431]
Summarising the various issues:
I've been testing the proposal of moving PT shelters to Z18+ and it works nicely. A public transport shelter is something small that you take advantage of, rather than a shelter you head to from a distance. It does clutter the map to render these from Z16.
Happy to submit a PR if general enthusiasm. This should close both #3483 and #2431, although #2431 has lots of suggestions for "stop + shelter" symbols that would fit better in #3124!
2431: As above, presenting problem is public transport (PT) shelters "hiding" bus stops. But solution of "prioritising" bus stops over shelters (i.e. when they are both being rendered at the same zoom level) doesn't seem a workable route.
This has been commented on in https://github.com/gravitystorm/openstreetmap-carto/issues/2431#issuecomment-1615161283 - and to be clear again: Changing priorities of shelter/bus_stop specifically would be ok, it is just not a workable route to address #3880 in general.
3483 (this issue): Addresses same problem as #2431, but in a more natural way. At low zoom, the bus stop will always be rendered, the shelter will appear later. Second order issue of prioritisation at Z18/Z19.
No, as written in #3880 the priorities need to be in sync with starting zoom levels, that does not mean changing starting zoom levels will fix priorities.
The choice of starting zoom level is a design decision and as such should not be influenced by our inability so far to fix #3880.
4317 [closed]: Issue proposing a new icon specifically for PT shelter. This didn't get much traction and the issue was closed. No reason why a specific symbol couldn't be used at Z18/Z19, but there is no need to complicate this issue.
The problem of #4317 was exclusively the lack of a suitable symbol. In general: I would strongly suggest that if the starting zoom level of shelters with shelter_type=public_transport is changed that also a symbol variant (which can differ is a subtle way) is used so the display rules are more intuitively understandable.
3124: Seems to be proposing a shelter-based symbol for bus stop with shelter. Not looking promising / largely independent of current proposal.
Part of #3124 could be aggregating shelter and bus stop into a single symbol - which would address the prioritization problem nicely. But technically this is somewhat difficult with current mapnik. The whole subject is discussed more in depth in https://imagico.de/blog/en/symbols-and-labels-3-augmenting-symbols/
I've been testing the proposal of moving PT shelters to Z18+ and it works nicely. A public transport shelter is something small that you take advantage of, rather than a shelter you head to from a distance. It does clutter the map to render these from Z16.
I would be in favor in principle of moving shelters with shelter_type=public_transport to a higher starting zoom level - with the following constraints:
That all makes sense.
It's clear from @BertMule 's example in #2431 (https://www.openstreetmap.org/#map=19/51.44462/4.92706) (where the shelters override stops even at Z19) that simply delaying PT shelters to Z18 and hoping that distance will avoid the prioritisation is a half-baked solution.
I do think that Z18 is a good start point based on size and function, but agree that a conservative approach is reasonable if the aim to to (partially) tackle #3880. This case might be a good test bed for solutions?
I assume a sensible option to addressing prioritisation is to introduce
ORDER BY start_zoom ASC
as you propose in #3880, but without (as yet) the SQL level filtering? [only defining start_zoom
for relevant POIs to start with]
I imagine that further sorting would be desirable in the longer term (#4676)?
A symbol variant would be important for mappers to intuitively understand the rendering logic
Yes, it would be a bit lazy otherwise. 3 starting options here:
transportation icon
blue (suggested by @Elefant-aus-Wuppertal above).It looked like you also had a PT shelter icon in (https://imagico.de/blog/en/symbols-and-labels-3-augmenting-symbols/) ?
3, Both a new icon and blue.
Option 2 may be the best; the shelter will always be larger (14 x 14, stop is 10 x 10) so there is the risk that a blue shelter might distract from the stop itself.
It would be a shame, however, to get blocked on the icon question, since a test for addressing #3880 as well the current issue would be a bigger prize.
I assume a sensible option to addressing prioritisation is to introduce
ORDER BY start_zoom ASC
as you propose in #3880, but without (as yet) the SQL level filtering? [only defining
start_zoom
for relevant POIs to start with]
In principle yes, the most viable way of prioritization of point symbols is by ordering in SQL.
But i would suggest to carefully separate between ideas for addressing #3880 and introducing means for explicit prioritization in amentiy-points in principle. The latter would be done using the same methods we use for defining priorities elsewhere - like
or
while for the former this will depend on the approach taken to address #3880 and is likely to require a different method to scale to the level of complexity we have here overall and to avoid the duplication of logic. You especially need to keep in mind that the starting zoom level frequently varies among elements with the same feature value while explicitly prioritizing bus stops over shelters can be done based on the feature column alone.
while explicitly prioritizing bus stops over shelters can be done based on the feature column alone.
Don't you need the shelter_type
hstore tag as well?
I was thinking that a more elegant solution was needed than the approach in #4836. I don't see how you can address #3880 without moving the "starting zoom" logic into the SQL, but it's not obvious how would do this is a generic way where the start zoom depends on different columns.
Perhaps there's a hybrid of JOIN(VALUES
approach and the explicit CASE WHEN
of #4836 to generate the starting zoom, but this might be beyond my SQL skills!
Don't you need the shelter_type hstore tag as well?
When you prioritize bus stops over shelters you can do so for all shelters and not just shelter_type=public_transport.
You still need a shelter_type
column to be able to select the right symbol and starting zoom level in MSS of course.
Please discuss #3880 there and not here.
When you prioritize bus stops over shelters you can do so for all shelters and not just shelter_type=public_transport.
That would feel a kludge to me. If you had a "proper" shelter next to a bus stop, then you would want to consistently prioritise the "proper" shelter.
I do have a working solution, but it may raise as as many questions as answers:
(SELECT *, CASE WHEN feature = 'shelter' THEN 15 WHEN feature = 'highway_bus_stop' THEN 16 WHEN feature = 'amenity_shelter_public_transport' THEN 17 END AS start_zoom 'amenity_' || CASE WHEN amenity = 'shelter' AND tags->'shelter_type' = 'public_transport' THEN 'shelter_public_transport' END,
[ahead of
amenity_shelter
in COALESCE]ORDER BY start_zoom ASC NULLS LAST, score DESC NULLS LAST, way_pixels DESC NULLS LAST
The "rewriting" of the feature column isn't necessary, but avoids duplicating logic in SQL and MSS. The MSS is then focussed on styling.
I don't see how to prioritise X over Y through ORDER BY
without assigning a priority to everything. In the above, the default priority is NULL, and so may lead to odd behaviour - a lot of PT shelters may pop up! A reasonable default priority / start_zoom
might be 16, i.e. "proper" shelters get a boost, PT shelters are disfavoured.
I also feel itchy about the sort ordering. It makes sense for larger areas to be prioritised, but this order is "hijacked" by putting other sort criteria above. score
is fairly harmless since so few things get a score, but the start_zoom
sort would currently push all the areas to the end. It would make more sense to me to prioritise way_pixels
>start_zoom
> score
.
If you had a "proper" shelter next to a bus stop, then you would want to consistently prioritise the "proper" shelter.
I see no reason not to prioritize bus stops over shelters in general - they have the same starting zoom level.
I don't see how to prioritise X over Y through ORDER BY without assigning a priority to everything.
You already have a priority assigned to everything, it is just the same for most nodes.
I might have been a bit convoluted in https://github.com/gravitystorm/openstreetmap-carto/issues/2431#issuecomment-1615161283 - so trying to make it more clear now:
The amenity-points
SQL code contains a lot of different things - stuff that is rendered with a symbol, a label or both. The labels get rendered separately in the text-point
layer, but with the same code.
You don't have to assign a unique priority to every tagging that gets rendered right away - although that would ultimately be the goal for addressing #3880 of course. But you also should not just prioritize bus stops over everything else, that would work badly relatively to features shown earlier than bus stops (like hospitals).
Yes, anything you'd do here short of actually addressing #3880 would be messy in one way or the other. That is why i have mentioned repeatedly that solving #3880 would be of high strategic importance.
Regarding the way_pixels sorting - keep in mind that for all the landcover labels the starting zoom level also depends on polygon size. So for the landcover labels way_pixels sorting already implements sorting by starting zoom levels. For the POI symbols, however, it does not. And of course there are labels in other layers (like stations
) that partly start earlier than amenity-points
and partly later.
And another reminder that this is not the right issue to discuss prioritization.
I see no reason not to prioritize bus stops over shelters in general - they have the same starting zoom level.
My bad. In my walking-oriented derivative, shelters are prioritised and start at Z15.
You don't have to assign a unique priority to every tagging that gets rendered right away - although that would ultimately be the goal for addressing https://github.com/gravitystorm/openstreetmap-carto/issues/3880 of course. But you also should not just prioritize bus stops over everything else, that would work badly relatively to features shown earlier than bus stops (like hospitals).
So you could just do something like:
CASE WHEN feature = 'amenity_shelter_public_transport' THEN 17 ELSE 16 END AS start_zoom
which would push PT shelters below everything else.
And another reminder that this is not the right issue to discuss prioritization.
Point taken, but I think we're agreed that simply changing the starting zoom without changing the relative priority of shelter vs. stop won't really fix things.
So you could just do something like:
CASE WHEN feature = 'amenity_shelter_public_transport' THEN 17 ELSE 16 END AS start_zoom
which would push PT shelters below everything else.
I doubt this would work any better than prioritizing bus stops above everything else. You would end up with various POI types with later starting zoom level and often clearly lower priority to block shelters and make them vanish as you zoom in. In this specific case in particular things like elevators, vending machines and information boards come to mind.
Point taken, but I think we're agreed that simply changing the starting zoom without changing the relative priority of shelter vs. stop won't really fix things.
Yes. But i also want to emphasize this is my opinion only so far. Short of actually solving #3880 i have no really good solution to suggest so if any of the other maintainers sees a different viable route to go forward here i am open to that.
I doubt this would work any better than prioritizing bus stops above everything else. You would end up with various POI types with later starting zoom level and often clearly lower priority to block shelters and make them vanish as you zoom in. In this specific case in particular things like elevators, vending machines and information boards come to mind.
You're right. Swapping the "catch all"
CASE WHEN feature = 'highway_bus_stop' THEN 16 ELSE 17 END AS start_zoom
would avoid the problem above (as well as the need to "rewrite" the feature column). It would mean that bus stops would oddly block any POIs with higher starting zoom (including "normal" shelters!), but there probably aren't many of those?
So there may be a partial / incremental solution to #3880 if starting from the "top down"?
It would mean that bus stops would oddly block any POIs with higher starting zoom (including "normal" shelters!), but there probably aren't many of those?
As already mentioned they would block stuff that already starts earlier (practically meaning: those would vanish as you zoom in).
So there may be a partial / incremental solution to https://github.com/gravitystorm/openstreetmap-carto/issues/3880 if starting from the "top down"?
I suggest to discuss strategies for solving #3880 there. As commented there already improving the drawing order in amenity-points does not have to be combined with addressing #3880. Any selective fix for some existing problems is welcome as long as it does not introduce new issues.
As commented there already improving the drawing order in amenity-points does not have to be combined with addressing https://github.com/gravitystorm/openstreetmap-carto/issues/3880. Any selective fix for some existing problems is welcome as long as it does not introduce new issues.
This is the bit I'm not really getting. Is there some way to selectively prioritise highway=bus_stop
over PT shelter that I'm missing? I don't see how to do this in the SQL query, since any form of ORDER BY
will require setting a "default" priority.
What you can do is aggregating different feature types into a common priority (despite them having different starting zoom levels) and this way you don't need to develop a full solution to #3880 while still being able to do some meaningful prioritization. For example you could
I am not claiming that either of these will work particularly well - i have not tried it. But in principle these are components that would allow you to do a partial explicit sorting in amenity-points without giving every feature class an explicit priority. And the bar is low because right now we don't do a meaningful prioritization at all for the most part. Hence anything other than an explicitly wrong order (like the mentioned prioritization of bus stops over hospitals) would be acceptable IMO.
That's seems a lot of engineering to address one prioritisation! Really you would want some kind of look-up table to return feature name + info useful for prioritisation, which is getting beyond what we do with the current all in-lined SQL (making apologies in advance for bringing up #3880 again).
Given that there isn't an easy immediate fix, a PR to push PT shelters down to Z17 would solve a large fraction of the problems. This would leave still leave the question of whether a distinct styling for PT shelters is first needed.
amenity=shelter + shelter_type=public_transport Wiki: https://wiki.openstreetmap.org/wiki/Tag:shelter%20type=public%20transport?uselang=en-GB
As the wiki says, these are small shelters found at bus stops and train stations.
Currently they are rendered from z16, which means they are rendered before typically larger features like pubs, restaurants etc. This make them look like prominent, important places when really they're not. Following the size rules mentioned by @kocio-pl recently, these shelters should be rendered later because of their small size. I propose moving them to z18 or maybe z19.