September 2021 - mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] Embedding raster maps
by Oliver Eichler 25 Jan '22

25 Jan '22

Hi Steve, thanks for the file. On my device nothing is visible at all. But that's kind of an information, too. There is no way to circle down bugs by simply skipping the extended part. Probably it is still some missing encoding. In the Isle of Man map (and others) there is much more information in the RGN header. Note the values in the "filling bytes". And there seems to be an additional section after the extended point2 section. I called it offset1/length2. --- RGN header --- size 007D type 47 41 52 4D 49 4E 20 52 47 4E | GARMIN RGN byte0x0000000C 01 flag 00 year 2010 month 7 day 21 hour 9 minute 53 second 6 offset1 0000D54E length1 00000000 offset_polyg2 0000D54E length_polyg2 00001A1F byte0x00000025_0x00000038 02 00 00 00 00 00 00 00 FF 00 00 20 FD FC 03 00 00 00 00 00 offset_polyl2 0000EF6D length_polyl2 00000000 byte0x00000041_0x00000054 00 00 00 00 00 00 00 00 3F 00 00 20 FD 0F 00 00 00 00 00 00 offset_point2 0000EF6D length_point2 00000000 byte0x0000005D_0x00000070 00 00 00 00 00 00 00 00 FF 07 00 20 3F F7 3F 00 00 00 00 00 offset2 0000EF6D length2 0000020B unknown 000000E3 This section has a variable length in different sub-files. The unknown value E3 can be E5, too. It doesn't seem to be a record size. I had a look at several sections. They are not completely random, thus there seem to be no "compression". However the patterns do not ring a bell for me. I copied a couple of them into a file and loaded it into my cloud share: https://www.magentacloud.de/share/s429h1z-r6 Maybe one of you has an idea what it's about. I also uploaded my current version of the test map with a single raster map tile. It does not show. Top left coordinate is N46° 57.768 E011° 47.484. Sadly I am stuck here and I am running out of quality time to concentrate on the topic. I also have to update QMapShack's decoding. While reading the mkgmap source code I noticed a lot of new stuff that is not covered by the decoder. Cheers Oliver

4 6

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option
by Felix Hartmann 11 Oct '21

11 Oct '21

.img files are always reused and never rewritten - it's only about the gmapi files (a gmapsupp.img has to be generated in one go anyhow - so it is not in question here). So I do not see the sense of making it more complicated? It would be fine with me too that way - but I think it's simpler to just assume all .img files already have the converted files - because you could do it when generating those .img files. The problem with your approach is - that when you have a long list of tiles that were crashing due to too little maxnodes - then regenerating it - will make it very complicated. It's much easier to assume that all .img files are already converted. All other input not. If you need to convert .img files too - then you just use the normal --gmapi option instead. On Mon, 13 Sept 2021 at 18:58, Thomas Morgenstern <webmaster(a)img2ms.de> wrote: > I suggest the new option should be named *reuse=<comma separated list of > files, wildcards enabled>. *exampel *reuse=40000001.img, 40005*.img. *If > this option is used, then mkgmap should not overwrite the listed folders > in the <name>gmap. Naturally mkgmap should write a new tdb, preview.img, > mdr and idx. In most cases the *reuse folders *contains Contourlines or > other static content. > > Thomas > > Am 13.09.2021 um 15:38 schrieb Felix Hartmann: > > Hi Gerd, yes exactly. I have a large collection of .img files of > contourlines. When I realized that I trash my NVME disk very fast if I > continue the way I did I got into thinking and analysing what happens. It > was clear that it all comes down to the --gmapi option. I had believed that > if I run several passes with .o5m and .img files as input - only the .o5m > input is converted into new .gmapi folders - while the existing ones are > not overwritten. Then I checked the created date/last modified date > (because windows has in my eyes a bug that if you replace a file with a > near identical file - it just shows a new modified date - but keeps the > original created date - even though it was a full overwrite). > > That got me thinking that in order to save writes - I have to find a way > to not only not recalculate the .img files - but also create a static set > of .gmapi folders. Those I just mklink into the directory name that will be > used on the next run of mkgmap.jar - I managed to do this by uncommenting > this one line. Because I noticed that the symlinked (by mklink) files are > not rewritten I changed my scripts to move them away and symlink them back. > Then at the end delete all symlinks - and move the files back (or to the > location that I will use for compressing). This step is a bit stupid if > mkgmap could just have a --gmapi-minimal mode in which only those files are > converted - that are also written out as .img files (if given --tdb-file > option). > > I know that many people keep a static set of contourlines .img files (also > containing DEM). You just add the show-profiles=1 option in case you > include contourlines - and leave it out if not. But actually it does not > matter if the contourlines files contain DEM or not. > *I think the easiest way is the principle - --gmapi-minimal only converts > those files, it would write out as .img files if --tdb-files option were > given (or is given). --gmapi on the other hand should convert the all input > files to .gmapi format.* Then mgkmap does not even need to test if those > files are there or not. This not only saves a lot of writes - but also a > lot of compile time. > > Because essentially if you only provide .img input files (including of > course the ovm-img for the overview map if you want) you only create a new > set of mapset files. The exception to this is the toolchain in which when a > tile failed to compile - you resplit the input files - and parse them again > with the same arguments so you have input of new o5m files and old .img > files. But the principle stays the same. If on the rerun of the failed > tiles now newy split with higher map-id you give --gmapi-minimal and > tdb-file - only those new tiles are written - while the old .img and old > ovm.img are supplied to create the correct mapset files. With this > procedure you don't even need to put a symlink for the contourlines into > the gmap folder. As the input data to create the contourlines rarely change > - you can offer the contourlines as a separate download. > Makes it much easier and faster. > > On the map compilation server you then do not even need to have a copy of > the .gmapi contourlines files. You just need the new input data and the > static contourlines .img files. Thomas Morgenstern for example had also not > realized that he is writing the contourlines .gmapi files each time without > any need. I think many/most providers of garmin maps who offer many > regions/worldwide coverage put the contourlines separate. It's just a huge > amount of compile time if you merge the contourlines in o5m format with the > map data in o5m data each time before running mkgmap. The only actual > advantage of this being that the contourlines do not overlap roads (as they > are supplied as transparent .img files in another layer) - AND that when > people select maps with a single click instead of drag in > MapInstall/Mapsource they get all maps they think they get (though there is > a different shading - each layer increases the darkness of the shading for > selected). And of course that the very old Mapsource still has problems > correctly showing the contourlines if they are in a separate layer. However > nearly everyone moved on to Basecamp which is fully compatible with layered > maps. The advantage of contourlines as separate layer is for the user he > can switch them on / off independant of the maps and does not need to > download and transfer them each time. So I think for most the advantages > heavily outweigh the disadvantages - hence contourlines into a separate > transparent layer. Same can be done of course for other things like > buildings or vegetation - though the advantage here is much less on the > compile side (while worldwide 10m coontourlines are 200GB of data - the > same extracts are only 15GB in data of buildings - if buildings are shown > only at resolution 24) > > On Mon, 13 Sept 2021 at 14:24, Gerd Petermann < > gpetermann_muenchen(a)hotmail.com> wrote: > >> Hi Felix, >> >> I have no clue how exactly your scripts work, how you manage to reuse >> *.img files and so on. Also, I want to find a solution that works for all >> users, not just you. >> >> So, I expect that you have one step that compiles frequently changing OSM >> data and other steps which are used to compile static data like >> contourlines or DEM. I don't know if you do the latter for each country / >> continent or once for planet and I don't care as long as it works for you. >> My understanding is that you have a large collection of *.img files at >> some stage and that you run mkgmap multiple times with different >> combinations of those *.img files as input to produce different zip-files >> with gmapi format or gmapsupp format. >> I think that's the normal way to do it, so I try to support that way. >> >> Gerd >> >> ________________________________________ >> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von >> Felix Hartmann <extremecarver(a)gmail.com> >> Gesendet: Montag, 13. September 2021 12:28 >> An: Development list for mkgmap >> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting >> to disk if used with --gmapi option >> >> I move away the info.xml - and use a different name for the mapset files >> and then just have mkgmap any file that is input in osm.pbf / osm / o5m >> format. Gmapi-minimal should not convert any file that is supplied as .img >> - as it can be assumed that those exist already (if they do not - then >> create them with --gmapi). That is in my opinion the best approach. So >> mkgmap does not even try to convert them. >> >> Afterwards I distribute a gmapi folder that includes all the data - and >> by replacing the info.xml you can enable or disable contourlines. For big >> countries the contourlines would be a separate download anyhow - so the >> user only needs to download the maps (including mapset files) but not >> redownload the contourlines. Same principle as in offering the >> contourlines as a separate gmapsupp.img file. so you have maps.img >> contourlines10m.img contourlines20m.img buildings.img .... >> >> >> On Mon, 13 Sept 2021 at 13:17, Gerd Petermann < >> gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> >> wrote: >> Hi Felix, >> >> sorry, the Data Deduplication as implemented in Windows Server would not >> help here. It works after data was written. >> >> And yes, files which are not just copies of the *.img are written as >> before. My understanding is that you have different product directories in >> the gmapi folder and that you write protect those files which should be >> kept. >> If you have a script to zip the gmapi directory you have to exclude the >> unwanted folders. >> Didn't try it. Does it make sense? >> >> Gerd >> >> ________________________________________ >> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: >> mkgmap-dev-bounces(a)lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < >> extremecarver(a)gmail.com<mailto:extremecarver@gmail.com>> >> Gesendet: Montag, 13. September 2021 12:09 >> An: Development list for mkgmap >> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting >> to disk if used with --gmapi option >> >> Oh - but data was certainly written - A rename will not show as data >> written in both Task manager on Windows, as well as in the smart data (I'm >> using Windows 10 pro not Windows server however - maybe that functionality >> is limited to windows server?) >> >> On Mon, 13 Sept 2021 at 13:06, Felix Hartmann <extremecarver(a)gmail.com >> <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: >> extremecarver(a)gmail.com>>> wrote: >> Not sure if it makes it possible to use read only attribute instead of >> moving and mklink. Maybe yes - because that was not possible before. So it >> then would be set read only - instead of of move & mklink - and at the end >> remove read only instead of moving back. >> >> On Mon, 13 Sept 2021 at 12:59, Felix Hartmann <extremecarver(a)gmail.com >> <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: >> extremecarver(a)gmail.com>>> wrote: >> Thanks Gerd, >> >> but that is just removing the warning if it cannot overwrite, correct? >> If it can overwrite the gmap file it will still overwrite it as I see.. >> So in essence just a bit more intelligent then my disabling that line. >> >> I think it should not overwrite at all if present and --x-gmapi-minimal >> (then you don't have to move away the files and link them back to the >> original folder). >> >> On Mon, 13 Sept 2021 at 10:43, Gerd Petermann < >> gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com >> ><mailto:gpetermann_muenchen@hotmail.com<mailto: >> gpetermann_muenchen(a)hotmail.com>>> wrote: >> Hi all, >> >> attached is a quick patch that implements experimaltal option >> --x-gmapi-minimal. >> >> If used instead of --gmapi mkgmap will not fail if a write-protected >> output file exists in the gmapi output folder and mkgmap copies data from >> *.img. It should still crash when other files like Info.xml are written. >> >> BTW: no conversion is done when those files are written. I think mkgmap >> simply copies data from sub files in *.img into single files. So, the same >> sequence of Bytes exists two or more times on the Computer. Windows Server >> seems to support automatic data deduplication (1). I am sure Linux offers >> similar support. No idea how effective or reliable it is, but it might be >> worth trying. >> >> Gerd >> (1) >> >> https://docs.microsoft.com/en-us/windows-server/storage/data-deduplication/… >> >> ________________________________________ >> Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: >> mkgmap-dev-bounces(a)lists.mkgmap.org.uk><mailto: >> mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: >> mkgmap-dev-bounces(a)lists.mkgmap.org.uk>>> im Auftrag von Carlos Dávila < >> carlos(a)alternativaslibres.org<mailto:carlos@alternativaslibres.org >> ><mailto:carlos@alternativaslibres.org<mailto: >> carlos(a)alternativaslibres.org>>> >> Gesendet: Sonntag, 12. September 2021 22:45 >> An: mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk >> ><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: >> mkgmap-dev(a)lists.mkgmap.org.uk>> >> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting >> to disk if used with --gmapi option >> >> I think it's a good idea if mkgmap checks the required files are present. >> >> El 12/9/21 a las 21:16, Gerd Petermann escribió: >> > Hi Felix, >> > >> > so you just want a new option so that mkgmap doesn't fail if it cannot >> overwrite (write-protected) files in the output directory, right? No need >> to verify the content of the exiting file(s)? >> > >> > Gerd >> > >> > ________________________________________ >> > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: >> mkgmap-dev-bounces(a)lists.mkgmap.org.uk><mailto: >> mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: >> mkgmap-dev-bounces(a)lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann < >> extremecarver(a)gmail.com<mailto:extremecarver@gmail.com><mailto: >> extremecarver(a)gmail.com<mailto:extremecarver@gmail.com>>> >> > Gesendet: Sonntag, 12. September 2021 19:10 >> > An: Development list for mkgmap >> > Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting >> to disk if used with --gmapi option >> > >> > And well - it is burning SSD for the contourlines currently even if not >> calling multiple times. 130GB minimum per worldwide map update for all >> geofabrik extracts at 20m equidistance. 260GB at 10m. With calling multiple >> times and 10m and 20m I had about 2TB of useless writes per weekly map >> update. I've got rid of all of them with my uncommenting the line, plus >> saved about 500GB of writes by now doing all the gmapsupp.img and gmap >> stuff in Ramdisk So now instead of 4TB of disk writes per map update I'm >> down to 1TB.. (and yeah the resplitting of tiles added another 5TB of >> writes - but that could have been fixed easily by changing order of >> commands too). >> > >> > On Sun, 12 Sept 2021 at 20:04, Felix Hartmann <extremecarver(a)gmail.com >> <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: >> extremecarver(a)gmail.com>><mailto:extremecarver@gmail.com<mailto: >> extremecarver(a)gmail.com><mailto:extremecarver@gmail.com<mailto: >> extremecarver(a)gmail.com>>>> wrote: >> > because you need to do it if you want to show contourlines. Now >> compiling the worldwide contourlines each time again - would burn SSD as >> well - besides taking longer than just compiling the maps. So everyone who >> offers maps for many countries as download puts the contourlines separate. >> If you want to offer the choice of showing contourlines or not - mkmgap >> will write the gmap contourlines once not needed, and once the maps not >> needed. If you don't want to offer that option - it's only the contourlines >> being written without need. Contourlines for all geofabrik extracts 20m >> equidistance are about 130GB, 10m would be 260GB. >> > If you offer 10m and 20m it will be even more not needed writes. >> > >> > The only solution is to go for a Ramdisk instead - However you likely >> will need 128GB of RAM to do that - because for Asia or Europe you need a >> 64GB Ramdisk. Same for North America extract (but few people offer that and >> just have Canada and the US divided into the 4-5 zones). For other maps you >> will get by with a 15-20GB Ramdisk (which I have resorted to now for all >> but the windows installers because I don't want to let the server wait for >> ages for the single thread NSIS wrapping up the data and instead start the >> next country in parallel). And yes going RAMDISK already using my patch and >> symlinking those files so mkgmap cannot overwrite them (would still be >> faster if mkgmap didn't try in first place I think). If you want to write >> out the contourlines as well besides the additional time - for Asia >> continent you may then go for a 90GB Ramdisk minimum if offering windows >> and gmap installers. In this case gmapsupp.img donwnloads aren't possible >> anyhow due to the huge data amounts. For sm >> > aller countries I have them too.... >> > >> > I coded around this now by using symlinks - but yeah that will be quite >> a lot of work and is prone to break - while I guess it's only 10 lines or >> so to add to mkgmap code to have a mode that does not write them out if >> they are present - or if you tell on commandline they are present already. >> For .img files they aren't overwritten either... >> > >> > On Sun, 12 Sept 2021 at 18:40, Gerd Petermann < >> gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com >> ><mailto:gpetermann_muenchen@hotmail.com<mailto: >> gpetermann_muenchen(a)hotmail.com>><mailto:gpetermann_muenchen@hotmail.com >> <mailto:gpetermann_muenchen@hotmail.com><mailto: >> gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> >> wrote: >> > Hi Felix, >> > >> > did not read all the posts in detail. I understand that mkgmap is >> neither burning SSDs nor doing any excessive writing unless you call it >> multiple times for the same input files. So the question is: Why do you do >> that? >> > >> > Gerd >> > >> > ________________________________________ >> > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: >> mkgmap-dev-bounces(a)lists.mkgmap.org.uk><mailto: >> mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: >> mkgmap-dev-bounces(a)lists.mkgmap.org.uk>><mailto: >> mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: >> mkgmap-dev-bounces(a)lists.mkgmap.org.uk><mailto: >> mkgmap-dev-bounces(a)lists.mkgmap.org.uk<mailto: >> mkgmap-dev-bounces(a)lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann >> <extremecarver(a)gmail.com<mailto:extremecarver@gmail.com><mailto: >> extremecarver(a)gmail.com<mailto:extremecarver@gmail.com>><mailto: >> extremecarver(a)gmail.com<mailto:extremecarver@gmail.com><mailto: >> extremecarver(a)gmail.com<mailto:extremecarver@gmail.com>>>> >> > Gesendet: Freitag, 10. September 2021 00:02 >> > An: Development list for mkgmap >> > Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting >> to disk if used with --gmapi option >> > >> > Well I think the .tmp files are just building up - and the renamed. So >> they are not causing any actual excessive write. >> > As for the gmap - it would be cool if there is a mode to not write them. >> > >> > Actually it would be great if mkgmap could write all in one go. Because >> the thing that takes so much time - is the address search - and that is >> always the same. The differences are tiny (just because MapInstall is >> crashing when files are missing) you need to compile them separately. >> > >> > but maybe there could be a mode where mkgamp writes all in one go. >> > So family-name / family-name1 / family-name2 >> > description / description1 / description2 >> > input input1 input2 >> > family-name.. >> > show-profiles >> > overview-mapname >> > product-id >> > (and maybe I missed some options are those that would need to be given >> for each set of input tiles. And then just an option where you tell mkgmap >> files starting with which first 4 numbers are relevant for address search. >> No need to analyze if those other supplied .img (e.g. buildings or >> contourlines) need to be added to address search.). I know coded around the >> problem of the gmap files causing excessive writes. But yeah that is >> actually really complicated be it on windows or linux... >> > >> > On Wed, 8 Sept 2021 at 17:07, Felix Hartmann <extremecarver(a)gmail.com >> <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: >> extremecarver(a)gmail.com>><mailto:extremecarver@gmail.com<mailto: >> extremecarver(a)gmail.com><mailto:extremecarver@gmail.com<mailto: >> extremecarver(a)gmail.com>>><mailto:extremecarver@gmail.com<mailto: >> extremecarver(a)gmail.com><mailto:extremecarver@gmail.com<mailto: >> extremecarver(a)gmail.com>><mailto:extremecarver@gmail.com<mailto: >> extremecarver(a)gmail.com><mailto:extremecarver@gmail.com<mailto: >> extremecarver(a)gmail.com>>>>> wrote: >> > Well I could give it 20 GB ram disk, maybe 32 but then I need to render >> on less than 12 processes 64GB ram available). But that is not enough for >> Asia continent map, and I guess super tight for Europe... >> > >> > Mkgmap could definitely keep those .tmp files in memory. But the >> important bit is the gmap files not needeed to be written.... Also would >> save quite some CPU time. >> > >> > On Wed, 8 Sep 2021, 14:31 ael <witwall3(a)disroot.org<mailto: >> witwall3(a)disroot.org><mailto:witwall3@disroot.org<mailto: >> witwall3(a)disroot.org>><mailto:witwall3@disroot.org<mailto: >> witwall3(a)disroot.org><mailto:witwall3@disroot.org<mailto: >> witwall3(a)disroot.org>>><mailto:witwall3@disroot.org<mailto: >> witwall3(a)disroot.org><mailto:witwall3@disroot.org<mailto: >> witwall3(a)disroot.org>><mailto:witwall3@disroot.org<mailto: >> witwall3(a)disroot.org><mailto:witwall3@disroot.org<mailto: >> witwall3(a)disroot.org>>>>> wrote: >> > On Wed, Sep 08, 2021 at 02:10:52PM +0300, Felix Hartmann wrote: >> >> 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. >> > +1. I always use an old spinning rust disk when using mkgmap to save ssd >> > write cycles, even without contours and such. It seems to be profligate >> > in its use of disk cycles. I did try using RAM disk, but even with 16GB >> > on a laptop, that was soon exhausted. >> > >> > ael >> > >> > >> > _______________________________________________ >> > mkgmap-dev mailing list >> > mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk >> ><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: >> mkgmap-dev(a)lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk >> <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: >> mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk >> >>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: >> mkgmap-dev(a)lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk >> <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: >> mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk >> ><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: >> mkgmap-dev(a)lists.mkgmap.org.uk>>>> >> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > >> > >> > -- >> > Felix Hartman - Openmtbmap.org & VeloMap.org >> > >> > _______________________________________________ >> > mkgmap-dev mailing list >> > mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk >> ><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: >> mkgmap-dev(a)lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk >> <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: >> mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> >> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > >> > >> > -- >> > Felix Hartman - Openmtbmap.org & VeloMap.org >> > >> > >> > >> > -- >> > Felix Hartman - Openmtbmap.org & VeloMap.org >> > >> > _______________________________________________ >> > mkgmap-dev mailing list >> > mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk >> ><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: >> mkgmap-dev(a)lists.mkgmap.org.uk>> >> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> _______________________________________________ >> mkgmap-dev mailing list >> mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk >> ><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: >> mkgmap-dev(a)lists.mkgmap.org.uk>> >> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> _______________________________________________ >> mkgmap-dev mailing list >> mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk >> ><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: >> mkgmap-dev(a)lists.mkgmap.org.uk>> >> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> -- >> Felix Hartman - Openmtbmap.org & VeloMap.org >> >> >> >> -- >> Felix Hartman - Openmtbmap.org & VeloMap.org >> >> >> >> -- >> Felix Hartman - Openmtbmap.org & VeloMap.org >> >> _______________________________________________ >> mkgmap-dev mailing list >> mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> >> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> -- >> Felix Hartman - Openmtbmap.org & VeloMap.org >> >> _______________________________________________ >> mkgmap-dev mailing list >> mkgmap-dev(a)lists.mkgmap.org.uk >> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > > > -- > Felix Hartman - Openmtbmap.org & VeloMap.org > > > > _______________________________________________ > mkgmap-dev mailing listmkgmap-dev@lists.mkgmap.org.ukhttps://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > -- Felix Hartman - Openmtbmap.org & VeloMap.org

3 22

Compilation fail with "Similar arcs"
by Stéphane MARTIN 28 Sep '21

28 Sep '21

Hi, - splitter-r642 - mkgmap-r4807 mkgmap fails compiling Madagascar map with extract from Geofabrik. mkgmap.log : https://files.mkgmap.org.uk/download/521/mkgmap.log More informations needed ? Regards Steph

2 8

POI's disappear
by brad 22 Sep '21

22 Sep '21

I've noticed that showing POI's is somewhat out of my control. Example: I have campgrounds, using 0x4800, they will show up at the zoom level I expect, then I zoom in and some will disappear. I zoom in more & they will come and go. I suspect that Garmin is deciding that it isn't important and showing something else instead. Is there any way to make this stick, or increase the priority? It all works as expected on Qmapshack. I'm using a Garmin Zumo XT & a DriveSmart. Thx Brad

2 1

The x prepended to the *.typ file
by Gerd Petermann 20 Sep '21

20 Sep '21

Hi all, I think there is an old rather confusing glitch in mkgmap class TypSaver which it is used with a *.typ file as input, as in java -jar mkgmap.jar --output-dir=<map-folder> --family-id=4711 ... -c splitter-dir\template.args ..\typfiles\existing.typ to make sure that family-id and product-id are correctly updated in the *.typ file. Since 2012 the program creates / overwrites a copy of file existing.typ in the source(!) directory ..\typfiles with the prefix "x", so ..\typfiles\xexisting.typ is written instead of <map-folder>\existing.typ. I can't find it now but I think there were complains that this name doesn't fit the 8+3 rule for old file systems and causes trouble on some devices. I think when Steve coded this he expected that the *.typ file is in the output directory, not somewhere else. My conclusions: - I think it is an error to create the copy in the source directory. - I see no reason to create a copy with the prepended "x", I would just create or alter the file in the given output directory. @Steve: What case am I missing? What's the reason for the different name in the copy? @all: Does anybody rely on this behaviour? Gerd

6 14

mkgmap doing excessive writing and converting to disk if used with --gmapi option
by Felix Hartmann 20 Sep '21

20 Sep '21

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). However this does not work when providing the --gmapi option. Actually mkgmap tries to rewrite all those files again/convert them. Could it please be possible for mkgmap to change this? There could be the status quo with --gmapi and there could be a new mode called --gmapiminimal that only converts files input as .o5m or .osm.pbf or .osm but not as .img --gpapiminimal would then work the same way as it does with .img files. This has two use cases. 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. 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. 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. 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... Yes mkgmap uses quite a lot of RAM, but RAM is much cheaper than continous SSD writes.... Write now mkgmap crashes if you symlink already converted files to it: e.g. message: Number of MapFailedExceptions: 0 SEVERE (global): Error saving gmapi data java.nio.file.FileAlreadyExistsException: .\mtb_alp_08.09.2021.gmap\Product1\75280000 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) 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. 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) I don't know how to change that myself, but I hope this is not much work to change. -- Felix Hartman - Openmtbmap.org & VeloMap.org

4 23

Creating gmapsupp.img fails with: Cannot invoke "String.endsWith(String)" because the return value of "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null
by Felix Hartmann 14 Sep '21

14 Sep '21

Partly related to the other problem - if I run mkgmap on the splitted files - I get this error. All .img files seem to be fine, but the gmpsupp.img is created with 0 bit size. This is not happening every time I resplit tiles. In this case two tiles were joined by osmconvert - and splitter splits it into three tiles. Then all .img files are created correctly, but the mapset.tdb / mapset.img files are not created - and the gmapsupp.img has 0 size, the gmapi files is also not created. I guess this happens because splitter somehow made a melange of the two input files into three? I really think the only thing missing in resplitting the too big tiles from mkgmap is an appropriate keep-complete mode - that keeps each input tile complete - but does not join input tiles. So osmconvert merging the input tiles is a bad idea even though it mostly works. C:\openmtbmap\maps>start /belownormal /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms5000M -Xmx43000M C:\openmtbmap\mkgmap.jar --max-jobs=12 --order-by-decreasing-area --code-page=1251 "--style-file=C:\openmtbmap\buildings_style" --levels="0:24, 1:23, 2:22, 3:21" --ignore-osm-bounds --ignore-turn-restrictions --merge-lines --allow-reverse-merge --transparent --draw-priority=28 --add-pois-to-areas --simplify-polygons=23:4,22:7,21:8 --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt" --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt" --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --ignore-fixme-values --polygon-size-limits="24:16, 23:14, 22:12, 21:11" --ignore-turn-restrictions --description=buildings_ru --country-abbr=ru --country-name=russia --mapname=85800000 --family-id=8580 --product-id=1 --series-name="buildings_russia_31.08.2021_NU_Local" --family-name="buildings_ru_31.08.2021_NU_Local" --tdbfile --gmapi --gmapsupp --overview-mapname=mapsetb --keep-going --area-name="russia_31.08.2021_NU_Local_buildings" -c D:\openmtbmap\maps\template.russiab buildru.typ [0.005s][warning][gc,ergo] NewSize was set larger than initial heap size, will use initial heap size. Mkgmap version 4806M Time started: Tue Aug 31 21:00:52 CEST 2021 SEVERE (Main): D:\openmtbmap\maps\85800012.o5m: input file 'D:\openmtbmap\maps\85800012.o5m' doesn't exist SEVERE (Main): D:\openmtbmap\maps\85800024.o5m: input file 'D:\openmtbmap\maps\85800024.o5m' doesn't exist Number of MapFailedExceptions: 0 Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.endsWith(String)" because the return value of "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:620) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:146) at uk.me.parabola.mkgmap.main.Main.main(Main.java:117) -- Felix Hartman - Openmtbmap.org & VeloMap.org

2 7

Commit r4807: fix possible NPE when --keep-going is used in combination with an input file that doesn't exist
by svn commit 14 Sep '21

14 Sep '21

Version mkgmap-r4807 was committed by gerd on Tue, 14 Sep 2021 fix possible NPE when --keep-going is used in combination with an input file that doesn't exist http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4807

1 0

mkgmap doing excessive writing
by Thomas Morgenstern 13 Sep '21

13 Sep '21

I suggest the new option should be named /reuse=<comma separated list of files, wildcards enabled>. /exampel /reuse=40000001.img, 40005*.img. /If this option is used, then mkgmap should not overwrite the listed folders in the <name>gmap. Naturally mkgmap should writea new tdb, preview.img, mdr and idx. In most cases the /reuse folders /contains Contourlines or other static content. Thomas

3 2

How to create an empty overview map (for transparent maps)
by Felix Hartmann 13 Sep '21

13 Sep '21

If you create a separate map for buildings or contourlines only - usually there is no need for an overview map - or better no need for any content in the overview map - or am I missing something? Because those maps sometimes may have very large tiles, but very few levels (maybe only 24) - mkgmap creates an overview map at the next resolution - and will then often throw warnings such as: SEVERE (OverviewBuilder): Tile selection (0x4a) polygon for tile 84900000 cannot be written in level 0 resolution 21, using 20 instead There is still a need for an empty overview map - as without it you cannot show the map in Basecamp/Mapsource - or transfer it with MapInstall. I know the overview map is only empty 0x4a polygons - just wondered if there is a better solution... --overview-levels= is not given. -- Felix Hartman - Openmtbmap.org & VeloMap.org

2 2