<div dir="ltr">Quite a few people do not compile the contourlines each time they update a map, but reuse the old contourlines. This works fine if you insert them as say 1234*img (and they are named 12340000.img 12340001.img and so on).<div><br></div><div>However this does not work when providing the --gmapi option. Actually mkgmap tries to rewrite all those files again/convert them.</div><div><br></div><div><br></div><div>Could it please be possible for mkgmap to change this?</div><div>There could be the status quo with --gmapi</div><div>and there could be a new mode called</div><div>--gmapiminimal that only converts files input as .o5m or .osm.pbf or .osm but not as .img</div><div><br></div><div>--gpapiminimal would then work the same way as it does with .img files. This has two use cases.</div><div><br></div><div>a) if you have to resplit a tile because some tiles were breaking - and directly gave the --gmapiminimal option - no need to redo the whole .gmap file. </div><div><br></div><div>b) you symlink all gmap folders with the contourlines (or other layers you do not recreate on each update) into the gmap folder and mkgmap only writes out the new stuff.</div><div><br></div><div><br></div><div>Yes on an nvme disk you barely notice the conversion - it's really quick. BUT it is not needed if you have the files and even more - it burns your NVME SSD disk. </div><div><br></div><div>To my horror I noticed that one worldwide update of maps wrote 5TB of data to my disk (thanks to NVME SSD and fast processor this all took 28 hours). At that rate even datacenter NVME ssd disks are quickly turned into trash., consumer grade NVME disk will not make it half a year for me... In general maybe mkgmap could have an option to write temporary files to another disk? Then you use a RAMDisk for those files. Or mkgmap should keep them in memory. Modern servers often have 64 or 128GB of RAM so enough RAM for mkgmap not to waste writes to disk... </div><div>Yes mkgmap uses quite a lot of RAM, but RAM is much cheaper than continous SSD writes....</div><div><br></div><div><br></div><div>Write now mkgmap crashes if you symlink already converted files to it:</div><div>e.g. message:</div><div>Number of MapFailedExceptions: 0<br>SEVERE (global): Error saving gmapi data<br>java.nio.file.FileAlreadyExistsException: .\mtb_alp_08.09.2021.gmap\Product1\75280000</div><div><br></div><div>While if it would be allowed to write out the data it would overwrite existing files (which is fine or should do so - but same way as for .img files)</div><div><br></div><div><br></div><div><br></div><div>For my worldwide maps 10m contourlines are 200GB, 20m contourlines are 100GB in size. Rendering the map in two styles and each time needing to convert them even though I already have them converted creates 600GB of useless writes per update (as well as useless time spend converting those 300GB at least twice) - and that is only if I use the --gmapi option as a separate step. If I give bot --tdb-file and --gmapi it gets worse if a tile failed to write - and I just parse it again.</div><div><br></div><div>And that is only for the contourlines. As I need three sets of mapset files - once without contourlines, once with 10m contourlines, and once with 20m contourlines the actual map gmapi folders are written three times instead of once... Well over 1TB of useless conversion time and useless data written to disk (but I do not know another way to create the needed mapset_mdr.img, mapset.img and mapset.tdb files)</div><div><br></div><div>I don't know how to change that myself, but I hope this is not much work to change.<br></div><div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Felix Hartman - Openmtbmap.org & VeloMap.org<br></div><br></div></div></div></div></div></div></div></div>