openstreetmap-carto icon indicating copy to clipboard operation
openstreetmap-carto copied to clipboard

Push some small amenities to higher zoom level

Open kocio-pl opened this issue 10 years ago • 45 comments

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.

kocio-pl avatar Aug 14 '15 11:08 kocio-pl

Is getting the money less important than spending it? I am not sure.

HolgerJeromin avatar Aug 14 '15 13:08 HolgerJeromin

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.

kocio-pl avatar Aug 14 '15 13:08 kocio-pl

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: small-amenities-17 z18: small-amenities-18

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.

kocio-pl avatar Aug 17 '15 13:08 kocio-pl

Given the density of post boxes, I don't think they should be moved from z17 to z18.

pnorman avatar Aug 18 '15 01:08 pnorman

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).

kocio-pl avatar Aug 18 '15 12:08 kocio-pl

I think pnorman meant there are only postboxes every 1000 meter (in Germany).

HolgerJeromin avatar Aug 18 '15 12:08 HolgerJeromin

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.

kocio-pl avatar Aug 18 '15 12:08 kocio-pl

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

matthijsmelissen avatar Aug 18 '15 13:08 matthijsmelissen

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.

kocio-pl avatar Aug 18 '15 17:08 kocio-pl

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

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.

pnorman avatar Aug 18 '15 21:08 pnorman

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.

matkoniecz avatar Aug 18 '15 21:08 matkoniecz

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).

kocio-pl avatar Sep 10 '15 23:09 kocio-pl

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.

kocio-pl avatar Sep 13 '15 11:09 kocio-pl

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.

maraf24 avatar Sep 13 '15 16:09 maraf24

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 avatar Sep 13 '15 18:09 kocio-pl

@kocio-pl

It should be possible. See turning circles - I think that currently only ones on highway ways are displayed.

matkoniecz avatar Sep 13 '15 18:09 matkoniecz

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?

kocio-pl avatar Sep 13 '15 19:09 kocio-pl

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 .

BalooUriza avatar Sep 14 '15 06:09 BalooUriza

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).

kocio-pl avatar Sep 14 '15 19:09 kocio-pl

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.

kocio-pl avatar Sep 23 '15 14:09 kocio-pl

Note that some ideas were declined in #1884.

matkoniecz avatar Jun 09 '16 20:06 matkoniecz

@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 image

kdudzik avatar Dec 14 '16 23:12 kdudzik

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.

kocio-pl avatar Dec 15 '16 00:12 kocio-pl

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 - 2

The 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?

kocio-pl avatar Jun 17 '17 23:06 kocio-pl

Just a reminder to myself: there's a separate issue for loose bollards and hint how to do it (#2756).

kocio-pl avatar Sep 06 '17 13:09 kocio-pl

Just for sort things out - there are 4 tags left in this issue:

  • amenity=drinking_water
  • amenity=atm
  • amenity=post_box
  • amenity=telephone

Tomasz-W avatar Jul 15 '18 08:07 Tomasz-W

@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 avatar Oct 06 '18 08:10 Tomasz-W

@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 avatar Oct 06 '18 08:10 Adamant36

@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 avatar Oct 06 '18 09:10 Tomasz-W

@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 ;)

Adamant36 avatar Oct 06 '18 09:10 Adamant36