On 21.11.2015, at 10:41, Gervase Markham <g...@mozilla.org> wrote: > Instead of doing a whole-world render, can we render on demand > server-side and send down PNGs? Or is that too large of a data-crunching > exercise?
Only rendering parts of the world on demand is a really good idea. Most of the world on most zoom levels will never be shown to any user on any given day. Unfortunately the tool we use to generate the map isn't build this way. We use a tool called "datamaps" [1] by Eric Fischer, one of the data artists working for mapbox. He also wrote a newer tool called tippecanoe that does much the same, but also has the same assumptions. datamaps assumes that you have the data for the entire world available in order to render any part of it. You need to feed in a CSV file of the entire world and get a custom binary quadtree file out of it. Then you can enumerate over this quadtree and render out png files for the lat/lon bounding box and zoom levels you want. But the input is a file for the world. Having a single file makes it possible to do the "point merging" that results in the "glow/turning white" effect. For that calculation to work, it needs to know all the points that are inside each image tile and the lat/lon bounds that tile corresponds to. Generating that quadtree file takes close to an hour today. With that base time, we can just as well render out the world, as it's not that much more costly. Put another way: The tool we use today severely limits what we can do. It was always meant as a tool to run once on large datasets, and not something to run continuously. The only real way forward is changing tools / approaches, but we don't know what to change to. Hanno [1] https://github.com/ericfischer/datamaps [2] https://github.com/mapbox/tippecanoe _______________________________________________ dev-geolocation mailing list dev-geolocation@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-geolocation
