
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

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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com

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@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

I think - modify source file if .typ is in the output directory. Do not modify but write a new typfile (same name) if not in output directory. For me that makes most sense. But anything is fine - also the current behaviour. On Sun, 19 Sept 2021 at 19:56, Gerd Petermann < gpetermann_muenchen@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org

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@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com

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@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Why would you have mkgmap modify a TYP file for any reason? (FYI: My output goes to the same directory that contains my input files.) I would much rather see some sort of error message than have an undocumented (AFAIK) feature modify my TYP file, especially since there is no indication of that behaviour in the error stream. I've seen this x-file for years and could not (and still don't) see why it exists. Both TYP files always prove to be identical when checked by the ExamDiff program). Reiterating, if there is some sort of conflict in family/product numbers, let the user know about it through error messages and suggest remedies. But don't change his/her TYP file behind the scenes. On Sun, Sep 19, 2021 at 2:53 PM Ticker Berkin <rwb-mkgmap@jagit.co.uk> wrote:
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@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com

Hi Dave, the typ file contains fields for the family-id and the product-id. If those don't match the values used in the map it will not work, that's why mkgmap creates a copy. As Ticker said, there is code to prevent that a correct typ file is overwritten, so I wonder how you manage to have the x-file with identical content. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Dave Swarthout <daveswarthout@gmail.com> Gesendet: Montag, 20. September 2021 02:08 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file Why would you have mkgmap modify a TYP file for any reason? (FYI: My output goes to the same directory that contains my input files.) I would much rather see some sort of error message than have an undocumented (AFAIK) feature modify my TYP file, especially since there is no indication of that behaviour in the error stream. I've seen this x-file for years and could not (and still don't) see why it exists. Both TYP files always prove to be identical when checked by the ExamDiff program). Reiterating, if there is some sort of conflict in family/product numbers, let the user know about it through error messages and suggest remedies. But don't change his/her TYP file behind the scenes. On Sun, Sep 19, 2021 at 2:53 PM Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> wrote: 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@hotmail.com<mailto:gpetermann_muenchen@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@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@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@hotmail.com<mailto:gpetermann_muenchen@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@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@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@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com

Hi Gerd, It's probably because I don't use the default family id. I substitute my own to prevent problems when using more than one map in my GPSr. Here's my command line for my Eugene (Oregon) maps: java -Xmx4000m -jar mkgmap.jar -c DJS.cfg --latin1 --family-id=24566 --name-tag-list=name,loc_name,int_name,alt_name --description="Eugene" "C:\Users\Alask\Downloads\Maps\Eugene.osm" "C:\Users\Alask\Dropbox (Personal)\Mapping\24983djs.TYP" When compiling a map of Thailand, I use family-id=18028 and description="Thailand" in my command line. I picked those numbers out of the air, so to speak. It's an easy solution that eliminates "conflicts" when checking my maps with the JaVaWa Device Manager. My maps work fine so I presume these changes are a good fix. I don't use splitter; all my maps are for areas that require OSM downloads of less than 1 GByte. Dave On Sun, Sep 19, 2021 at 11:23 PM Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Dave,
the typ file contains fields for the family-id and the product-id. If those don't match the values used in the map it will not work, that's why mkgmap creates a copy. As Ticker said, there is code to prevent that a correct typ file is overwritten, so I wonder how you manage to have the x-file with identical content.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Dave Swarthout <daveswarthout@gmail.com> Gesendet: Montag, 20. September 2021 02:08 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file
Why would you have mkgmap modify a TYP file for any reason? (FYI: My output goes to the same directory that contains my input files.)
I would much rather see some sort of error message than have an undocumented (AFAIK) feature modify my TYP file, especially since there is no indication of that behaviour in the error stream. I've seen this x-file for years and could not (and still don't) see why it exists. Both TYP files always prove to be identical when checked by the ExamDiff program). Reiterating, if there is some sort of conflict in family/product numbers, let the user know about it through error messages and suggest remedies. But don't change his/her TYP file behind the scenes.
On Sun, Sep 19, 2021 at 2:53 PM Ticker Berkin <rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk>> wrote: 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@hotmail.com<mailto:gpetermann_muenchen@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@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@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@hotmail.com<mailto: gpetermann_muenchen@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@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@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@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com
-- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com

Hi all, to avoid both the prepended "x" and stopping with an error message mkgmap could write the modified copy to a temp directory. That way there would be no need to change the file name and no problem with altered source files. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Sonntag, 19. September 2021 23:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file 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@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi all, sorry, a new temp directoy wouldn't work with the --nsis option. So, stopping with an error is probably the best option (see attached patch) I just don't like that this is likely to happen after(!) most *.img files are compiled. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Montag, 20. September 2021 08:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file Hi all, to avoid both the prepended "x" and stopping with an error message mkgmap could write the modified copy to a temp directory. That way there would be no need to change the file name and no problem with altered source files. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Sonntag, 19. September 2021 23:53 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file 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@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Gerd Ticker is right about the reasoning. Perhaps if I had chosen a completely different name with the family id such as 'mkg6324.typ' no one would have thought it was so weird. You are right that it probably should be created in the output-dir like all the other compilation steps. You could avoid changing the file base name if it is writing to a different directory than the input file. Steve
participants (6)
-
Dave Swarthout
-
Felix Hartmann
-
Gerd Petermann
-
Gerd Petermann
-
Steve Ratcliffe
-
Ticker Berkin