Guidelines on adding new icons #660
Comments
|
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. |
|
@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? |
|
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/ 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. |
|
For now we have waiting 76 amenity-points requests, which make it 25% of all 301 open issues: |
That's a different person on the mailing list. |
|
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. |
|
@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. |
|
I thought about this, and I would like to propose the following guidelines:
Any opinions? |
|
"let's say over 1000 icons" -> "let's say over 1000 occurrences on taginfo" |
|
Thanks, fixed. |
|
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. |
Done. |
to your point 1: |
|
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. |
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. |
If we were designing the map from the start, would we render icons for courthouses? I'm not sure. |
|
2014-07-29 16:53 GMT+02:00 math1985 [email protected]:
I would hope so. Courthouses are part of the basic main infrastructure of a |
|
We could render them with name, but without icon. |
|
2014-07-29 21:23 GMT+02:00 math1985 [email protected]:
btw., also churches at least partly fall into this category (you often |
|
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. |
|
Let's consider this from an other angle: are the objects for which we should definitely not render an icon? |
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. |
|
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. |
|
math |
|
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. |
|
I think it's time to reframe this debate. POI's, particularly obscure ones, don't clutter the map. 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. |
|
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). |
|
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.
|
|
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.
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.
Which leads me to a question "how does it work now?":
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. |
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. |
|
@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. |
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.
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...
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!
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. |
|
sent from a phone
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 |
|
My idea is rather gradually showing them more or less by their size:
|
|
Some composite icons are possible also. For example campgrounds may have attributes of fee, drinking_water, toilet Such an organization gives instant context, and exposes data that presently |
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. |
|
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. |
|
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.
|
|
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. |
|
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. |
|
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). |
|
@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. |
I admire this icon simply because it managed to squeeze so much things, yet I can read it easily. But I don't think it couldn't be made in a different way. Maybe you could try with two other left/right halves (half the basket, half the shirt for example)?
Just my position: I don't have a problem with the authorship - if I like it more than the previous one, it's just better, but if I think it's not readable enough (this is the only thing which I don't like in some of your drafts), I will try to propose something different or vote the change down. In general you gave this style a lot of visual consistency, and that's what I like here a lot. And sometimes just your fresh idea is what helps to make a progress. In a nutshell: don't be shy (unless you just don't like to discuss another item to death 😉). |
|
I have been thinking a bit more about the principles behind this. I think there are about three uses of icons in cartography. With each of the uses, I have indicated some questions map users might have, and how the map could answer them.
In addition, in the context of OSM, it is also important to be able to check whether a particular feature has been mapped already (mapper feedback loop). All these uses are probably somewhat conflicting. For example, schools will not be often used as a target, but as a landmark they can be quite handy. Probably (and hopefully) they also lead to common requirements. In my opinion, our map is not that useful for using icons as targets. Because there are so many different types of icons, it is really hard to find, for example, a bakery in a fully mapped city centre. On the other hand, because a user might have so many different types of targets, it is also not that easy to get this right on a static map like ours. We could improve on this by dropping icons for features that users are less likely to search for, such as mobile phone stores, and maybe even clothes stores etc. Also a smart use of colour could contribute. Because of maps with dynamic icons and search functions (in OsmAnd), using icons as targets will likely become less important in the future. I think we are doing slightly better with using icons as landmarks. Up to z16, we only render icons for things that tend to be more important as landmarks on a larger scale, such as churches, museums, and theatres. We could still improve on this by not rendering very minor museums and theatres based on area size on z16. On z17, icons in big cities are not so useful as landmarks, because there is just rendered too much, and it is impossible to tell what is important. On this zoom level, for this purpose it might make sense to drop some types of icons. I would say that from z18 on, things get a bit better again, because at that scale, any shop can serve as a landmark. I think we are also not too bad with using icons as area descriptors. One of the problems for this use, is that icons like mailboxes, water taps, etc. are unnecessary on z17 and maybe even z18. For the mapper feedback loop, it would be useful to add even more features. For example, public_buildings, artworks, and social_facility's are currently not rendered at all. However, rendering them only at (very) high zoomlevels would suffice. Probably other/smarter people have been thinking about this before me, does anyone have a recommendation where I can read more about this topic? |
|
Great analysis, thanks! In general I support your observations. I also think we're not able to act effectively in terms of "targets" - we should give it up to the other, dynamic tools. I'm not sure what is the difference between "landmark" and "description" - I guess it may be about easy to spot objects (landmarks) vs general properties and both deserve our attention. I was thinking lately about dropping some objects from z17, which tends to be the most busy level and causing most of the discussions. The easiest action would be to demote specific shop icons one level down and instead show just the dots on z17. This would be consistent with my idea of using z18 for smaller amenities and z19 for "the rest", because just dropping shops completely from z17 would not allow us to show the scale more accurately. Yet my idea of having some system was neglected by @imagico and I have no idea what to do with it. I wanted to use a typical size as the most neutral measure I could think of, with importance as a "modifier", because it's more subjective and harder to rank, but unreasonable to completely avoid it. So we're stuck with it currently, because no other system was proposed, just a subjective list of important objects, which unfortunately is completely different. I could also think of of adding more features in z18 and z19, which are rather safe from the danger of being overloaded, to satisfy mappers' needs, but for example @matkoniecz says he just doesn't like having more icons (no matter what the zoom level). So while I have an idea how to render artworks (which can be landmarks in parks for example), I don't know if it won't be just wasting my time trying and I'm stuck here too. The same for education icons, which are now ready, but I had some technical problems rendering them properly, so I gave up for the same reasons. In my opinion lack of any system is the most important obstacle for adding anything now. It looks like the coding side makes it also hard (more code lines and performance issues, which was reported by @pnorman lately). Some problems with icons could be solved by taking the context into account, but it also was rather not welcomed because of expected complexity. So, I share your vision, but there are multiple practical problems I don't know how to solve. |
|
We have detailed discussion about each icon in certain tickets. There is also a guideline in |
|
It can be extended to cover more problems from original report, but let's reopen it then - or open more specific discussion, since guidelines is strictly related to discussing policies. |
|
BTW: there's a set of raster icons from (ex-)Mapzen to help designing new shapes: |
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.
The text was updated successfully, but these errors were encountered: