gravitystorm / openstreetmap-carto

A general-purpose OpenStreetMap mapnik style, in CartoCSS
Other
1.51k stars 812 forks source link

Guidelines on adding new icons #660

Closed matthijsmelissen closed 6 years ago

matthijsmelissen commented 10 years ago

There are quite a few requests for adding new icons (#591 #540 #570 #487 #456 #452 #450 #419 #418 #336 etc), and even more features that we currently do not render, but might be nice to have on the map.

How do decide which POIs we render as icon?

Do we want to increase the icon set, or keep the set of icons small?

@gravitystorm you indicated in the past that you are in favour of an approach that doesn't involve hundreds of new icons. Could you give some more background to that statement?

A large icon set might give more information. But having too many icons might also make the map unreadable. We should also make sure that all icons are understandable.

matthijsmelissen commented 10 years ago

There are much more icons available than we currently render, so from a technical perspective, adding extra icons is easy and not much work. The main question is whether we want more icons or not.

matthijsmelissen commented 10 years ago

@gravitystorm you mentioned before that you didn't want to add too many new icons. Could you expand a bit on that? Is that a management issue (you want to divert development effort to more foundational issues) or also a cartographic issue?

kocio-pl commented 10 years ago

I'm also a bit confused between what was said and what I've read:

http://blog.gravitystorm.co.uk/2014/07/07/openstreetmap-carto-workshop/ https://lists.openstreetmap.org/pipermail/tagging/2014-July/018199.html

If Andy is the man who has the power to add such icons and is unsure what is the current direction, it should be easy to see what are the issues claimed by people. But if it will stall for a long time, they may have no interest in trying to do something, when it's lagging too much. I also would like to know what is the current policy and practice on carto.

kocio-pl commented 10 years ago

For now we have waiting 76 amenity-points requests, which make it 25% of all 301 open issues:

https://github.com/gravitystorm/openstreetmap-carto/issues?direction=desc&labels=amenity-points&page=1&sort=created&state=open

gravitystorm commented 10 years ago

I'm also a bit confused between what was said and what I've read:

That's a different person on the mailing list.

kocio-pl commented 10 years ago

Oh, I'm very sorry for such a mistake!...

But still I'd like to understand what you mean by this. I want to have at least one "for mappers" map, but if you don't like new icons, than we already have two general "for visitors" maps (Mapnik+MapQuest Open) and I don't know what's this for.

matthijsmelissen commented 9 years ago

@gravitystorm as I said, we need to make a policy decision, and guidance would be welcome. There are a lot of other issues that depend on this one.

An example policy might be 'we aim to have icons for POI with more than 1000 occurences', for example.

matthijsmelissen commented 9 years ago

I thought about this, and I would like to propose the following guidelines:

  1. The POI needs to be interesting for people who look for this type of POI, rather than this particular POI. For example, people might look for a bakery, without caring which particular bakery, so we render bakery icons. People don't look for nursing homes, at best they look for one particular nursing home (if they bring a visit). Therefore, we don't render nursing home icons.
  2. It must be possible to create an icon for the POI that can be interpreted without having to train the user.
  3. The POI needs to be commonly mapped, let's say over 1000 icons occurrences on taginfo".

Any opinions?

matkoniecz commented 9 years ago

"let's say over 1000 icons" -> "let's say over 1000 occurrences on taginfo"

matthijsmelissen commented 9 years ago

Thanks, fixed.

HolgerJeromin commented 9 years ago

Seems a good start (but readd the number 1000 in your text :-).

"without having to train the user" is a difficult thing. Even the bakery icon could be a problem in a non german/european audience.

matthijsmelissen commented 9 years ago

but readd the number 1000 in your text

Done.

dieterdreist commented 9 years ago

Am 29/lug/2014 um 13:07 schrieb math1985 notifications@github.com:

Any opinions?

to your point 1: I think the idea of utility (find a certain kind of shop because you want to buy bread) should not be the only one, e.g. we are rendering court houses, but it is not likely that there will be many users looking for any kind of courthouse and not a particular one (same is true for prison, school and a lot more). This would IMHO be too narrow as criterion.

matkoniecz commented 9 years ago

I would leave 1 as 1a and add 1b - important places visited by general public. It is likely that someone will want to find some specific court/museum/etc but it less likely for nursing home, prison etc.

It is still not explaining why prison is rendered with an icon.

dieterdreist commented 9 years ago

Any opinions?

setting a hard limit of 1000 also bears some problems. E.g. there is a proposal for obelisks (man_made=obelisk), there aren't 1000 historic monolithic giant obelisks in the world, but every one of them is a prominent landmark worth to be shown with a distinct style on a good map.

matthijsmelissen commented 9 years ago

we are rendering court houses, but it is not likely that there will be many users looking for any kind of courthouse and not a particular one

If we were designing the map from the start, would we render icons for courthouses? I'm not sure.

dieterdreist commented 9 years ago

2014-07-29 16:53 GMT+02:00 math1985 notifications@github.com:

would we render icons for courthouses? I'm not sure.

I would hope so. Courthouses are part of the basic main infrastructure of a society, they tend to be representative (i.e. they stand out) and big (landmarks).

matthijsmelissen commented 9 years ago

We could render them with name, but without icon.

dieterdreist commented 9 years ago

2014-07-29 21:23 GMT+02:00 math1985 notifications@github.com:

We could render them with name, but without icon.

btw., also churches at least partly fall into this category (you often won't search for any church, but for a specific one). No icons?

Rovastar commented 9 years ago

I would worry about adding too many icons. Generally the guidelines are sensible but we should consider them on a case by case basis.

There are some that icons are useful and name maybe less so. Take say fountainsnotable ones will likely be tagged with some sort of other tag, tourism/attraction, etc.

Some have an obvious suitable icon that makes more sense other like hackerspace would be very difficult. Courthouse could a have few different potential icons, gravel, scales, court like build (google court images).

Also if they are likely to be caught by other tags I imagine for man_made=obelisk if notable will again have another tag that we show attached to it. If the name is rendered and a tourism,historic or something is attached I think the need for an exclusive icon or name rendering is less needed if at all.

matthijsmelissen commented 9 years ago

Let's consider this from an other angle: are the objects for which we should definitely not render an icon?

dieterdreist commented 9 years ago

Il giorno 30/lug/2014, alle ore 17:01, Rovastar notifications@github.com ha scritto:

Also if they are likely to be caught by other tags I imagine for man_made=obelisk if notable will again have another tag that we show attached to it.

yes but it could make sense to use a more specific one, eg the more interesting man_made=obelisk will probably have an historic=monument attached to them (this compatibility was also intentional when creating the tag), but the icon for monuments is something like a tombstone or memorial plate, nothing someone would associate with an obelisk.

Rovastar commented 9 years ago

Maybe true but in cases like that I think there is still less need for a specific icon. Then you have to consider a hierarchy of the icons where they conflict.

Rovastar commented 9 years ago

math are you saying what icons we should consider the icons we have at the moment that can be removed?

matthijsmelissen commented 9 years ago

No, I think I made a typo.

I mean: can you think of any objects that are tagged in OSM that would better not be rendered with an icon (on the main map)? Answering that question might help us to improve the guidelines.

Rovastar commented 9 years ago

Stadiums, social clubs, nursing homes,

matthijsmelissen commented 9 years ago

Why can't stadiums have icons? Bing does render them with an icon.

matthijsmelissen commented 9 years ago

And it seems within China, Google renders icons for nursing homes.

Rovastar commented 9 years ago

Does stadium have an icon?! That icon is used all over the place in bing. zoom out a little and you will see it 5 or 6 times. No idea what that icon is for.

daganzdaanda commented 9 years ago

We won't be able to make everyone happy, not until we have a zoom to 21 or more. Or a interface for switching on and off information, like http://www.openstreetbrowser.org/ but with more speed... But the good side of that is, we don't have to try and make everyone happy ;)

What are icons most useful for? a) Quickly showing the location of b) things that don't need a name to be identified

a) works only if the map is not overloaded, b) works if the thing is familiar and the icon is easy to learn: P, bus-stop, restaurant.

On really close up zooms, there could be an icon for everything. We may not need a zoom >19 for that, on 19, the displacement rules will sort out what is shown.

On distant zooms, we should try some order of importance. One way to go is area size. Everything that displays large should have an icon or label. We could have an icon at z14 for large school and university areas, or stadia (ahem...). Large Parkings should become visible before small ones. A national park could have an icon or label on z10.

Then there are important things that may not be large. These could / should overrule the larger, less important ones. I'm thinking of hospital (especially with emergency tags), maybe police.

Small things that aren't much more important than others could be left to the displacement algorithm, or we could make up a hierarchy. Pubs show up at 16, that's nice, but debateable... I wouldn't mind seeing museums at that zoom.

daganzdaanda commented 9 years ago

One more thing: Benches are the top amenity that isn't rendered yet. I think we should try to show benches at z19. But we will either need really small icons (just a dash or square?) or we risk getting a lot less shops named. Alternatively, if it's possible for other labels to obscure benches, then we're fine.

matthijsmelissen commented 9 years ago

@gravitystorm I'm still interested in feedback on this.

brycenesbitt commented 8 years ago

I think it's time to reframe this debate.

POI's, particularly obscure ones, don't clutter the map. Line styles and fills get confusing quickly.

As such I think the "1000 uses" threshold is particularly lacking in vision. It's an electronic map: it can support many constituencies, including small ones.

imagico commented 8 years ago

As @math1985 said the main purpose of displaying POI icons is to allow map users to search for a particular type of feature. This only works if there is a limited set of symbols, if there are thousands of different icons it does not (needle in a haystack problem). With the brown icons this mostly still works, with the purple ones it no more does in most cases (IMO).

matkoniecz commented 8 years ago

main purpose of displaying POI icons is to allow map users to search for a particular type of feature

And second purpose is too recognize object based on icon and context (IMHO works for shop icons like ones added in #1493 and is not working so well in case of some other icons like #1776)

brycenesbitt commented 8 years ago

My main purpose for POI icons is to see what's in an area. I rarely search. OSM is one dataset, but many many uses.

I have no needle in the haystack problem with a multitude of POI types. Rather the opposite. If anyone does have a needle in the haystack problem, that's a problem with the client. It should in search show the most commonly needed options, with a pathway to getting more.

kocio-pl commented 8 years ago

I generally think the same as @brycenesbitt - I don't look for exact objects, I rather want to know what's up there (as much as it's possible) and I think something is wrong when there are holes or just some unidentified structures which don't look like plain buildings. POIs are helping me understand the area along with roads, land colors, names and boundaries. The higher zoom, the more important POIs and icons are.

@imagico

This only works if there is a limited set of symbols, if there are thousands of different icons it does not (needle in a haystack problem).

The map areas and lines also would work better with limited set of road types or land colors, so this argument is universal and works not only for POIs/icons. After all this is the same haystack for every item - try to identify anything other than the icon symbols (it starts with lines description):

http://wiki.openstreetmap.org/wiki/Standard_tile_layer#Lines

and tell if it's any easier for you - for me it's not.

@matkoniecz

And second purpose is too recognize object based on icon and context (IMHO works for shop icons like ones added in #1493 and is not working so well in case of some other icons like #1776)

Which leads me to a question "how does it work now?":

1) How do we know the basket icon means convenience shop and not the:

2) How do we recognize that given area is:

For me all these examples show how much arbitrary some objects are - yet we still use them and it would be hard to find anything better. Of course some symbols/colors are easier: that's why new tree area rendering is better than the old one and why I created new pattern for quarry, we also are trained to recognize the railway, water or churches without any additional clues.

But does it mean we should avoid such generalizations and stop rendering all these "muddy" examples just because there's no way to tell without looking at the cheat sheet what the hell is this green area (other than that it's probably about grass; or some other plants; or the sport; or leisure)? And if we shouldn't - what are the reasons?

BTW: if you don't like the icon for social facilities and want to stick with the name, I'm curious:

I know these questions are tricky, but I think the whole subject is not that easy and that's why I try to be as concrete as possible.

imagico commented 8 years ago

try to identify anything other than the icon symbols (it starts with lines description): http://wiki.openstreetmap.org/wiki/Standard_tile_layer#Lines and tell if it's any easier for you - for me it's not.

Are you kidding?

The line features use a huge variety of different colors, line patterns and combination and more importantly recognizing them has as much to do with the geometry of the line and context as it has with the styling of the lines themselves. The icons OTOH are shown in one of very few color and are always identical.

If you don't believe me just make a test: try shuffling all the shop, food/drink and culture icons in a map and see if it still looks plausible at a quick glance and then try shuffling all the highway and boundary line types.

Compared to other maps the number of fixed design point symbols is already very large in this style. There are good reasons why point symbols are used relatively sparsely in many cartographic designs - they take a lot of space, transport relatively little information and frequently obscure other, more meaningful features which often happen to be located around where the icon is.

brycenesbitt commented 8 years ago

@imagico from my point, I'm not kidding. There are far too many line styles and colors for me to keep track of. Show me one in isolation and I won't be able to tell you what it means.

The lines exist in a context. But so do the icons. A "toilet holding tank dump station" icon in a campground is in context. A bicycle repair stand near bike racks is in context. A road's name gives it context. A POI's name gives it context. And it's an electronic map, should a user be confused the back end support exists to allow a click or swipe to resolve the confusion.

And consider how the "1,000 uses in the database rule" promotes clutter. A common but low utility POI rates higher than a rare but crucial POI.

kocio-pl commented 8 years ago

The line features use a huge variety of different colors, line patterns and combination and more importantly recognizing them has as much to do with the geometry of the line and context as it has with the styling of the lines themselves.

The ultimate context for those lines colors and other features is exactly this "haystack". If you don't believe, try to tell if it's primary or tertiary road with no cheat sheet. Oh - you already know it probably, so the test will fail. But looking just at the map you can also tell "it's probably more important road than the other" or "I guess this road (track) is more solid than the other one", but nothing as exact as you may like. Colors and other elements are not tied to some road features (they are just black, gray or brown in reality), that's why it's possible at all to try a new set.

The icons OTOH are shown in one of very few color and are always identical.

I don't get how the icons are identical to you. They have just similar size (and visual style, if we were able to achieve it! It was great that @nebulon42 started the process of unifying them in this regard). Take just two random icons and if you really see no difference, I think it's rather you who is kidding me...

Compared to other maps the number of fixed design point symbols is already very large in this style.

Because this is how it is in reality. There are many important kinds of "points" (the icons are also used for areas) in the world and we're able to catch and show them, which is great and unique property of OSM!

There are good reasons why point symbols are used relatively sparsely in many cartographic designs - they take a lot of space, transport relatively little information and frequently obscure other, more meaningful features which often happen to be located around where the icon is.

This is very important point, so let's look closely: if the map has low-to-medium zoom level, you have to flush away a lot of things and stick mainly to the areas in the low zoom and lines in the medium zoom. This is not to say that areas are not important on high zoom level (like water) or that there are no important points in the low zoom level (capitals), but you get the pattern.

On the high zoom level the world is much different. Think about what you see with a telescope, a naked eye - and the microscope. You can see no continents now (just a few of them exist), there are only few lines like streets (there are at most a few dozen types of them) and probably few more points - but only in the given box, because there are a lot of them if you add all the boxes.

So - at the high zoom levels (where most of the icons exist!) all these reasons you mentioned are no longer valid. Most of the time you have plenty of rather empty space - no matter how crowded place you'll examine! There's not much to obscure, because points typically don't stack like landuses, for example. And "relatively little information" is, well, really relative - here this is the most interesting thing you can get! We're probably not able to really show the opening hours on any static piece of map with zmax=19, but the name and color are just too general, so the icon is here to tell us more about specific type of this point in a common, uniform way.

For me the reasons you just gave are perfect example of the "scale blindness". When you know what typical map should be, you just seem to ignore the reality of high zoom level maps - which are very different. I'm all for the rules you gave (they are sane and useful), but only when dealing with lower zoom levels - they're unusable outside this scope. Flushing things away is necessary when you have to do it, but it's just wasting the precious informations if you don't. And we have of lot of them in OSM.

The last thing - you're not supposed to know all the icons on the map without additional help if there will be a lot of them. But you're also not supposed to understand all the names in different languages and even know some alphabets we render on the map. How does it limit your ability to use the map? This is the same question which I have asked Mateusz: "how do you plan to recognize such places more accurate in the languages you don't know at all?" (if not using visual symbols like icons).

OSM is not just "my home yard", the world is much bigger and if we want to have as universal map style as it's possible, icons will help us. Let's not be "blind" also for this aspect of scale.

dieterdreist commented 8 years ago

sent from a phone

Am 26.08.2015 um 18:54 schrieb brycenesbitt notifications@github.com:

The lines exist in a context. But so do the icons. A "toilet holding tank dump station" icon in a campground is in context. A bicycle repair stand near bike racks is in context. A road's name gives it context. A POI's name gives it context. And it's an electronic map, should a user be confused the back end support exists to allow a click or swipe to resolve the confusion.

I agree for very high zooms (maybe z19 and higher). Christoph is right for z17 maybe 18 and lower. In very detailed close ups it would indeed be useful to have an icon for "sub-features" that occur inside other features

kocio-pl commented 8 years ago

My idea is rather gradually showing them more or less by their size:

brycenesbitt commented 8 years ago

Some composite icons are possible also.

For example campgrounds may have attributes of fee, drinking_water, toilet dump station. In a real campground you may see a notice board showing a large tent symbol with a series of small symbols for what's available (e.g. toilets / beach / wildlife viewing).

Such an organization gives instant context, and exposes data that presently is not rendered at any zoom.

imagico commented 8 years ago

Some composite icons are possible also.

This is something that can work very well if done well - this is why i wrote fixed design point symbols above - if you make minor variations and additions to the same base shape this is not as cluttering as fully different icons.

The key here is to make the base shape really recognizable. There are a number of recurring base shapes in the current icon set like the car and the bed shape but they occur in very different sizes and variants so are not really recognizable as the same base feature type (and are also often not meant as such).

This technique also usually works best with fairly simple and abstract shapes. Good example are medical symbols - cross within circle, cross within box etc. Such usually require a legend to be understood but once the map user is familiar with them they are very well readable.

kocio-pl commented 8 years ago

Having designed a bunch of icons myself, I think currently we're too constrained technically: 14x14 px is barely enough for one/two symbols (that's why I admire department_store icon!). I guess composite icons could be good on the additional layer (given we have more pixels there), but it's outside the scope of this style.

brycenesbitt commented 8 years ago

Just keep in mind the icon does not do all the "heavy lifting", not when there's a text label. I agree fully that 14x14px is a terrible constraint, and with high DPI desktop displays, really a historic artifact.

nebulon42 commented 8 years ago

14px is great because it prevents you from squeezing in too much. In that vein I think the department store is horrible, although I have so far no better alternative to propose. Note that the 14px were not a magic number I came up with, I started with 16px icons and wanted to have 1px padding. Sometimes 14px is a little tricky and if it would be 16px or 18px, fine. But if you recall the discussion on icon halos (which I still think are really necessary for legibility) there was a lot of concern that 18px is too much.

If you look to Maki they currently even have smaller versions that are used by e.g. iD to display marker symbols. So there could be some need for small icons. Regarding high res displays it is very easy to make icons larger (e.g. double size), but downsizing an icon should be avoided if you don't want to end up with blurry icons. Since we don't serve retina tiles yet (do we?) these constraints are far from becoming historical.

@imagico It would be great if you would be a bit more specific where you see inconsistencies in current shapes. Regarding the car example the only inconsistency I see is the car shop icon. I refrained from changing that because that was already SVG and didn't want to give the impression that I wanted to change everything to "my" icons.

imagico commented 8 years ago

I did not see particular inconsistencies but there are currently relatively few icons that are clearly variants of the same base icon (in contrast to composite icons built from the same base elements). Variants in this sense means the dominating element of the icon is the same in all variants.

The clearest case IMO is shelter/alpine hut. Parking/bicycle parking as well although the 'P' has significantly different proportions in both (the smaller one is notably thicker in lines compared to the character size). In most other symbols with recurring elements the recurring element is not clearly dominating so the effect is different.

kocio-pl commented 8 years ago

Sounds like maybe scaling down the standard (=car) parking icon to be the same as the bicycle/motorcycle would be good indeed. We could also add a car icon to make them more consistent, but I'm not sure if it won't be too strong given how popular car parkings are (600k:60k:60).

nebulon42 commented 8 years ago

@imagico Got your point now. I was thinking of how to best design the "progression" from weather shelter via basic shelter towards alpine hut and onwards to guest house and the like for some time now. So far I have not found a working solution. Alpine hut is not bad, but the hiker is far too detailed for me.

If the motorcycle parking icon was derived from the bicycle parking icon it might be a better idea to upscale that to the general parking icon. In my repository there is also a general parking icon, but I don't remember currently if it is similar to the bicycle parking one. Generally, I always try to reuse shapes as much as possible, but sharpness is - at least for me - an equally important constraint.