Usability : New map openstreetmap-carto is too pale.

[AllroadsNL]

Default map, standard map, the map to control and see "basic tags" off all kind back after mapping.

I use it in JOSM as a background map, like many of us, over that I put some layer(s), which I make transparent, the overlayer becomes pale, inherent because of the transparency process, because the openstreetmap is so pale, above the pale overlayer(s) makes is very difficult to work with. The overlayer transparency must set so low. Comparability in JOSM is lost. The openlayersmap does not shine through like it did before.

The use in JOSM is one of first in line important uses.

This proves that the chosen rendering is not well.

This is a major problem!

We need back the old contrast and deep colors.

I see the default openstreetmap as a control map, a need to use it like that.

I have lots of paper maps, but none has a layout so pale as openstreetmap, why? Are these papermaps factories doing it wrong?

Are there more that find this a problem. If I read the forums they do.

[imagico]

You are not very specific with what you consider 'too pale'. There are recent changes that reduced the overall contrast (in the sense of average brightness variance) of the rendered map and others that increased it. In particular the wood/forest color change reduced it while for example the recent general road color change (that is not yet rolled out) probably increased it. There is also a pending PR regarding farmland color that would significantly increase the contrast (#1701).

But i am not even sure if overall contrast is what you refer to with 'too pale'. In general it would be more helpful if you'd say what colors you think should change.

[matthijsmelissen]

Could you have a look at http://bl.ocks.org/tyrasd/raw/67a00dbb869456094373/#9.00/52.3535/5.0572 again, and let us know:

• Do both the left and right map too pale, or only the left map?
• If only the left map looks too pale, what are the changes exactly that you would like to revert?

[dieterdreist]

sent from a phone

Am 22.09.2015 um 18:55 schrieb Christoph Hormann notifications@github.com:

You are not very specific with what you consider 'too pale'.

I believe a main reason for lack of contrast compared to the old style stems from the decision to not render residential roads on lower zooms, leaving just landuse as background for the arterial roads. The old style had very deliberately created a kind of builtup polygon effect by the mass of residential roads merging into one 'blob'

An alternative could be the rendering of place polygons in a relatively dark gray

[matthijsmelissen]

I doubt the effect was deliberate actually.

An alternative could be the rendering of place polygons in a relatively dark gray

That's basically #1755.

[jojo4u]

Do we have some tileserver with an older version of the style?

[matkoniecz]

Do we have some tileserver with an older version of the style?

http://bl.ocks.org/tyrasd/raw/67a00dbb869456094373/#9.00/52.0761/5.0716 - with limited area http://bl.ocks.org/tyrasd/6164696 - used to work but it no longer compares with the old version

[AllroadsNL]

Specific: It is more the overall view of the map, that is to pale, that is also specific. Of course all elements has there own effect on the overall view. The end product. That is been criticized. It is too much asked from me to say 1 element does the trick. Green is present, but that is the character of that color, building is now less, building corners are target points to set a piclayer( transparentoverlayer).

So it is not easy to say this element makes the different, it is the combination. Big elements have more impact, so landuse have more impact. When there are so much element changed over the past month, maybe little changes in other polygon elements to match color with, for example forest layer, there must be a harmony between colors, I believe the overall harmony is set to pale.

@ math1985 Where used to, I believe, the right one, in the past on the openstreetmap and in JOSM in the example of you (Math1985. the NL example). The left one is pale, just try/imagined to drop over this one overlayer, piclayer, make it transparent. Then we take usability. The other way a much deeper intense map, we do not have as a comparison, Maybe the right one was already on the pale side, I can not tell, but believe not. If that not existing intense map should work better in JOSM

See for yourself, math1985 comparison, example says it.

I do not know how the evolution started, I read roads, if you give roads a more pale looking line and then say, ohhh, landuse must be not so intense, the roads must come out more, the pallet you choose, saw some pallets, nice the say, but does it work, then you go the way to a more pale looking map.

What was the purpose in the beginning. Where to end with the product.

Working in JOSM, I catched myself, with the new map, that i go more forward to watch the screen. And I use a special pc glasses, to sit back range 60 -120 cm, multiple screens. Have you thought about colorblind people, how they see the map. I have no experience with that.

You all have put a lot of effort in to it, I appreciate that, respect, but it is the end product that counts, usability in other products like JOSM, our own, maybe back to the drawing table.

I find that the old map has a openstreetmap character, it was not so bad, overall view, with new map it is lessssss.

[matthijsmelissen]

Unfortunately, I still don't see exactly what you mean. I'm afraid your current comments are too general to be useful to serve as a base for changes. I'll therefore close this issue - but feel free to create new issues for more specific comments.

[AllroadsNL]

Specific: the overall view is to pale, that is very specific/direct and the usability of this pale map is a problem in JOSM.

I explained that. Did you try it in JOSM? It is about putting a transparent paper layer over the new and old map, which map do you see better through the transparent paper and recognize the underlying data.

I am not commenting general, I say the used color pallet is to pale. This gives a pale map in the end. That is the problem!

And this is 5 hours open, let others comment, give others the possibility. Why must it be closed so quickly?

You do not understand "pale", a white look.

[matkoniecz]

Somebody on Polish forum had a similar idea (increase contrast and decrease brightness) and provided mockups - see http://forum.openstreetmap.org/viewtopic.php?pid=527470#p527470

I am not convinced that changed map is better (it is simply ugly), though maybe something less extreme would improve map.

[AllroadsNL]

For me it is about usability in JOSM, as a example, when putting over these maps a transparent layer. Yes, maybe this is to extreme. Above pics. And this is a pic that is totally turned in contrast and brightness, this gives a deviation in comparison when, if you changed every color separately.

About color blindness, I said, no experience, a bit I think about that also. I use in chrome, for comparison my draws, the extension, search for "See" from Q42, there you can switch this page to a colorblind version. Trying to image how these people see it at some blind levels. Compare above pics, every colorblindness category. Here, too pale is not good.

[gravitystorm]

It is more the overall view of the map, that is to pale, that is also specific.

That's not being specific, that's making a general comment. I'm not saying that you are wrong, it's just that when you make a general comment, and a maintainer asks you to be more specific, you can't just restate your general comment and claim that it is specific.

For example, religious icons, trams and place labels are all black. So they can't really be too pale. Shop icons are intense purple. I doubt that you think they are too pale. We haven't changed the water colour, but is that somehow now too pale?

So when we ask you to be specific, please actually be specific and refer to actual features of the map. Otherwise your comments won't lead to any improvements.

For me it is about usability in JOSM, as a example, when putting over these maps a transparent layer.

Can you please post a screenshot of JOSM showing your problem? I note, however, that we aren't designing the map with the aim of the contrast being further reduced by using transparency.

[kocio-pl]

That's not being specific, that's making a general comment. I'm not saying that you are wrong, it's just that when you make a general comment, and a maintainer asks you to be more specific, you can't just restate your general comment and claim that it is specific.

:+1:

I would re-open this issue, because I think of it as a proper meta-issue (which is broad and generic by definition), but only if @AllroadsNL is planning to make the more detailed issues and deal with discussing them. Otherwise it should stay closed.

[matthijsmelissen]

Are there others who agree with @AllroadsNL's observation that the map is too pale?

[SomeoneElseOSM]

The lack of visibility of footpaths as currently rendered over other features has been mentioned before (https://github.com/gravitystorm/openstreetmap-carto/pull/747#issuecomment-49991607 is one example, I'm sure there are others). The rendering of "path" as "footway" has made that effect more widespread.

As another example, it might be useful to look how the rendering of a tile (http://tile.openstreetmap.org/13/4061/2666.png) has changed between April 2014 and now.

April 2014:

September 2015:

(ignore the missing boundaries and tracks in the "old" one - that's a quirk of the database used)

Is it specific enough to say that "footpaths and tracks were more visible, particularly over woodland, before than they are now"?

@matkoniecz 's link https://github.com/gravitystorm/openstreetmap-carto/issues/1863#issuecomment-142501442 above is interesting - it's clearly much more easy to distinguish features in there than it is the current osm.org version. Whether it looks "ugly" or not (or whether that is even a problem) is an entirely different issue (see e.g. https://github.com/gravitystorm/openstreetmap-carto/pull/747#issuecomment-50188728 and comments down from there).

In answer to https://github.com/gravitystorm/openstreetmap-carto/issues/1863#issuecomment-142581507 above, a quick search of issues finds lots https://github.com/gravitystorm/openstreetmap-carto/search?utf8=%E2%9C%93&q=visibility+issues&type=Issues .

It's a little disingenuous to dismiss criticism as "not specific enough" when attempts to address specific problems have in the path just been closed down (see abandoned railways ad nauseam). A more honest answer would be "we've decided to do it this way after looking at the pros and cons; sorry it doesn't work for you; no one map can work for everyone - here are some other options".

I personally don't believe that one map rendering can do all of "being the primary feedback to mappers", "being a usable general-purpose map" and "looking nice". The current style seems to be targetting the third of these far better than the other two.

[imagico]

Are there others who agree with @AllroadsNL's observation that the map is too pale?

Not across the board but there are several cases where the map does not make optimal use of the limited color range available. As @gravitystorm pointed out in the urban context there are a lot of features in strong and dark colors and while there are certainly cases of less than optimal priorities (less important things in strong colors and important things too weak) these are mostly fine. But in the rural environment and at lower zooms there is room for improvement beyond #1755 and 1701. I could also say: the demo by @matkoniecz shown above - as ugly as it may be - would probably improve readability at low zoom and in rural areas in many cases but the map would be definitely worse in urban areas.

In general with colors at the lower zooms being the same as on high zooms but line widths being smaller contrast of the map is reduced and this is a problem. In case of area colors there is also the problem that there are several fairly bright area colors, in particular park, campsite and playground that are mostly used on fairly small areas while grass, which is widely used on large areas, is significantly darker. Changing this could contribute to a more contrasty overall appearance.

[matthijsmelissen]

Opened for further discussion - however note that this discussion will need to lead to actionable comments. I'll close this again if/when we don't find any aspects on which we can take actions.

[AllroadsNL]

Josm and a overlay, municipality map, new junctions of a white jpg with black blue lines as a example.

basemap Osm default standard

map Osm NL as in math's link

[AllroadsNL]

People who have colorblindness. Just a few examples how it is visualized for us. Took some category and stage

The pics from above replaced for a better compare https://cloud.githubusercontent.com/assets/899988/10038535/b3e82038-61c7-11e5-9bb2-11d9d998daf1.jpg https://cloud.githubusercontent.com/assets/899988/10038536/b4f1a634-61c7-11e5-9874-e89d4ef5e077.jpg

Achromatopsy

Protanomaly

[polarbearing]

The advantage of OSM is that things can be rendered in different ways. With the improvements in the code to define colours as variables, it should be relatively easy to automatically fork a version for high contrast or other special needs. There are already projects that print a tactile map sheet for the fully blind from OSM data.

[AllroadsNL]

But the account page is the page openstreetmap.org, this is the page/map for us all. A own rendered map is not possible there and many of us mappers do not have the knowledge to set up such a page or the time. All links to nodes, ways and relations from many programs are linked to that page, so every time, every one, see this map. That why this is a important map.

[kocio-pl]

These are the things I've been researching a bit lately and my conclusion is that we have two general problems:

1) Standard web page is primary just a map, while we could also tell the mappers more about our mission, community and tools (like TagInfo or KeepRight) and the users about additional useful services (like UMap). 2) Standard style is a compromise between being clean and packed with features.

First one is easier: we can redesign OSM.org to be more like a universal OSM portal and create subpages like /map, /users, /community, /developers or /tools. It takes some effort to do this and some more to convince people this change would make it better, but it's perfectly doable.

Second one is much harder. Our database is so huge, that we have not enough resources to bring more than one style covering the whole world. There is some hope in adding dynamic overlays, but I guess the ultimate solution would be to have vector tiles with many dynamically applied styles, just like the popular HTML+CSS combo, which is interpreted by the client (in osm-carto we apply the style on the server and we produce raster tiles). However it means we need a vector tiles server to begin with and we still doesn't have one, so I wait until we can afford it or somebody else will offer it for us to use (like HOT offering their own style).

By the way: JOSM uses both approaches - it shows vector data with local styling, which you can easily change, but you can also show the static raster map or aerial images below, which makes data layer a dynamic overlay.

[sommerluk]

Are there others who agree with @AllroadsNL's observation that the map is too pale?

Well, as you have asked for opinions, here is my opinion:

I have the same impression as @AllroadsNL when I look at map: It seems pale to me. And it feels boring. This may be subjective and everyone has a slightly different impression, but I think that quite some more people feel the same – specially when comparing openstreetmap-carto to other map styles.

The reason for the pale impression are usually the background colours of big areas at a given zoom level. This are the ocean and the basic land colour on low zoom levels. When zoom levels raise, the colour of areas like lakes, residential areas, industrial areas, parks and even buildings gets important. (Symbols though are small and do not give a coloured impression to the hole map if the background areas are pale.)

However, I do not think that the pale impression is bad. I think it is good that the map is pale and boring. It is maybe like a letter. You can write a letter with “Times New Roman”. Or you can write a letter with “Comic Sans”. When you write a letter in “Comic Sans”, people will probably notice you unusual “fancy” font choise. But when you use the boring “Times New Roman”, than probably nobody will even think about the font you have choosen. Instead, the reader will completly focus on the content of your letter. Note that, also if “Times New Roman” seems more boring, it is the better font and it takes a lot more work to make a font like “Times New Roman” than to make a font like “Comic Sans”.

And so it should also be for openstreetmap-carto. This map style shows more elements than many other map styles. This can only work well, when the overall impression is not too noisy, not too “loud”. And I think that this style does a pretty good job. Contrary to this, when I see the colour-tuned example proposal that @matkoniecz has taken from the polish forum, than I have the impression the the map is screaming to me, and it is more difficult for me to orient myself on the map: it is harder to read, and it is harder to find a specific element you are searching for.

If a map is readable depends heavily on the use case. I agree that the way @AllroadsNL is using openstreetmap-carto in JOSM does not give a good result. But I do not think that this is the principal use case of openstreetmap-carto, and making it more colourfull just to satisfy a quiete unusual use case would mean a lower quality for the main use cases of this style. Also making this style be suitable for people with (partial) colourblindness would be a very special use case, and it would mean to use only some very extreme colours and reduce dramatically the choise of “allowed” colours, which would mean that we would have to render/support less elements and make the map harder to read for all people that have not colourblindness. I would not too much consider these very special use cases.

Nevertheless maybe it would be a good idea to make the map a little bit (!) more colourfull, more joyfull. This would make it more attractive – but only if the modifications are only slightly (otherwise the readability suffers)! Probably forest, farmland and water background colours would be usefull candidates for some coloufull fine tuning at medium zoom levels and parks and other green features and buildings (and maybe even residential areas) on high zoom levels.

PS: Note that also the new road style will bring a fresh breeze of colour …

[gravitystorm]

I just wanted to jump in with one observation that hasn't been made. When we started recolouring the map we had all kinds of different colours and no method to the jumble - trunk roads couldn't be seen in forests, sports centres were (are) more brightly coloured than points of interest, etc. So my idea was, and still is, to bring a rough order of precedence to the colouring, namely polygons < lines < icons and labels. Given the size of polygons compared to other features, it's natural for them to be less eye-catching, otherwise they dominate the map and it's really hard to find linear or point features among them.

Of course, there is some subtlety between "less eye-catching" and "pale". For example, a pure white line can be eye-catching, or a pale line on a darker colour. There are also lots of subtleties around pale-and-interesting colours, or light-and-vibrant, or grey-and-boring. So it's really hard to generalise about this topic.

I think there's still a lot of work to do, even just to finish sorting out our colours into a useful range, before we worry too much about whether the overall result is too pale or not. Certainly we've made the polygons paler, to make the roads stand out more, but with recolouring of roads that's likely to open up more range to adapt to.

[kocio-pl]

So my idea was, and still is, to bring a rough order of precedence to the colouring, namely polygons < lines < icons and labels.

I have already noted myself that at least icons+labels are more intense than polygons (I'm not sure if the lines are really between) and I like this approach, I was however not aware that it's deliberate feature, but I like it even more.

[matthijsmelissen]

Note that #1882 reported the opposite of this issue - the user there prefers the HOT style because 'the colours are softer'.

[Rovastar]

@AllroadsNL

No idea what you are doing to get those screenshots but changing the opacity in JOSM for the various layers (osm layer and data layer for example) will result normal "brightness" for the map style.

I suggest you ask on the JOSM message areas for more information about how to use the product.

[AllroadsNL]

The screenshots above, the osmlayer basic layer underneath is full color, no adjust opacity, only the on top/above piclayer is adjust in opacity, to let the osmlayer shine through. To adjust the pic, because this one have no geodata. Above that is the "data layer 1" in JOSM

https://www.youtube.com/watch?v=Jn-2awm3bYU

[mboeringa]

No idea what you are doing to get those screenshots but changing the opacity in JOSM for the various layers (osm layer and data layer for example) will result normal "brightness" for the map style.

I suggest you ask on the JOSM message areas for more information about how to use the product.

+ 1 You need to adjust the opacity of the overlay. Complaining here about about muted pale colors, while using another application that overlays data in a non 100% transparent manner using an apparently white base color, seems counter intuitive...

[AllroadsNL]

"looks like" counter intuitive, but some maps of construction roads, we get it this way as a pic (non geocoded) from several municipality, these are the first maps, to put new part of roads on the map, bing comes later with aerial view. But you can not turn down the opacity of a overlay to much then the overlay is not visible enough. It is about the best balance to work with. When the basemap (osm) is too pale (general) but also important objects ( you know. there in the right spot to Geo-reference), you need to decrease the opacity more than with a more intense map.

This was one example of use.

[drkludge]

On Thu, Sep 24, 2015 at 4:20 AM, kocio-pl notifications@github.com wrote:

These are the things I've been researching a bit lately and my conclusion is that we have two general problems:

1) Standard web page is primary just a map, while we could also tell the mappers more about our mission, community and tools (like TagInfo or KeepRight) and the users about additional useful services (like UMap). 2) Standard style is a compromise between being clean and packed with features.

First one is easier: we can redesign OSM.org to be more like a universal OSM portal and create subpages like /map, /users, /community, /developers or /tools. It takes some effort to do this and some more to convince people this change would make it better, but it's perfectly doable.

This is a good idea but I do not believe that's the problem. The front page was already designed once. The original site had a left menu that hooked into the wiki and the rest of community. I don't recall if the main wiki page was redesigned at the same time. The editing tools have improved dramatically since 2012. I don't see the need to give the GPS traces such a prominent place with the editor tool improvements. Where I do agree with you is that a new drop down menu of Keepright, OSMInspector, ITOWorld, specialized maps like the railroad map. http://wiki.openstreetmap.org/wiki/Talk:Main_Page#Proposed_changes_Jan_2012

Second one is much harder. Our database is so huge, that we have not enough resources to bring more than one style covering the whole world.

Is this a serious reason? What happened to the $56K UK that was raised to resolve this problem. https://blog.openstreetmap.org/2015/06/24/target-reached-thank-you/

There is some hope in adding dynamic overlays, but I guess the ultimate

solution would be to have vector tiles which many dynamically applied styles, just like the popular HTML+CSS combo, which is interpreted by the client (in osm-carto we apply the style on the server and we produce raster tiles). However it means we need a vector tiles server to begin with and we still doesn't have it, so I wait until we can afford it or somebody else will offer it for us to use (like HOT offering their own style).

Once again I do not agree with all that you are saying. I always wondered why the OSM data was converted to row upon row of data in a wide table. My guess is that hstore did not come along until after the Mapnik render chain started. Adding column after column to the render row to support another feature felt brittle to me. I don't know where the hstore change is at. If it is close or already in production, then all of a sudden all you need is one dataset to support several renderings of the same data.

Vector tiles will not solve the too pale problem. I think that it is great that the cartographers are working to improve the map. You get to experiment in order to make things better. I have great hopes for what you are doing. The problem is that I don't believe that you encourage me to map more features. You see along time ago there was a render system called TAH or Tiles At Home. The tiles were butt ugly but effective. http://wiki.openstreetmap.org/wiki/Tiles@home

That render chain render change supported traffic calming, for example. It was magic when I saw my first traffic_calming=hump render on osm.org. That inspired me into an "Easter Egg Hunt" during my TIGER fixup efforts. You can see the impact on the data that was added via one of the those ITOWorld maps that I mentioned above. http://www.itoworld.com/map/239?lon=-112.02719&lat=33.55815&zoom=11 There were other butt ugly features like a baseball player would show up when you added sport=baseball to leisure=pitch. That was magic to drive mapping forward.

The problem is that when a request comes in to lighten, say, the power tags to a lighter shade, it feels like the request went way off course. I still don't understand why after over 10 years, I still cannot get a stop sign or a yield/give way sign to render on a street related map. https://github.com/gravitystorm/openstreetmap-carto/issues/1683 Then policies like "add one feature; take one feature off the map" are purposed. https://github.com/gravitystorm/openstreetmap-carto/issues/1630 Taginfo says that there are already twice as many stop signs as pubs. However, if pubs were removed to add stops signs, there would be a violent revolution.

Like I said, you guys have the right to experiment. However, you are not giving mappers tools like TAH did to drive mapping forward. If you do not understand the importance of showing even more features and how the pale tiles are are a setback to making a usable map for mappers, then using vector tiles and dynamically applied styles will only present the same pale tiles from a different format. We have Stamen minimalist maps, we have MapBox minimalist maps, and four kinds-of minimalist maps on www.osm.org. These are all beautiful maps!! We need some butt ugly tiles that only a mother would put on her fridge and be proud of. We need some butt ugly tiles that would drive mappers to add even more data to the database because the mapper is rewarded with a feature showing up on www.osm.org. Simple features like stop signs and street lamps would provide great sport for new mappers to add to the map without damaging complex areas that having already been mapped.

Regards, Greg

[dieterdreist]

2015-09-30 23:46 GMT+02:00 AllroadsNL notifications@github.com:

"looks like" counter intuitive, but some maps of construction roads, we get it this way as a pic (non geocoded) from several municipality, these are the first maps, to put new part of roads on the map, bing comes later with aerial view. But you can not turn down the opacity of a overlay to much then the overlay is not visible enough.

I don't think that your very special use case should be reason for the osm-carto team to adapt this style. My guess is that there are far more people who need a pale style for background maps on which they overlay POI data. I do agree that a little more contrast between settlements and open landscape would be desirable though. For your use case I suggest you file a ticket on the JOSM trac asking for different overlay modes, and/or masking. E.g. with these you could mix the overlay layer with "multiply" mode or mask white color, both leading to completely vanishing of the white (or any other color) without changing the look of the underlying colors.

[gravitystorm]

Is this a serious reason? What happened to the $56K UK that was raised to resolve this problem.

That wasn't raised in order to support multiple styles on OSMF hardware, it was raised for other purposes.

I still don't understand why after over 10 years, I still cannot get a stop sign or a yield/give way sign to render on a street related map.

If there's something specialist that you want to see, make your own map and add it to the www.osm.org page.

Like I said, you guys have the right to experiment. However, you are not giving mappers tools like TAH did to drive mapping forward. If you do not understand the importance [...]

It's really bad to have a "you guys" attitude. We're all working together, it's not an us vs them thing.

Not everyone can be satisfied with just one map style, hence why there are multiple map styles on the www.osm.org front page.

In this repo, we're concentrating on this style, with the goals outlined here. If you want a "butt ugly" style, put a team together and make one, but don't come here haranguing us for trying to make a nice style.

The more styles the better.

[gravitystorm]

Right, from all the comments here, it's clear that it's not becoming productive i.e. nobody is listing specific changes that need to be made. So I'm closing this issue.

If you have a change, or a set of changes, that you want to see happen, then I welcome pull requests.

[kocio-pl]

I think we can continue the general discussion somewhere else, probably on Talk list, and come back here once we have something more specific, which can result in a working code.