Write to temporary file failed: No space left on device

[baggio1117]

22519446416 bytes used or committed, of 25018892288 originally available xxx.geojson: Write to temporary file failed: No space left on device

When I run tippecanoe, I got the above error message. Where is the temporary directory and how can I change it? My system is ubuntu 20

[e-n-f]

You can use the -T option to set the location that is used for the temporary directory. It is /tmp if you don't specify.

[rsimon]

Sorry to revive an old thread. But I' getting a similar error, while writing PBF tiles using the following command:

tippecanoe -zg -e ./output input.json --no-tile-compression --drop-densest-as-needed --extend-zooms-if-still-dropping

I'm working with a 34GB input file, and the error comes up when writing zoom level 15. Which means things seem to work as they should up until the error (and the disk is probably getting pretty full).

However, checking my disk space after the error occurs, I still have > 350GB left. This seems odd, although I understand that the demand for temporary disk space might just be that high. Any thoughts on what the recommended disk space is for input files of that size?

[e-n-f]

https://github.com/felt/tippecanoe now compresses the temporary files, so you may have better luck with that version.

Sorry, I don't have a rule of thumb to suggest for how much temporary storage will be required. The deeper the zoom levels get, the more you need, because features get split between tiles and need to be represented multiple times.

[rsimon]

Thanks! I've actually been using the felt version. (Just posted my comment here because the issue seemed to match my problem best.)

But if I interpret your answer correctly, it would not be unusual that 350GB free space would be insufficient for a dataset of this size (95 million points, global coverage), once tiling hits zoom level 15 and more? If so, I'll go look for a bigger drive ;-)

[e-n-f]

I would think you would be fine with much less temporary space than that since your data is points. Polygons can end up stretching across many tiles at maxzoom, but points can't, so they shouldn't eat much more space than their raw size, and tippecanoe's "You will probably run out of disk space" warning is calculated based on that assumption.

Oh, you are using -e! Your file system is running out of inodes long before it runs out of free blocks, because it has to spend an inode to create every tile or directory of tiles. This is why mbtiles exists, because writing to individual files can be very slow and can easily run you out of inodes.

[rsimon]

Ah, thanks for the explanation! That must be the case. I hadn't expected it to make such a significant difference (beyond performance).

I've been using plain pbf tiles previously for smaller datasets, due to the obvious convenience of being able to do static file hosting. But looks like this will have to be an .mbtiles file then.