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.

It seems to me vector tiles technology is only an example for a somewhat more general problem. There are quite a few people and smaller companies working on and practically using vector tiles technology - like for example Andy Allen, but when you develop sophisticated stuff primarily for your own use releasing it as open source is a mixed bag, you spend a lot of time bringing things into a form that works out of the box for others and document it so people are actually able to use it but if you are not primarily a software developer there is little gain in doing so. I’d guess the situation is somewhat similar even for a fairly large company like Mapbox, their primary business is not developing software - despite employing several core developers of open source software projects.

If you read closely this can also more or less be found in https://www.mapbox.com/about/open/ - both for open/closed software and data by the way. This is somewhat at odds with marketing claims like ‘majority of their data is open’ or ‘dedication to being open’ IMO but from a business perspective this is a consistent view. It is unlikely that you will see a company like Mapbox preferencing open compared to closed (software or data) unless it seems to be favorable for them from a business perspective.

The real question is where these mechanisms leave us in terms of innovation. I have no doubts open source has such a solid position meanwhile that whenever something innovative, widely useful and popular is developed it will sooner or later also get available as open source. But if business structures prevent actual innovation from happening, for example because a few dominating companies in a field prevent innovative ideas from gaining foothold because they threaten their business model this becomes a real problem. Most people consider this to be a problem w.r.t. Google but it is perfectly possible that this also applies to Mapbox in some areas.

These are very useful insights into far east Language relations and particularities. You do not however address the problem of verifiability of handcrafted transliterations. This is rarely an issue with two neightboring countries with a long history of cultural relations like China and Vietnam but the main question is how to handle this in other cases. How do you decide if and how to tag name:vi for European/African/American places?

Nice summary of the big imports.

You however only looked at the formal cleanup of the nodes. There is also substantial cleanup in tagging required, in Tiger that is obvious but with Canvec this is also a real problem. To give an example: Canvec imports tag all waterways as stream. There are nearly 3 million waterway=stream ways with a source=NRCan* tag right now but only 774 (!) waterway=river with such source tag, 63 of which have been touched since the beginning of the year, 285 last year.

Making a very generous estimate and assuming the same number of rivers have been retagged removing the source tag (which is more difficult to determine, but it is unlikely there are this many - source tags usually remain untouched in later edits) and assuming only ten percent of the waterways would actually qualify for waterway=river (in reality it is more) it would still take ~500 years to fully evaluate waterway tagging in Canvec data even if we’d stop importing further streams right away.

By the way, CanvecImports only accounts for ~15% of the ways with a source=NRCan* tag, extrapolating from that for the nodes there would be more than 250 million Canvec nodes at the moment.

The whole situation including the different claims is fairly well mapped in that area, see:

osm.org/relation/4609727

osm.org/relation/4609726

osm.org/relation/4611980

osm.org/relation/4610574

osm.org/relation/4611981

See:

https://github.com/gravitystorm/openstreetmap-carto/issues/989

Note however the practical usefulness is right now fairly hypothetical. If you have an electric vehicle right now the chances that when you go to one of the places tagged amenity=charging_station in OSM with it you can actually charge it there are probably slim - just have a look at the number of sockets shown on the wiki page - not to mention the contractual difficulties of being allowed to use it. Electric charging is still lightyears away from fossile fuel ‘charging’ where you can usually be sure that you can (a) technically fuel your vehicle and (b) pay with at least either cash or credit card at any fuel station.

The biggest difference in road rendering between Google and OSM standard style to me seems to be that at z13/14 Google uses thin plain lines for all but the largest roads while the OSM style draws them with casing. Apart from that the road rendering in Google is generally more subtle. This is not necessarily a good thing - i am in general a proponent of rendering things clearly visible or not at all. But the dark gray at low zooms and the bright white at high zooms for the lower importance roads in the OSM style is of course quite extreme.

Also Google in general draws roads thinner than the OSM standard style (except for the highest zoom levels where OSM draws them thinner than reality). This helps them avoid things like

http://tools.geofabrik.de/mc/#14/4.6211/-74.1845&num=2&mt0=mapnik&mt1=google-map

although a better approach might be making the drawing width depend on local map scale rather than zoom level. This might be something you could try - AFAIK this would also be a first for any web map.

Nice to see waterbody mapping and use of OSM waterbody data gathering attention outside OSM itself.

Looking at your presentation it seems however your methodology has quite a few issues, both in detail and en large - some of them will likely ‘bite you in the back’ when you try to use that approach in other areas.

The most basic one probably is that the techniques you compare do very different things. In OpenStreetMap we map bodies of water, either standing or flowing. When analyzing Landsat images you map surface water and when analyzing elevation data you map potential drainage lines. It should be obvious that these three methods - even if all of them work perfectly - will produce diverging results.

Your approach to Landsat/SRTM reminds me of something i did several years ago. You are lucky you do not have snow and glaciers or frozen lakes in Australia…

Rock glaciers are mapped with natural=glacier + glacier:type=rock - see osm.wiki/Proposed_features/Glaciers_tags

They are difficult to map though since they often look similar to scree and moraines in images.

You effort for providing useful information is meritorious but may i suggest you somewhat more carefully verify what you map. Aerial images are often difficult to interpret, especially if you don’t know the area from first hand experience and this is further aggrevated in mountain areas by irritating shadows and the distortions resulting from orthorectification.

For example

osm.org/way/334530242

osm.org/way/334561139

are clearly wrong (the glacier has mostly vanished except for a small rock glacier and the cliff would have a stream flowing uphill across it).