[OSM-dev] Bolder - Starting a new client-side OpenStreetMap style

Christoph Hormann osm at imagico.de
Mon Apr 30 19:15:15 UTC 2018

On Monday 30 April 2018, Paul Norman wrote:
> I didn't find noticeable differences between the Natural Earth and
> OSM data I'm using at these very low zooms 

I find this kind of hard to believe since the differences are so obvious 
and characteristic.  In most cases when i ask people why they use 
Natural Earth in web maps it is not that they don't think there is a 
visual difference but because of indifference, i.e. people don't care 
about the differences.

Of course most of the differences are in areas 90 percent of mappers and 
map users never consciously look at.  That's the difference between 
noticeable and noticed. ;-)

And of course Natural Earth ocean polygons are not equivalent to OSM 
water polygons definition wise - you need to cut out the Antarctic ice 
shelves for that:


Almost everyone gets this wrong.

> I've been using the same script with my server demoing the new WMF
> style work. It doesn't run automatically there, but i have run it a
> lot. It takes about 30 seconds to load and process the water polygons
> for the coastline on my home server, and that includes clustering and
> index building. It takes longer to download the file.
> The script makes sure to create a table optimised for rendering, with
> the contents clustered, indexes created for a read-only case, and
> some other tweaks. This avoids bloated tables.
> How do you consider this case extreme?

Well - >99 percent of the coastline data stays identical from one day to 
the other typically.  So you are replacing several hundred MB of data 
in the database every day with overwhelmingly exactly the same data.  
In absolute numbers this might not be too significant but relatively 
speaking this is like doing a new full planet import every day.

When creating the regular split coastline polygons for 
openstreetmapdata.com (which are currently only produced in geographic 
coordinates, not in mercator) i contemplated the idea that it would 
actually be nice to create a way for data users to only get those tiles 
where something has changed.  This would be possible but it would be 
quite a bit of work to set up and it would add quite a bit of 
complexity for the data user so it is unlikely many would use this.  
But it would be a much more elegant way to perform coastline updates 
when you have the data in a PostGIS database.
> I've been experimenting with different colour selection methods, and
> have found using a limited colour palette helpful. I want to specify
> colours in LCH, not sRGB, and Tangram scene files, like most style
> files, only allow direct input of the latter.

The problem (apart from a somewhat awkward syntax of color 
specification) is you unnecessarily limit the accuracy at which you can 
specify colors at in a quite severe way (if i saw correctly you have a 
fixed color palette of about 1700 colors).  You probably say you don't 
need more than 1700 distinct colors but if you for example want to 
create a harmonically stepped color sequence for roads those colors 
will usually not contain the ones you would ideally want for such 
purpose.  And in terms of sampling desity of color space 1700 distinct 
colors is very coarse.

I don't know if Tangram allows defining custom color conversion 
functions in some way - i am not even sure how the native color format 
is defined, i.e. if that is sRGB or linear color space as you would 
normally expect with OpenGL:


Christoph Hormann

More information about the dev mailing list