Yes, JOSM does it correctly, if you do it like JOSM you should be fine.

That is a very nice video, especially in the beginning where it explains the core of what OpenStreetMap is about, i.e. people mapping their environment and sharing their knowledge of the world with others.

I want to point out however that the narrative that both OSM and HOT are about creating “a free map of the world”, which also was mentioned several times in recent discussions in some form, is not really correct. For me as someone who has mapped primarily in those areas in OSM that are probably most distant from this potential goal this seems pretty clear. For OSM the map of the whole world would be the ultimate conclusion when everyone on earth has become a mapper and is contributing his/her knowledge to the OSM database. But this does not make it a goal of the project, OSM is about the process of collecting data and sharing knowledge.

And for HOT the map of the whole world seems to be no goal either, HOT is about generating free map data where map data is needed, either actutely in case of a desaster/crisis or prophylactically where it might be needed in the future. In any case HOT mapping is generally based on data needs by specific interested parties (that is mostly the aid organizations HOT cooperates with). And these parties generally do not have a need for a “map of the world”, there are huge parts of the world, both geographically and thematically, they have no interest in at all.

One problem of NHD as well as other waterbody imports is that river/stream classification is often either off or completely missing and this is often very difficult to assess properly from imagery alone.

Your observations re. accuracy comply with what i experienced with NHD data. This is very variable, both in terms of positional accuracy and age of the data. In some areas NHD data is clearly very old (probably 1950s-1960s).

With your ‘data efficiency analysis’ - make sure when you apply this worldwide you take into account projection distortion, otherwise you probably end up with very wrong results at high latitudes.

JOSM could by default offer a scale independent simplification (using the node density along the line to set the simplification threshold).

I suspect one major problem of your methodology is that quite a few mappers start off with either a remote mapping changeset (which does not necessarily have to be part of a HOT project etc.) or mapping in a location away from home (during vacation for example). This will probably not significantly affect numbers for countries like Germany or the USA but it will likely overestimate the number of mappers in countries with a low number of mappers.

There are two important things you analysis misses i think:

• In addition to Mapbox Streets there are also other styles that use preprocessing. Like OpenTopoMap In fact you could say through the coastlines all styles make some use of external data preprocessing that is based on additional code. This is of course the same for all styles.
• In addition code complexity is largely influenced by the feature set offered by the underlying software. Styles vary in what versions of the various tools they require for example and if they use custom extensions (like for PostGIS). Quite a lot of the code complexity in osm-carto is there to work around limitations of the capabilities of the software used.
• many styles use external non-osm data which often essentially means externalizing processing complexity.

Small recommendation: if you show images of non-urban areas for educative purposes it usually helps to include a scale bar.

In general node distance only tells one side of the story since there are fairly straight roads that require few nodes for accurate representation and curved roads that would be extremely inaccurate with the same node density. So it is usually best to also look at the average derivation angle at the nodes, see here for an example for that.

By the way - is that spherical/ellipsoidal distance or in mercator meters?

General roads look quite fine now. Would be even better with the brighter farmland of course. ;-)

The new pedestrian color you tried looks very close to landuse=residential.

I am worried about collision with water.

I don’t think that’s a problem as long as you keep it bright enough and on the reddish side of blue - water color is quite greenish.

For pedestrian areas - you could try something slightly blueish placing it somewhere between residential and retail, like:

The weaker shields are better but you should probably make sure the visibility is strictly decreasing with decreasing highway size - currently secondary appears slightly stronger than primary.

And the secondary shield color is fairly close to heath color due to the secondary color already leaning towards green.

Looks fairly good to me - two remarks:

• At z=7/8 where you don’t have minor roads in gray you could sightly lighten the railways to avoid them appearing too strong.
• The secondary road yellow fill looks somewhat extreme at the higher zooms - i hope there is room for making it somewhat more like the old teritary with the lighter farmland color.

Ok - will try to explain briefly on the problem of too strong colors.

Your original choice of colors was a selection of moderately bright, moderately strong red-orange-yellow tones. These form a distinct unit within the color palette of the style that is not much used for other elements. This makes them work quite well. Problems arise (as you noticed) primarily where this set of colors is farily close to area colors used elsewhere, most notably things like beach and farmland.

Now when you make the colors stronger, i.e. move each of the colors closer to the color space edge you increase the distance between the different road colors. This means the color palette for the roads no more forms a clear unit within the overall color palette of the style. The perceptual distance between your new motorway red and the new secondary road yellow is so large for example that each of the various road colors is probably closer to a whole bunch of other colors of the style than to the other road colors. All the advantages of moving from the full color red-green-blue scheme to a more compact set of colors are gone.

A good collection of various sources with background information on color design and some specific discussions of rainbow palettes can be found on:

http://earthobservatory.nasa.gov/blogs/elegantfigures/2013/09/10/subtleties-of-color-part-6-of-6/

My specific suggestions here would be:

• stay with your previous choice of colors as a starting point
• give up the idea of using the same color for high zoom casing and for low zoom fill - this gives you more options to adjust things, in particular for the yellows
• try tweaking the farmland color. As previously discussed this is tricky since there are several other colors closeby that constrain you.
• don’t test for ‘bad eyesight’ - sounds unfair but this is about optimizing understandability vs. optimizing readability. The primary reason for people using rainbow palettes is because they think by using all available colors they can transport more information than otherwise. But this is of no use if can’t undestand the information. And basic readability is always an artificially constrained problem with interactive maps - if you can’t read it you can always zoom in to get a better view.

Regarding buildings: Since size of actual buildings follows a very distinct statistical distribution the idea to find a position within that distribution that approximately separates the large mass of small buildings from the few bigger ones could work. But this will of course fail badly with a way_area cutoff due to the scale variation in the map.

I have to say i lost track with all your different color scheme variants. Some of your new examples look much too strong in color for my taste. Choosing colors that are well visible next to the other colors used in the style is one thing, having colors that are far outside the range of colors used in the style otherwise another. The problem of having too many colors that are not individually recognizable is not going to be solved by using more extreme colors. This just adds to the confusion and makes it impossible to correctly group the different colors mentally (the well known rainbow palette syndrome).

Regarding urban landuse - currently rendering of the natural earth builtup areas at z=8/9 is brighter than the landuse=residential at higher zooms so it will probably not work so well to darken this at the intermediate zooms. Unifying the different landuses (residential/commercial/retail/industrial) into a common gray at z=10/11 might be a good idea though.

Have you looked into the possibility of using a grained fill pattern to indicate unpaved roads? From my point of view it seems the only possibility to do that with the current toolchain is to generate polygon geometries from SQL with ST_Buffer() but this might not be too bad performance wise. And optically this could really be a very good solution.

I do not think the dashed fill works so well. Intuitively dashed line signatures tend to indicate some global abstract difference (like legal restrictions, underground location etc. for roads) and not local properties. And in general dashed lines where the dash length is not much larger than the line width often work poorly IMO. Using a kind of dotted line would probably look better but neither seems a very good solution to me.

For z=12 i think if you don’t show minor roads you also should not show buildings.

My understanding of the difference between highway=path and highway=footway without further tags is that footway is meant for ways contructed for use by pedestrians along its whole length (but not necessarily paved) while path is used for ways where rudimentary construction work might have been done to enable safe use but that are largely ways just established by use, for example a way across a meadow that exists simply because a lot of people frequently walk there. Many uses of these tags match this distinction quite well although i am sure there are also many examples contradicting it.

Removal of the minor roads at the lower zooms seems like a good idea, this will also encourage mapping urban land uses (which is missing in a lot of cities at the moment). Likewise for thinning the roads a bit at intermediate zooms. These two things are however strongly a matter of map scale - both lead probably to a huge improvement at low latitudes but probably less so at high latitudes (try Murmansk as an example for that). Hiding residential but showing unclassified might also improve consistency in use of these tags although due to the above it might also lead to a systematic difference in use of these tags depending on latitude (high latitude mappers might use unclassified in residential areas for example to make them show up).

Blue is a common colour worldwide for motorway signage, hence the use in maps.

Maybe it is worldwide standard for motorway signage but it certainly is not a worldwide standard for marking motorways on maps.

FWIW it is not an universal standard for signs either - there is probably some kind of EU regulation for blue signs but traditionally many countries use green - like Italy, Turkey, USA, China.

Can you give example of well mapped city/town at low latitude for testing? Most of what I found had really high road density and also benefited from less wide roads.

Road density in Mercator is both a function of latitude and of cultural/historical aspects. Many cities in equatorial areas are densely built while in northern Europe and North America they are often coarser. This emphasizes the latitude effect.

Examples:

osm.org/#map=13/13.0808/80.2107

osm.org/#map=13/13.7719/100.5367

osm.org/#map=13/36.8498/10.2118

osm.org/#map=13/19.4216/-99.0817

osm.org/#map=13/-23.5640/-46.6246

And i am for the non-blue motorways - if a distinction between motorway and trunk is considered necessary this should be a relatively subtle variation in red, possibly simply a distinct centerline color as in the german style. Getting blue (and green of course) out of the roads will go a long way towards more consistent use of color in the style. As SK53 pointed out historically color selection was often made with regards to the limited set of colors that could be printed without halftoning. On the other hand printed maps can do a lot more with thin lines, line signatures and patterns - historically the German topographic maps for example did not use any color in road rendering at 25k:

and at coarser scales all major roads were red. Same applies to the Swiss maps - only last years they started using colored roads at 25k (with orange for motorway/trunk and pale red for major roads).

The main highway coloring looks good, the subtle variants are somewhat difficult to judge - i tend to prefer the stronger fill for highway=motorway but the weaker yellow for secondary. I have come to terms with the red junction labels but i still prefer the blue oneway arrrows for some reason.

You seem to have narrowed the roads at z=15/16 but not at 13/14 - this looks good on Malmö but as you know less so at lower latitudes.

Trams look good as well now IMO.

As for the footways - i am sorry but i distinctly do not like the changes in most cases - the sb12 variant looks mostly fine on the higher zooms in urban context although it looks strange in combinations with tracks. The current rendering - as noisy as it might be - is very distinct and well recognizable for features that are very important to many map users. This is not the case for the new stylings. I particularly think the rendering of highway=path is very difficult to improve, it works on a wide range of scales, for a long distance path that is straight across many kilometers as well as for one with small scale curves and bends. The new styling OTOH is just a line that could be anything - fence, power line, boundary - you name it.