tippecanoe
tippecanoe copied to clipboard
Tippecanoe holds forever above 5 million points in geojson file
I have a gzipped file positions.json.gz
with one geojson object representing one point per line:
{"type":"Feature","geometry":{"type":"Point","coordinates":[-88.55666,30.10603]},"properties":{"speed":0}}
{"type":"Feature","geometry":{"type":"Point","coordinates":[-88.55661,30.10625]},"properties":{"speed":0}}
{"type":"Feature","geometry":{"type":"Point","coordinates":[-88.55695,30.106083]},"properties":{"speed":0}}
I run tippecanoe on Ubuntu 16.04 in parallel mode with the following command:
tippecanoe -o positions.mbtiles -P -z 22 -B 15 -r 1.25 --maximum-tile-bytes=5000000 positions.json.gz --force
This works great when there are fewer than approximatively 5 million rows in the file. As the count of rows increases, I noticed that tippecanoe takes more time to really start "processing" the points across multiple CPU cores. This seems normal as I'm assuming that tippecanoe simply loads the rows in memory before starting the parallel computation.
However, above 5 million rows, this "loading" step seems to hold forever and the multi-processing computation never actually starts. I've waited for several hours with 10 million rows with nothing happening.
Is this a bug or am I doing anything wrong?
note 1: if I remove -P
from the command to let tippecanoe run on a single core, the behaviour doesn't change: it will hold forever above 5 million points as well
note 2: if I don't pass any of the -z
, -B
, -r
or --maximum-tile-bytes
parameters then behaviour is still the same again
@ericfischer @springmeyer
I can see the most recent issue closing happened end of May — is this repo still maintained?
Thanks for the report. 5 million features should not ordinarily be difficult to process, and Tippecanoe tries to do most of its processing in temporary files instead of trying to load everything into memory. If you can upload a copy of your data, I can take a look and try to figure out what is going wrong.