Push some small amenities to higher zoom level
I think such small amenities as amenity=post_box and amenity=atm are rendered too early now (z17, like shops for example). They are more important than trash cans (z19), so z18 seems like a natural choice for me.
This issue is related to https://github.com/gravitystorm/openstreetmap-carto/issues/847#issuecomment-127776632 - I have proposed rendering amenity=recycling+recycling_type=container and amenity=waste_disposal also from z18, as they are also only of local interest, but more important than trash cans.
Is getting the money less important than spending it? I am not sure.
I think about proportions: the counterpart for shops is rather bank or post office IMO. ATM or post box are less important than them.
Similar case: amenity=recycling+recycling_type=centre are bigger/more important > amenity=recycling+recycling_type=container and amenity=waste_disposal are in between > trash cans are the least important.
Another progression of scale: monument > memorial sculpture > memorial plaque. There can be also many other such things - for example we already show supermarkets/malls etc earlier than convenience shops.
Mockup with atm, post_box, telephone pushed from z17 to z18 (and emergency_phone to z19, as this is highly specialized kind of amenity):
z17:
z18:

I also think about moving them to the low priority group.
Another amenities that could be probably moved further down the zoom level and/or prioritized as less important could be toilettes and drinking_water, but I am not sure about them yet.
Given the density of post boxes, I don't think they should be moved from z17 to z18.
It's not about density of post boxes alone - they just add up to the whole density, as you can see, like other small amenities. They are clearly less important than post offices, so in my opinion it's perfectly legit to push them +1 zoom level.
In many places they are of less interest for general public (it's not a map mainly for tourists anyway) and there is a special issue about objects in rural areas, where every POI is more important than in the city/town/village, so post boxes should be more visible there (maybe even more than now - we'll see).
I think pnorman meant there are only postboxes every 1000 meter (in Germany).
Yes, I have understood it this way too - does it sound like I haven't? In other words: I realize that their density is low, but there are other POIs on the map and the sum of all the elements can be dense (as on the example picture) and it makes sense to clear the things (even a bit) if we can. Those small elements tend to be placed around some more important ones, so they don't just take unused space, they rather make busy places even more busy.
BTW: do we have levels of importance or just normal/low groups? I think it would be the best to have more layers - post box may be less important than post office or a shop, but is more important than trash can.
I think such small amenities as amenity=post_box and amenity=atm are rendered too early now (z17, like shops for example). They are more important than trash cans (z19), so z18 seems like a natural choice for me.
+1
Detailed technical question: how should I create amenity-medium-priority group? I see that in project.yaml group with id amenity-low-priority has something like:
ORDER BY prio
) AS amenity_low_priority
but I don't understand how it is used then to find the real priority level?
Maybe we don't need additional group, because this line:
CASE WHEN amenity='waste_basket' THEN 2 ELSE 1 END AS prio
is the core information (the more number, the lower priority) and I could give 3 to waste_basket, 2 for current low priority objects and 1 for those small amenities?
Of course I understand I need to also edit amenity-points.mss file.
Detailed technical question: how should I create amenity-medium-priority group? I see that in project.yaml group with id
amenity-low-priorityhas something like:ORDER BY prio ) AS amenity_low_priority
The name of the table in the SQL (amenity_low_priority) exists purely for ease of debugging SQL statements. It could be changed to anything and all that would happen is identifying which layer a query is from when just looking at a SQL log would become very difficult.
The id amenity-low-priority is significant, but is just a string of text. You could change it to anything, but would need to change the cartocss the same way.
The "priority" is determined by rendering order, i.e. where the layer is relative to other layers. Within the layer, the order rows are returned in is what determines rendering order, as well as cartocss order.
is the core information (the more number, the lower priority) and I could give 3 to waste_basket, 2 for current low priority objects and 1 for those small amenities?
Yes.
I'm waiting for https://github.com/gravitystorm/openstreetmap-carto/pull/1825 to be applied (and maybe also for https://github.com/gravitystorm/openstreetmap-carto/issues/1802#issuecomment-138809013), but the code is more or less ready and it's working as expected: global density change is not visible, but in some places it's getting more clear and the overall view is more uniform (smaller amenities don't mix with standard ones on z17 and ATMs should not eclipse banks on any zoom level).
Another candidate for moving deeper: barrier=bollard should be rendered on z>=19 in my opinion. It also means some other small amenities could be rendered there:
- fire hydrants (simply as a red dot)
- traffic sign poles (silver dot)
- street lamps (probably some lamp shape in black)
They are also used to be a part of bollard line.
barrier=bollard is very important kind of barrier that makes road impassable for cars. It should be rendered earlier not later. However, there are some bollards which are not part of the road. These could be rendered at z19.
Thanks for the comment, it makes a lot of sense! Is there a way to detect in this style if the bollard is part of the road?
@kocio-pl
It should be possible. See turning circles - I think that currently only ones on highway ways are displayed.
It should be rendered earlier not later.
Currently it is visible from z16 I guess, which zoom level would you like to have as the starting one?
http://www.openstreetmap.org/#map=19/33.05398/-96.69600 seems to show that bollards are rendered, though rather oddly (see the gap between 75 HOV and 75 on the link there; context is the Central Expressway in metro Dallas, Texas.
On Sun, Sep 13, 2015 at 1:19 PM, Mateusz Konieczny <[email protected]
wrote:
@kocio-pl https://github.com/kocio-pl
It should be possible. See turning circles - I think that currently only ones on highway ways are displayed.
— Reply to this email directly or view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/1745#issuecomment-139901036 .
I guess highway=traffic_signals are also smaller amenities, so they should be moved to z>=18 instead of z>=17 (which is better for standard amenities).
Now I think traffic_signals should be moved to z>=19, since they are not the even the small amenities worth looking for, rather part of a road infrastructure.
Note that some ideas were declined in #1884.
@kocio-pl would you consider returning to this issue? Maybe #1884 could be split in smaller tasks. I'd be very interested in moving bollards (the ones that don't belong to a highway) to z19 as they tend to mess up the map at z16-z17:
http://www.openstreetmap.org/#map=16/52.2239/20.9200

would you consider returning to this issue? Maybe #1884 could be split in smaller tasks.
Feel free to do it yourself. I can join the party, but I won't do it alone.
I would like to get back to this issue - the summary of a rejected PR was:
against moving toilets - 1 against moving drinking_water - 2 against moving emergency_phone - 1 against moving traffic_signals - 2The rest (atm, post_box and telephone) was not mentioned directly, however @imagico propositions is completely different and is hard to count.
Would it make sense to create separate PRs for these 3 types to be rendered from z18?
I still don't know how to push bollards to z19+ only if they are not part of highway, but I think this should not create controversy. Can anybody help me with this?
Just a reminder to myself: there's a separate issue for loose bollards and hint how to do it (#2756).
Just for sort things out - there are 4 tags left in this issue:
- amenity=drinking_water
- amenity=atm
- amenity=post_box
- amenity=telephone
@kocio-pl @Adamant36 Current state:
- [x] amenity=atm -> done! https://github.com/gravitystorm/openstreetmap-carto/pull/3372
- [ ] amenity=post_box -> https://github.com/gravitystorm/openstreetmap-carto/issues/3431
- [ ] amenity=drinking_water
- [ ] amenity=telephone
@Tomasz-W, thanks. Amenity=post_box is currently an issue though, not a PR. Although, I guess I could have done one for it.
@Adamant36 Oh, I see now. I think that splitting PRs into smaller parts is OK, but I find splitting issues (at least this one) unnecessary for the reason given in https://github.com/gravitystorm/openstreetmap-carto/issues/3298#issuecomment-427260884 .
@tomasz-W, Good call, even if I disagree. I took the original comment by @kocio-pl about it as a possible suggestion and not a part of the issue. Since he didn't include it in the ATM PR. I guess that's part of the problem with not having unified way of doing things. Issues, lists in issues (sometimes referencing other issues, with their own lists), PRs, lists of PRs, PRs with lists of issues, etc, etc. It can easily turn into inception sometimes ;)