I just answered in the old topic - but it would make it very complicated if
you had some tiles that you need to split again. I feel --gmapi converts
everything - while --gmapi-minimal only converts input given in
.o5m/osm.pbf/osm is the much better approach. The first time you use
--gmapi - all
.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
Hi Thomas,
yes, I also thought about something like that. I still have to learn some
details of the gmapi format and the generated files and dependencies between
them.
Gerd
Von: mkgmap-dev im Auftrag von Thomas
Morgenstern
Gesendet: Montag, 13.
I suggest the new option should be named /reuse=files, wildcards enabled>. /exampel /reuse=4001.img, 40005*.img. /If
this option is used, then mkgmap should not overwrite the listed folders
in the gmap. Naturally mkgmap should writea new tdb, preview.img,
mdr and idx. In most cases the
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
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
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
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
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
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,
Thanks Gerd,
but that is just removing the warning if it cannot overwrite, correct?
If it can overwrite the gmap file it will still overwrite it as I see.. So
in essence just a bit more intelligent then my disabling that line.
I think it should not overwrite at all if present and
I think just remove the warning. I could not notice any problem due to it (
and if there would be problems, by now at least one user of my maps should
have complained)
On Mon, 13 Sept 2021 at 12:09, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Hi,
>
> yes, I think that message
Hi,
yes, I think that message makes no sense in this situation. I am not sure why I
decided to log this as an error.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3679
I've attached a patch to suppress the message if the input file is a ovm_*.img.
I could also simply reduce
Hi all,
attached is a quick patch that implements experimaltal option --x-gmapi-minimal.
If used instead of --gmapi mkgmap will not fail if a write-protected output
file exists in the gmapi output folder and mkgmap copies data from *.img. It
should still crash when other files like Info.xml
14 matches
Mail list logo
