Skip to content
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

Pushing small amenities to higher zoom levels #1884

Closed
wants to merge 1 commit into from

Conversation

kocio-pl
Copy link
Collaborator

Resolves #1745.

Objects moved down to z>=18:

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

Objects moved down to z>=19:

  • amenity=emergency_phone
  • highway=traffic_signals

Examples:

Warsaw, z17 (21.0843,52.2430,21.0878,52.2451), before/after
small-amenities-universam-before-17
small-amenities-universam-17

Warsaw, z17 (21.0098,52.2484,21.0144,52.2512), before/after
small-amenities-starowka-before-17
small-amenities-starowka-17

However I am not sure if the code related to priorities works as expected - please correct me if I made any mistakes, I'll try to learn how to use it. The biggest problem is that it's hard to test them.

@dieterdreist
Copy link

sent from a phone

Am 29.09.2015 um 20:34 schrieb kocio-pl notifications@github.com:

Objects moved down to z>=18:

amenity=atm
amenity=post_box
amenity=telephone
amenity=toilets
amenity=drinking_water
Objects moved down to z>=19:

amenity=emergency_phone
highway=traffic_signals

drinking water (and maybe emergency phones) are also important outdoor POIs in rural areas, by hiding them before z18 they will basically almost never show up in this context while browsing the map

@pnorman
Copy link
Collaborator

pnorman commented Sep 29, 2015

amenity=toilets
amenity=drinking_water

I'd rather not move these to z18. If we're getting overwhelmed with private toilets, we could look at handling them like parking.

amenity=emergency_phone
highway=traffic_signals

traffic signals work well on z17 here. There's not much overlap with other icons because they're in the middle of roads, where POIs tend to not be.

@matkoniecz
Copy link
Contributor

private toilets

This is be definition an invalid tagging, amenity=toilet is defined as a public toilet.

@matthijsmelissen
Copy link
Collaborator

Very useful PR! I'd prefer to keep traffic_lights where they are, they are very important for navigation ('turn left at the second lights').

@kocio-pl
Copy link
Collaborator Author

Sorry, I should have start with a rationale probably (it seems I did it in some other comments). My main purpose here is to establish a general system based on already existing scheme:

special shop (z16) > standard shop (z17) > vending machine (z18)
special amenity (z16) > standard amenity (z17) > small amenity (z18)
monument (z16) > statue (z17) > stone (z18) > plaque on the wall (z19)

...and so on. We're currently not showing vending machines nor we're able to recognize the type of memorial, but I hope we will in the future.

The system does not have to be strict, but I think it's a sane default to start with. We can still have exceptions, but at least we should know why we want them. So we can discuss drinking water, emergency phones, toilets and traffic_signals, of course.

I think the main problem with them is that they have different priority for users in different environments, but we have currently no tools to know it for sure (interesting exception could be a bollard - it's very important on the road, but otherwise it belongs to z19 and I think it's easy to check). It's a general problem described in #1705.

Let's look closer at these examples:

  • Drinking water is a secondary amenity in the city, as shown on the image above (see also St. Peter's Square in Vatican), but can be as important as shelter in the outdoor.
  • Emergency phones on the metro station are the least important thing (we already have a big problem with multi-level objects clutter), while it may be the only POI in some places near motorway.
  • Toilets should be visible when in some bigger area, especially for tourists or visitors (like theme park or zoo), but in general they are less important than for example bank or post office (they can even be a part of them, but not the other way around).
  • Traffic lights may be important for navigation outside the city on the long road, but inside they are in general visually competing with street names, shields and direction arrows, which are more important, and the roads are much shorter there.

What do you think we can do with those cases?

@imagico
Copy link
Collaborator

imagico commented Sep 30, 2015

I would probably do it more or less exactly the other way round - keeping the listed things at the current zoom levels but moving shops in general and possibly also restaurants etc. up one zoom level. With the huge number of shop types added recently shops are very dominating at z17 strongly affecting general map readability and this would help here. And shops are much more limited to dense urban areas while the features you intend to downgrade are mostly quite common in smaller places and rural areas where you often do not use z18/19 at all.

You can also look at it differently: atm/toilets/drinking_water/emergency_phone are all addressing very basic needs and should therefore have priority over things addressing more specialized and sophisticated needs like shops.

And in any case at z18 and z19 all symbols shown at z17 already should have priority over those starting later - this does not seem to be the case right now.

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Oct 5, 2015

I think about your proposition for a few days, because it's so different, but I'm still not convinced:

You can also look at it differently: atm/toilets/drinking_water/emergency_phone are all addressing very basic needs and should therefore have priority over things addressing more specialized and sophisticated needs like shops.

Looking at your examples, toilets and drinking water may be seen as essential (well, mainly for visitors/tourists; rather not for anyone else), but any type of food+drink shops are very similar in this regard, while using ATM is definitely not a "basic need". And I don't even know how should we measure emergency phone: most of the time they're not even used, but sometimes they can be top priority. However this style is not "emergency" map, rather universal one, so I consider them less interesting. Otherwise we should probably show fire hydrants in a distinctive way and I don't think it would be good solution here.

I think my set of rules is rather compact and easy to apply to the new objects, while your approach is more subjective and specific instead of general solution I'm trying to achieve. When we try to act case by case, we fall into the "this-and-that" trap: we're not able to keep consistency in the long run (any new element can turn it upside down) and I'd like to avoid it.

@imagico
Copy link
Collaborator

imagico commented Oct 5, 2015

With addressing very basic needs i mean these features cater needs that are either essential for physical well-being (drinking water, emergency phone) or for socially acceptable behavior (toilets, ATM). This does not apply for the usual food&drink amenities which have primarily a social function (a non-obligatory one in most societies) and not basic sustenance.

Also note ATM is a prerequisite for use of shops and other things, not the other way round - hence it is more basic.

You can of course argue that emergency phone - like post box - is no more important due to the ubiquity of mobile communication. I would be careful with that but it is without doubt a possible argument in many parts of the world.

Otherwise we should probably show fire hydrants in a distinctive way

That's a joke, right? - an emergency phone is useful for everyone while a fire hydrant is not of any use for the vast majority of people (except maybe to park their car in front...).

I think my set of rules is rather compact and easy to apply

Did i understand you correctly that this is essentially physical size equals importance?

While this certainly is a consistent importance rating scheme and probably works quite well within a single class of objects (like large restaurants being more important than small ones) there are likely many people who disagree this is the best approach in general. The criterion should not be simplicity and ease of use from the developer perspective but usefulness for the map user.

@dieterdreist
Copy link

sent from a phone

Am 05.10.2015 um 18:58 schrieb kocio-pl notifications@github.com:

Looking at your examples, toilets and drinking water may be seen as essential (well, mainly for visitors/tourists; rather not for anyone else)

I don't agree, these are relevant to all people, not just visitors. It may depend on the climate (and availability) whether drinking water is essential or just nice to have, toilets tend to be more important for women than men

, but any type of food+drink shops are very similar in this regard, while using ATM is definitely not a "basic need".

I would see ATMs as basic need, unless you're in a region where you barter or pay everything above 2 cents with a credit card. This might change in the future (NFC payments, all other kinds of Proprietary Pay etc), but at least around here that's simply not the case yet.

And I don't even know how should we measure emergency phone: most of the time they're not even used, but sometimes they can be top priority. However this style is not "emergency" map, rather universal one, so I consider them less interesting.

agreed

Otherwise we should probably show fire hydrants in a distinctive way and I don't think it would be good solution here.

not at all, hydrants are completely different from emergency phones, as they are intended for the fire brigade to be used while the phones are intended for you.

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Oct 5, 2015

@imagico

With addressing very basic needs i mean these features cater needs that are either essential for physical well-being (drinking water, emergency phone) or for socially acceptable behavior (toilets, ATM).

Using ATM has nothing special to do with socially acceptable behaviour - buying goods or using any other services falls into the same category. This category is just too broad to be useful - in general we don't show any socially unacceptable behaviour objects.

This does not apply for the usual food&drink amenities which have primarily a social function (a non-obligatory one in most societies) and not basic sustenance.

While typical restaurant or bar may be seen as social, typical fast food is just totally different. What about alcohol shop? We loose any system here. And what about supermarkets? Now we also loose the reason behind current rendering.

Also note ATM is a prerequisite for use of shops and other things, not the other way round - hence it is more basic.

It may be in some cases, but it is not universal: you can get your salary from a postman/post office or just pay with a card. What about banks? Do you propose to show ATM first and bank later? For me it doesn't make sense. Again, we loose the system here.

One can also say that earning money is a prerequisite for using ATMs, so maybe industrial objects, retail objects and offices are more important... It's hard to say where should we start at all.

You can of course argue that emergency phone - like post box - is no more important due to the ubiquity of mobile communication. I would be careful with that but it is without doubt a possible argument in many parts of the world.

No, I said it's less important because it's small amenity and at the same time it is not an emergency map, so it should be less visible for general purposes. If we talk about safety features, health category is much more important for most of the people and relevant enough.

That's a joke, right? - an emergency phone is useful for everyone while a fire hydrant is not of any use for the vast majority of people (except maybe to park their car in front...).

You're right - this example is different. But what about fire extinguisher then? Anybody can use it, it's small and very useful in case of (fire) emergency. It's very similar to emergency phone.

Did i understand you correctly that this is essentially physical size equals importance?

No, it's just an important base feature - I mean: for a general map. Importance is a very useful modifying feature.

While this certainly is a consistent importance rating scheme and probably works quite well within a single class of objects (like large restaurants being more important than small ones) there are likely many people who disagree this is the best approach in general. The criterion should not be simplicity and ease of use from the developer perspective but usefulness for the map user.

Size is more objective criterion and it's easier to use even for totally new kind of objects; and even more people will disagree with what is more or less important. "Case by case" works if you have very small set of features - but we have much more of them and we start to deal with a big mix of things.

So, let's suppose we try to stick with importance as a base, not size. That would make UNESCO heritage objects (rare example when we have some objectivity in recognizing importance) shown at the world/country level, for example. That is great solution when trying to make a tourist map, but on general map I prefer to see a big military area earlier, even if it's not important (or even usable) for general public.

@imagico
Copy link
Collaborator

imagico commented Oct 5, 2015

I think you are getting side tracked here in multiple directions (and it does not really lead anywhere when you say things i did not say do not make sense to you). I'd suggest to stick to the subject at hand, that is if the changes in priorities you suggest, that is essentially to consider a number of amenities less important than all shops and food&drink amenities, are desirable.

I stick to my opinion that the changes you propose are in a very different direction to the priorities i consider useful. I offered some arguments with reasons for these priorities, i.e. why i consider ATMs, toilets and drinking water more important than jewelry and perfumery shops 😉. And i do not consider the typical physical size (however you intend to measure it) to be a useful criterion for cross category rating. I do not even think typical size is even less subjective than other measures of importance - after all the typical size of a shop/restaurant/whatever varies strongly with the cultural environment.

Maybe also see it from a different perspective: which of the following statements do you consider a more likely complaint from a map user:

  • I can't find a restaurant or clothing shop on the map because the map is filled with all the public toilets and drinking water points
  • I can't find a public toilet or drinking water point because the map is filled with all the restaurants and clothing shops.

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Oct 5, 2015

I think you are getting side tracked here in multiple directions

I guess what you call "being side tracked" is that we still have no place for general discussions, so we have to put everything into small, detailed boxes like this one. Looking for a general rules is a clear common thread in few of my propositions (like stations precedence or system for using colors of POIs, for example) and also the context which is important to understand the purpose of this piece of code. For me it is just the opposite of going into multiple directions.

(and it does not really lead anywhere when you say things i did not say do not make sense to you).

Sorry, I was trying to guess what do you mean and apparently didn't get your way of thinking.

I'd suggest to stick to the subject at hand, that is if the changes in priorities you suggest, that is essentially to consider a number of amenities less important than all shops and food&drink amenities, are desirable.

If we don't think about why having general rules of thumb is desirable, it's harder to understand why I propose to push them in the first place. I have nothing against some exceptions, but first I'd like to have some scale-related rules, not only disconnected individual "votes" on everything.

Are you just opposing those specific types of objects (as exceptions) or you don't like this rule at all?

I stick to my opinion that the changes you propose are in a very different direction to the priorities i consider useful.

I also still think that having rules is more important than trying to manually fine tune every type of object, especially when we have a lot of them.

Maybe also see it from a different perspective: which of the following statements do you consider a more likely complaint from a map user:

I can't find a restaurant or clothing shop on the map because the map is filled with all the public toilets and drinking water points
I can't find a public toilet or drinking water point because the map is filled with all the restaurants and clothing shops.

Interesting question, probably worth asking at the Talk list.

As for me the first is a no brainer: in dense places I wouldn't look for such amenities on the map, I'd rather ask the people or just look around (public toilets in restaurants or ATMs in banks are common features, at least here in Poland), restaurants and shops are much more interesting (especially restaurants are common meeting points). In the outdoor I think about general "amplifying" some objects (including water points or toilets), but there are no restaurants nor clothes shops to eclipse them.

@imagico
Copy link
Collaborator

imagico commented Oct 6, 2015

Are you just opposing those specific types of objects (as exceptions) or you don't like this rule at all?

I think using a feature type based estimate of typical sizes as an importance rating measure for POIs is not a good idea because it is (a) subjective, arbitrary and prone to cultural bias and (b) not well suited for this purpose. But even if you disagree it should be clear that this PR is not a good approach to executing this principle anyway since for example the typical size of a public toilet is likely not smaller than the typical size of a small shop like a kiosk, the size ratio within shops OTOH - from a kiosk to a mall/garden centre etc. - is probably larger than 1:100. Hence this would be a much more significant place to implement a size prioritization principle than the amenities here.

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Oct 6, 2015

Anything related to "importance" is even more subjective and definitely more influenced by the culture and multiple circumstances. Typical size is not completely free from this problem too, but it's simply not that severe. I don't believe in finding perfect solution, I just prefer something less subjective, more flexible and universal. I guess it's the closest thing to the neutral measure we can have for a general style.

But even if you disagree it should be clear that this PR is not a good approach to executing this principle anyway since for example the typical size of a public toilet is likely not smaller than the typical size of a small shop like a kiosk,

That would be acceptable explanation for me to leave the toilets on z17, however they can be also a part of fuel station for example and could eclipse it. What do you think about this problem?

the size ratio within shops OTOH - from a kiosk to a mall/garden centre etc. - is probably larger than 1:100. Hence this would be a much more significant place to implement a size prioritization principle than the amenities here.

And notice, that we already show malls earlier! If we find other examples of typically big shops, we should also make them appear earlier. I just started with things that I see most of the time that should be seen later, but the rule is still the same ("mind the scale").

@imagico
Copy link
Collaborator

imagico commented Oct 6, 2015

Note i use importance rating as a technical term here. This has nothing to do with an individual map users subjective considerations what is important or not for him/her. Importance rating occurs at many places in a map style - it is kind of absurd to say it should not be used.

And notice, that we already show malls earlier!

No, that is label placement for area features larger than the typical label size. For shop icons only supermarket and department_store are currently displayed early which is a fairly arbitrary choice. Also they are not rendered with priority over the other icons so they frequently vanish as you zoom in making the whole thing fairly counterproductive (see my first comment here).

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Oct 6, 2015

Note i use importance rating as a technical term here.

I am not familiar with that term nor do I understand what does it mean in a technical sense. Could you describe it a bit more or show me where I could learn about it?

No, that is label placement for area features larger than the typical label size. For shop icons only supermarket and department_store are currently displayed early which is a fairly arbitrary choice.

Up to now everything is more or less arbitrary and I'd like to change it to be more systematic, so I would be happy to work on some rules. However both supermarket and department store are big by definition (first one is bigger than convenience, second one includes many selling points), so I see nothing wrong with it.

Also they are not rendered with priority over the other icons so they frequently vanish as you zoom in making the whole thing fairly counterproductive (see my first comment here).

Good point, probably worth opening separate issue!

@matthijsmelissen
Copy link
Collaborator

@kocio-pl I'd be happy to merge this without the traffic light change, which might need some further consideration (and a separate PR).

In any case, if we decide to change the traffic signals, the line

[zoom >= 17] {
needs changing as well (a variable might make sense to avoid them getting separated again in the future).

@pnorman
Copy link
Collaborator

pnorman commented Oct 19, 2015

I'm against merging this.

@matthijsmelissen
Copy link
Collaborator

@pnorman Could you provide a bit more motivation?

You mentioned before you'd like to reduce the number of map features, would you be in favour of dropping any of the features in this PR instead?

@pnorman
Copy link
Collaborator

pnorman commented Oct 19, 2015

@pnorman Could you provide a bit more motivation?

#1884 (comment), and I generally agree with @imagico's comments above.

You mentioned before you'd like to reduce the number of map features, would you be in favour of dropping any of the features in this PR instead?

I could see moving some to the low priority layer - where these features are important tends to be areas where they wouldn't collide with other features. Others like amenity=drinking_water I see no need to change.

@kocio-pl
Copy link
Collaborator Author

@math1985 I was about to sum the things up to see where we can agree, to limit the scope of this PR, but after this comment of @pnorman I don't really understand if he's against moving anything or just those 3 (4?) items he mentioned before. But if you still support the idea of skipping traffic lights in this PR, I'm ready to make just this change.

@matthijsmelissen
Copy link
Collaborator

But if you still support the idea of skipping traffic lights in this PR

I'd prefer if we could find a form of consensus before merging this.

@pnorman Another question, is your objection mainly based on the rendering in residential/suburban areas, or is this a problem for dense urban areas as well? For example, do you think the proposed change works well in the example renderings in the first post, or do you think even the example renderings are problematic?

My motivation: completely mapped areas, even suburban ones, are currently rather hard to read at z17. Example The main cause seems to be the great variety of icons. The mailboxes there really seem to be not that significant.

@imagico
Copy link
Collaborator

imagico commented Oct 19, 2015

My motivation: completely mapped areas, even suburban ones, are currently rather hard to read at z17. Example The main cause seems to be the great variety of icons.

I already made the suggestion to move the shops and food&drink amenities up one zoom level.

@pnorman
Copy link
Collaborator

pnorman commented Oct 20, 2015

@pnorman Another question, is your objection mainly based on the rendering in residential/suburban areas, or is this a problem for dense urban areas as well? For example, do you think the proposed change works well in the example renderings in the first post, or do you think even the example renderings are problematic?

I see icon overload as a problem, but not one that this PR really addresses. If anything, I'd rather have some of the stuff under discussion (e.g. drinking water) moved down a zoom level to render sooner.

@dieterdreist
Copy link

sent from a phone

Am 20.10.2015 um 05:58 schrieb Paul Norman notifications@github.com:

I see icon overload as a problem, but not one that this PR really addresses. If anything, I'd rather have some of the stuff under discussion (e.g. drinking water) moved down a zoom level to render sooner.

while that would be useful for many parts of the world (especially outdoors) it will surely create problems in areas with lots of them (like around here). Too many collisions I suspect (years ago, when I last checked, there already were 500 in the city area).

@kocio-pl
Copy link
Collaborator Author

That's why I mentioned #1705 ("Showing some POIs earlier when outside the landuse=residential") - because for me those issues are correlated.

I think of size as the most universal property that could be used as a general rule and a context (such a "residential/city area" or "outdoor" for example) as a very important modifier - we can even call it a "secondary rule", which can change "primary rule" as much as we want it, not just "a bit".

Being secondary doesn't mean it's limited in any way (like for example "only +/- 1 zoom level change is allowed"), because context/environment can be very different. It only means that we think this is a special case and so we want to have more control.

But of course I would like to have some rules also within those special environments, because there can be a lot of objects which should be shown different and crafting everything manually can lead to inconsistencies and strange effects.

I see it like this (totally bogus pseudocode):

default rule
  mind the size
if environment == outdoor
  use some general_outdoor rules 
  treat special cases in a special way
if environment == city
  use some general_city rules 
  treat special cases in a special way
if environment == water
  use some general_water rules
  treat special cases in a special way 

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Nov 3, 2015

Just a short summary (that I wanted to do anyway):

  • 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. Maybe a competing issue/PR should be created instead to discuss its merits in itself?

@matthijsmelissen
Copy link
Collaborator

Unfortunately there does not seem to be support for the current PR so I'm going to close it. @kocio-pl Thanks for the effort! If @kocio-pl or anybody else has a different idea, feel free to propose it!

@kocio-pl kocio-pl deleted the small-amenities branch February 9, 2016 14:21
jeisenbe added a commit to jeisenbe/openstreetmap-carto that referenced this pull request Feb 27, 2020
This PR, similar to closed PR gravitystorm#1884, moves amenity=atm and amenity=post_box to z18, though in this case they are currently rendered only at z19. Also emergency phones are moved back to z18 from z19
jeisenbe added a commit to jeisenbe/openstreetmap-carto that referenced this pull request Mar 7, 2020
This PR, similar to closed PR gravitystorm#1884, moves amenity=atm and amenity=post_box to z18, though in this case they are currently rendered only at z19. Also emergency phones are moved back to z18 from z19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants