[mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

Mon Oct 11 11:01:43 BST 2021

If it's only about nvme/SSD writes, then you could write to Ramdisk. I do
this for all geofabrik extracts except Europe/Asia continent.
The above patches for not writing again gmap files that exist already are
still important, as it saves on Ramdisk size and is faster as it is not
needed.
Also make sure 7zip or whatever you use for packing uses Ramdisk for
temporary files.

Note however, that this slows down the map compilation process Vs nvme
drives. Ramdisk used much more CPU than nvme for reading/writing, while
only being 2-4 times as fast (Vs Samsung 980 pro). As CPU time for me is
more important than write/read speeds, using Ramdisk Vs nvme is slowing
down map compilation time by around 5percent for me (using imdisk, dataram
Ramdisk even 10 percent). I still do it to save nvme writes.

Actually I think the gmapi-minimal patch v4 could be pushed to trunk. It is
working stable and not changing anything for those not using it. For me it
results in the whole map compilation process being 10% faster, while also
saving all excessive writes.
And while it's convenient to distribute gmapi maps to windows users, I
think .img is far superior.
a) you cannot create gmapsupp.img with mkgmap/gmaptool from gmap files.
b) the performance in basecamp is slightly better for .img maps
c) exporting maps with mapinstall is faster for .img maps
it's still a mystery for me why garmin decided to use the gmap format on
mac and now PC too. They could have just added the info.xml for .img files
too (yes registry is the disadvantage to .img files)

distributing as as gmapsupp.img only is the slowest option for desktop use
(needs to be converted first or read in painfully slow from external
memory). gmaptool not available on mac osx anymore making this even worse

On Mon, 11 Oct 2021, 11:35 Gerd Petermann <gpetermann_muenchen at hotmail.com>
wrote:

> Hi Carlos,
>
> there is no way to omit the writing of *.img files so far. The *.img files
> are used in the combiners.
> So, mkgmap first creates the *.img files and then reads them again to
> produce the index and *.tdb  and finally the other files.
> I don't know how much work it would be to skip the writing of .img. I also
> think that gmapsupp contains a collection of *.img files, but maybe those
> could be created on the fly...
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
> Carlos Dávila <carlos at alternativaslibres.org>
> Gesendet: Samstag, 9. Oktober 2021 11:17
> An: mkgmap-dev at lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting to
> disk if used with --gmapi option
>
> Sorry, not sure what you mean by "simply update zipped files". I create
> new zip files in a temporary directory and then replace online old ones.
> Note some maps are several GB in size. If someone is downloading such a
> map while I'm writing it ,download while fail and user will have to
> restart download, which may be annoying especially with low speed
> connections. Writing new zip files in a different location and then
> replacing downloadable files reduces the risk of the above problem.
>
> If you could find the way to build working MapSource/BaseCamp maps and
> also gmapsupp from tiles subfiles that would help me a lot reducing
> required disk space, but I can manage it if not. I missed one of your
> comments in a previous mail. I use nsis installer, but only to unzip
> *.gmap folder, so really no need to write single *.img files provided
> *.gmap and gmapsupp can be created from subfiles. By the way, is there
> currently an option in mkgmap to omit single *.img creation?
>
> El 8/10/21 a las 10:07, Gerd Petermann escribió:
> > Hi Carlos,
> >
> > can't you simply update the zipped files?
> >
> > I've learned that I was wrong. There is no code yet in mkgmap to process
> a single subfile, we have that only in display tool. I guess it is simple
> enough to implement this, but I don't know that part of the code very well.
> >
> > Gerd
> >
> > ________________________________________
> > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
> Carlos Dávila <carlos at alternativaslibres.org>
> > Gesendet: Montag, 4. Oktober 2021 23:22
> > An: mkgmap-dev at lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting
> to disk if used with --gmapi option
> >
> > I'll try to explain my (current) workflow. For each map I compile *.img
> > with updated OSM data. Then I combine them with precompiled contour
> > lines (currently saved as img) in a second step and in a third step I
> > combine  OSM img's with precompiled DEM (also saved as img). For each
> > map obtained in steps 1-3 I serve zipped gmap folder + nsis installler
> > which unzips gmap folder and place it in the right place to be used by
> > MapSource/BaseCamp. In order to take advantage of new gmapi-minimal
> > functionality I need to save both contour lines and DEM as gmap
> > subfiles, which will take me a while and will require a lot of disk
> > space, in fact more than I have available in my server at present.
> > That's why I would like to have an automated way to write or not gmap
> > subfiles, depending if they are already present or not.
> >
> > As for my second wish, I have realized I will probably have to keep
> > contour and DEM img's in disk, as building gmapsupp files for each set
> > described above may not be feasible from gmap subfiles.
> >
> > El 4/10/21 a las 8:37, Gerd Petermann escribió:
> >> Hi Carlos,
> >>
> >> everything is possible but this is more or less the opposite of the
> functionalty suggested by Felix.
> >> The first patch (gmapi-minimal.patch) implemented the check for
> existing (and write-protected) subfiles.
> >>
> >> I guess it all depends on the way how you organize the "constant"
> files. If you don't use the nsis installer it would indeed save time and
> space to omit the writing of single *.img files.
> >>
> >> Gerd
> >>
> >> ________________________________________
> >> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Carlos Dávila <carlos at alternativaslibres.org>
> >> Gesendet: Sonntag, 3. Oktober 2021 19:49
> >> An: mkgmap-dev at lists.mkgmap.org.uk
> >> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting
> to disk if used with --gmapi option
> >>
> >> Hi all,
> >>
> >> Would it be possible to add a check so that if some *.img are passed to
> >> mkgmap it looks for the corresponding subfiles and then, if they are
> >> present omit writing (do not overwrite), else write them? Also it would
> >> be great if real *.img files are not required when subfiles are present,
> >> so that it is not necessary to keep two copies of the same information
> >> in disk.
> >>
> >> Carlos
> >>
> >> El 21/9/21 a las 9:27, Gerd Petermann escribió:
> >>> Hi all,
> >>>
> >>> attached patch contains the docu for the new --gmapi-minimal option:
> >>> --gmapi-minimal[=<include-pattern>]
> >>>        Special option for map providers to reduce disk writes when
> updating. Works
> >>>        like --gmapi but does not write Product data for input files
> which are
> >>>        provided as *.img. It is assumed that the content of those
> files wasn't
> >>>        changed and thus doesn't need a rewrite. The optional
> include-pattern is a
> >>>        regular expression which can be used to specify *.img files for
> which a
> >>>        write should be forced. The pattern is used on the full path to
> the input
> >>>        file. The global index files and the *.tdb file will still
> contain all
> >>>        needed references.
> >>>        Example usage with pattern:
> >>>            --gmapi-minimal=.*4711[0-9]{4}\.img
> >>>            This pattern matches file names between 47110000.img and
> 47119999.img
> >>>            and ignores the path.
> >>>
> >>> So, I've also changed the handling of the optional include-pattern.
> Previous versions of the patch expected a comma-separated list of patterns.
> Now only one pattern is expected.
> >>> This allows to use the comma within the regex.
> >>>
> >>> Please let me know if something is unclear or could be improved
> otherwise.
> >>>
> >>> Gerd
> >>>
> >>> ________________________________________
> >>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Felix Hartmann <extremecarver at gmail.com>
> >>> Gesendet: Montag, 20. September 2021 13:56
> >>> An: Development list for mkgmap
> >>> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and
> converting to disk if used with --gmapi option
> >>>
> >>> Hi Gerd,
> >>>
> >>> i could not notice any problems with v4 either, address search and
> maps work in Mapsource/Basecamp and device as intended - I changed too many
> things to be able to properly test how much faster it is - but yeah some
> not needed reads less is surely good.
> >>>
> >>> On Mon, 20 Sept 2021 at 12:24, Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>>
> wrote:
> >>> Hi all,
> >>>
> >>> attached patch avoids to call MapReader multiple times for the
> combiners. The effect is rather small, as only two combiners actually use
> it: TdbBuilder and MdrBuilder.
> >>> Anyhow, those two are probably always called and there should be no
> negative impact even if none of them is called.
> >>>
> >>> I see 23 secs instead of 25 secs for the combiners with a map with 186
> (existing) tiles and ~ 880MB on a real hard disk. I assume that the real
> disk reads are not affected much as the disk caches should kick in with the
> old code.
> >>>
> >>> Gerd
> >>>
> >>> ________________________________________
> >>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>>
> >>> Gesendet: Samstag, 18. September 2021 10:33
> >>> An: Development list for mkgmap
> >>> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and
> converting to disk if used with --gmapi option
> >>>
> >>> Hi Felix,
> >>>
> >>> maybe another speed improvement is possible. I've noticed that each
> *.img file is read multiple times, e.g. by the TdbBuilder and the
> MdrBuilder.
> >>> I think it is possible to share the extracted info between the
> different combiners without using more memory.
> >>>
> >>> Gerd
> >>>
> >>> ________________________________________
> >>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>
> >>> Gesendet: Freitag, 17. September 2021 13:47
> >>> An: Development list for mkgmap
> >>> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and
> converting to disk if used with --gmapi option
> >>>
> >>> Thanks Gerd, I*ll likely not find time to test it before Monday
> afternoon... But I think it will do everything that is needed to write much
> less and speedup.
> >>>
> >>> On Fri, 17 Sept 2021 at 13:11, Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>>> wrote:
> >>> Hi all,
> >>>
> >>> attached is a new patch which implements experimental option
> --x-gmapi-minimal[=pattern list] like this:
> >>> - if used with no args the *.img files only those *.img files are
> written which were compiled in the same call (from *.osm, *.o5m, *.osm.pbf
> or *.mp)
> >>> So, java -jar mkgmap.jar ... --x-gmapi-minimal -c template.args
> 8812*.img <some_path>4711*.img
> >>> will not write the sub files of the img files 8812*.img or 4711*.img,
> but they will be added to the *.tdb file
> >>> - if used with a pattern list the patterns are interpreted as regular
> expresssions (not like file patterns). So, you can use e.g.
> >>> java -jar mkgmap.jar ... --x-gmapi-minimal=.*4711.*img -c
> template.args 8812*.img <some_path>4711*.img
> >>> to tell mkgmap that the 4711 (sub) files should also be written to the
> Product folder.
> >>> - I've remove the check regarding write protection of existing files,
> so this will cause an error as with the unpatched version when mkgmap is
> told to overwrite such a file.
> >>>
> >>> I've not tested this much so far but I think it works as expected. I'd
> prefer to use standard file patterns (*,?) for the include list but I don't
> know a java function for this. Any help would be welcomed.
> >>> I've created a binary with the patch, see
> https://files.mkgmap.org.uk/detail/518
> >>>
> >>> Gerd
> >>>
> >>> ________________________________________
> >>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>
> >>> Gesendet: Donnerstag, 16. September 2021 15:41
> >>> An: Development list for mkgmap
> >>> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and
> converting to disk if used with --gmapi option
> >>>
> >>> Hi Gerd,
> >>> maybe I've misread Thomas, but he said exclude not include list. No
> worries an include list makes sense  - while an exclude list really doesn't
> (at least I cannot think of a use for an exclude list). So definitely add
> an include list if you like. Include as in including .img that should be
> converted. All osm/o5m should be converted without being on the include
> list anyhow.´(because they would not be on that list if the .img existed
> already)
> >>>
> >>> As for the linking - yes please - do not check if the gmapi files
> exist (the .img have to exist anyway else we cannot build the mapset
> files). That way I could throw away the gmapi contourlines on the render
> server - and only keep them on the download server already zipped (for all
> files that one decides to take out of the main download to make it smaller.
> E.g. for Asia continent 20m contourlines are like 5x the size of the map or
> so - so better the user on update can download the map files only without
> the contourlines). Essentially it's like 350GB just lying around to be
> linked but no other sense for me.
> >>> So you only need a copy of the .img files - not another copy of the
> gmapi files for rendering the maps (and you do not need to create 0byte
> files to link so they cannot be overwritten as an alternative).
> >>>
> >>> On Thu, 16 Sept 2021 at 15:19, Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>>>>
> wrote:
> >>> Hi Felix,
> >>>
> >>> what do you mean with exclude list? I suggested a possible
> include-list to specify more files which are overwritten even if they
> already exist.
> >>> Regarding linking: OK, you just want a new tdb file containing all
> listed input files? No check if the output file really exists?
> >>>
> >>> Gerd
> >>>
> >>> ________________________________________
> >>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>>
> >>> Gesendet: Donnerstag, 16. September 2021 14:11
> >>> An: Development list for mkgmap
> >>> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and
> converting to disk if used with --gmapi option
> >>>
> >>> I would prefer if I don't even need to link anything, just the concept
> that only o5m and osm.pbf input is converted. I can keep the converted
> contour lines on the server too, but it would be nicer if I don't even need
> to have them for all maps where I have them as separate download.
> >>>
> >>> If that is working all is perfect. I don't see a usecase for an
> exclude list.
> >>>
> >>> On Thu, 16 Sep 2021, 11:11 Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> >>><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com>><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>>>>> wrote:
> >>> Hi all,
> >>>
> >>> OK, I think I can add code to detect the img files which were compiled
> in the same call of mkgmap. So, with option --gmapi-minimal
> >>> - Files in this list always need to be written. It should be possible
> to evaluate a parameter list that specifies additional file patterns.
> >>> - Files which don't yet exist in the gmapi folder are also written.
> >>> - other files in the Product subfolder would not be touched
> >>> - the Info.xml will contain all files listed as input
> >>>
> >>> So, either just --gmapi-minimal or --gmapi-minimal[=<patterns for
> files which should overwritten>]
> >>>
> >>> Would that work well for all?
> >>>
> >>> Gerd
> >>>
> >>>
> >>> ________________________________________
> >>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>>>> im Auftrag von Felix Hartmann
> <extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>>>
> >>> Gesendet: Montag, 13. September 2021 20:44
> >>> An: Thomas Morgenstern; Development list for mkgmap
> >>> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and
> converting to disk if used with --gmapi option
> >>>
> >>> .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 at img2ms.de
> <mailto:webmaster at img2ms.de><mailto:webmaster at img2ms.de<mailto:
> webmaster at img2ms.de>><mailto:webmaster at img2ms.de<mailto:
> webmaster at img2ms.de><mailto:webmaster at img2ms.de<mailto:webmaster at img2ms.de
> >>><mailto:webmaster at img2ms.de<mailto:webmaster at img2ms.de><mailto:
> webmaster at img2ms.de<mailto:webmaster at img2ms.de>><mailto:
> webmaster at img2ms.de<mailto:webmaster at img2ms.de><mailto:webmaster at img2ms.de
> <mailto:webmaster at img2ms.de>>>><mailto:webmaster at img2ms.de<mailto:
> webmaster at img2ms.de><mailto:webmaster at img2ms.de<mailto:webmaster at img2ms.de
> >><mailto:webmaster at img2ms.de<mailto:webmaster at img2ms.de><mailto:
> webmaster at img2ms.de<mailto:webmaster at img2ms.de>>><mailto:
> webmaster at img2ms.de<mailto:webmaster at img2ms.de><mailto:webmaster at img2ms.de
> <mailto:webmaster at img2ms.de>><mailto:webmaster at img2ms.de<mailto:
> webmaster at img2ms.de><mailto:webmaster at img2ms.de<mailto:webmaster at 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 at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> >>><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com>><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>>>><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> >><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com>>><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at 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 at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>>>>> im Auftrag von Felix
> Hartmann <extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at 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 at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> >>><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com>><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>>>><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> >><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com>>><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> >>>>><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com>><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>>><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> >><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com>>>><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> >>><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com>><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at 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 at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>>>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>>>>>> im Auftrag von Felix
> Hartmann <extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at 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 at gmail.com
> <mailto:extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>>>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at 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 at gmail.com
> <mailto:extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto: <extremecarver at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20211011/57ec923f/attachment-0001.html>