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
<[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> im Auftrag von
Carlos Dávila <[email protected]
<mailto:[email protected]>>
Gesendet: Samstag, 9. Oktober 2021 11:17
An: [email protected]
<mailto:[email protected]>
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 <[email protected]
<mailto:[email protected]>> im Auftrag von
Carlos Dávila <[email protected]
<mailto:[email protected]>>
> Gesendet: Montag, 4. Oktober 2021 23:22
> An: [email protected]
<mailto:[email protected]>
> 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 <[email protected]
<mailto:[email protected]>> im Auftrag von
Carlos Dávila <[email protected]
<mailto:[email protected]>>
>> Gesendet: Sonntag, 3. Oktober 2021 19:49
>> An: [email protected]
<mailto:[email protected]>
>> 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 <[email protected]
<mailto:[email protected]>> im Auftrag von
Felix Hartmann <[email protected]
<mailto:[email protected]>>
>>> 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
<[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>> 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 <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>> im Auftrag von
Gerd Petermann <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>
>>> 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 <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>> im Auftrag von
Felix Hartmann <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>
>>> 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
<[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>> 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
<https://files.mkgmap.org.uk/detail/518>
>>>
>>> Gerd
>>>
>>> ________________________________________
>>> Von: mkgmap-dev <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>> im Auftrag von
Felix Hartmann <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>
>>> 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
<[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>> 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 <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>> im Auftrag von
Felix Hartmann <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>
>>> 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
<[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>> 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 <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>> im Auftrag
von Felix Hartmann <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>>
>>> 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
<[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>>> 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
<[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>>> 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 <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>>> im Auftrag
von Felix Hartmann <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>>>
>>> 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
<[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>>>> 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 <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>>>> im Auftrag
von Felix Hartmann <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>>>>
>>> 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
<[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>>>>>> 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
<[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>><mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>><mailto:
_______________________________________________
mkgmap-dev mailing list
[email protected]
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
