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: http://www.naturalearthdata.com/downloads/50m-physical-vectors/50m-antarctic-ice-shelves/ 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: https://mapzen.com/documentation/tangram/draw/#color -- Christoph Hormann http://www.imagico.de/ _______________________________________________ dev mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev
