imagico has commented on the following diary entries

Post When Comment
How large are our national contributor communities and how are they developing? 4 days ago

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.

OpenStreetMap Carto Complexity 10 days ago

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.
#Spotted - 1 17 days ago

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

Average highway node distance between 2 points in OpenStreetMap - September 2015 2 months ago

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?

New road style for the Default map style, the full version - high zoom 4 months ago

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.

New road style for the Default map style - the full version 4 months ago

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.

New road style for the Default map style - the full version 4 months ago

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

pedestrian in blue

New road style for the Default map style - the full version 4 months ago

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.

New road style for the Default map style - the full version 4 months ago

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.
New road style for the Default map style - the second version 4 months ago

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:

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.
New road style for the Default map style - the second version 4 months ago

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.

New road style for the Default map style - the second version 4 months ago

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.

About problems with [surface=unpaved; access=destination] roads 4 months ago

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.

New road style for the Default map style - highway=path is evil 4 months ago

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).

New road style for the Default map style - the first version 5 months ago

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.

New road style for the Default map style - the first version 5 months ago

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.


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:

german tk25 example

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).

New road style for the Default map style - the first version 5 months ago

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.

MapBox and MapQuest ... the bit the tech pundits are missing 5 months ago

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 - 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.

Globalizing the name translation debate 6 months ago

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?

Top OSM Rank: The Big Imports 6 months ago

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.