logo separator

[mkgmap-dev] The x prepended to the *.typ file

From Ticker Berkin rwb-mkgmap at jagit.co.uk on Sun Sep 19 22:53:35 BST 2021

Hi

My reading of the code is that it won't create an x-version that is
identical to the original, so I don't understand what Dave observes.

I think the best solution is as Gerd suggests, if the binary input .typ
file has the wrong family/product and is in the output direction, an
error should be flagged. If it is in another directory, a patched
version with the same name should be created in the output directory.

Ticker

On Sun, 2021-09-19 at 10:35 -0700, Dave Swarthout wrote:
> FYI
> 
> In my workflow, the source TYP file is not modified. Both TYP files,
> the original and the x-version, are identical. However, my TYP file
> is not a text file; it is a binary file that the TYPViewer program
> generates. How that plays in this scenario I have no idea.
> 
> On Sun, Sep 19, 2021 at 9:56 AM Gerd Petermann <
> gpetermann_muenchen at hotmail.com> wrote:
> > Hi Ticker,
> > 
> > OK, I agree that it isn't the best idea to modify a source file.
> > So, maybe mkgmap should stop with an error message if that would
> > happen?
> > 
> > Gerd
> > 
> > ________________________________________
> > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > Gesendet: Sonntag, 19. September 2021 18:31
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file
> > 
> > Hi
> > 
> > With mkgmap compiling the .txt to .typ there is no problem - I'm
> > assuming this question is only concerned with what happens when
> > starting with a binary .typ file.
> > 
> > If the .typ file already exists and has the wrong family/product
> > and is
> > in the directory that mkgmap will use for output files, then the
> > options are:
> > 
> > 1/ change the original .typ file, patching the family/product;
> >   - it must be wrong to change an input file.
> > 
> > 2/ use a different directory for the patched version;
> >    - but where?
> > 
> > 3/ use a different name for for the patched version;
> >    - this could be improved, so that rather than prefixing with x,
> > a
> >    clearer suffix is added to the actual file but when this is
> > added
> >    to gmapi/gmapsupp, the original name is used for the embedded
> >    component.
> > 
> > At the moment mkgmap ignores the last condition "... is in the same
> > directory ...", but this could be tested and, if not, the name
> > could be
> > kept and the new file created in the natural output directory.
> > 
> > Ticker
> > 
> > On Sun, 2021-09-19 at 08:38 -0700, Dave Swarthout wrote:
> > > I have wondered where that "x-file" came from for years. To me,
> > it's
> > > totally unnecessary and confusing. I thought my typ file editor,
> > > TypViewer, was creating it.
> > > Even after reading the email and replies, I still don't
> > understand
> > > the reasoning behind having mkgmap creating this "backup" copy in
> > the
> > > first place but I think it should be got rid of.
> > >
> > > Thanks for clearing up the mystery!
> > >
> > > Dave
> > >
> > > On Sun, Sep 19, 2021 at 4:30 AM Gerd Petermann <
> > > gpetermann_muenchen at hotmail.com> wrote:
> > > > Hi Ticker,
> > > >
> > > > please explain why mkgmap is "stuck" with the fixed version.
> > What's
> > > > the difference between a fixed *.typ file and one that is
> > freshly
> > > > compiled from *.txt?
> > > >
> > > > Gerd
> > > >
> > > > ________________________________________
> > > > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im
> > Auftrag
> > > > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > > > Gesendet: Sonntag, 19. September 2021 13:25
> > > > An: Development list for mkgmap; Steve Ratcliffe
> > > > Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file
> > > >
> > > > Hi
> > > >
> > > > If you don't use --output_dir but have map sources (.osm.pbf)
> > and
> > > > results (.img) all in the same place, and you specify a pre
> > -built
> > > > TYPfile with extension .typ, but it has the wrong
> > family/product,
> > > > mkgmap can adjust these, but is then stuck as to what to do
> > with
> > > > the
> > > > fixed version, hence the "x" prefix to deal with this case.
> > > >
> > > > If --output-dir is specified and the .typ file wasn't in that
> > when
> > > > specified as an input parameter, then could avoid the rename.
> > > >
> > > > This doesn't effect me as I always use mkgmap to generate the
> > .typ
> > > > from
> > > > the .txt as part of the final map generation process.
> > > >
> > > > Ticker
> > > >
> > > > On Sun, 2021-09-19 at 10:22 +0000, Gerd Petermann wrote:
> > > > > Hi all,
> > > > >
> > > > > I think there is an old rather confusing glitch in mkgmap
> > class
> > > > > TypSaver which it is used with a *.typ file as input, as in
> > > > > java -jar mkgmap.jar --output-dir=<map-folder> --family
> > -id=4711
> > > > ...
> > > > > -c splitter-dir\template.args ..\typfiles\existing.typ
> > > > > to make sure that family-id and product-id are correctly
> > updated
> > > > in
> > > > > the *.typ file.
> > > > > Since 2012 the program creates / overwrites a copy of file
> > > > > existing.typ in the source(!) directory ..\typfiles with the
> > > > prefix
> > > > > "x", so ..\typfiles\xexisting.typ is written instead of
> > > > > <map-folder>\existing.typ. I can't find it now but I think
> > there
> > > > were
> > > > > complains that this name doesn't fit the 8+3 rule for old
> > file
> > > > > systems and causes trouble on some devices.
> > > > >
> > > > > I think when Steve coded this he expected that the *.typ file
> > is
> > > > in
> > > > > the output directory, not somewhere else. My conclusions:
> > > > > - I think it is an error to create the copy in the source
> > > > directory.
> > > > > - I see no reason to create a copy with the prepended "x", I
> > > > would
> > > > > just create or alter the file in the given output directory.
> > > > >
> > > > > @Steve: What case am I missing? What's the reason for the
> > > > different
> > > > > name in the copy?
> > > > > @all: Does anybody rely on this behaviour?
> > > > >
> > > > > Gerd
> > > > > _______________________________________________
> > > > > mkgmap-dev mailing list
> > > > > mkgmap-dev at lists.mkgmap.org.uk
> > > > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > > _______________________________________________
> > > > mkgmap-dev mailing list
> > > > mkgmap-dev at lists.mkgmap.org.uk
> > > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > > _______________________________________________
> > > > mkgmap-dev mailing list
> > > > mkgmap-dev at lists.mkgmap.org.uk
> > > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > >
> > >
> > > _______________________________________________
> > > mkgmap-dev mailing list
> > > mkgmap-dev at lists.mkgmap.org.uk
> > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > 
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


More information about the mkgmap-dev mailing list