[OSM-dev] Bolder - Starting a new client-side OpenStreetMap style
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:
More information about the dev