A simple question ( I hope!): I have a number of pbf format files containing contour information derived from SRTM2OSM. Since they were downloaded separately, they appear to have duplicate node and way IDs. Will this matter to mkgmap if they are all listed together in template.args, or do they need to be compiled individually? Also, osmconvert reports 4 IDs in the wrong order in each file (exactly the same in each). Will this cause any problem? Many thanks, Roger -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------
Roger Calvert wrote
A simple question ( I hope!):
I have a number of pbf format files containing contour information derived from SRTM2OSM.
Since they were downloaded separately, they appear to have duplicate node and way IDs. Will this matter to mkgmap if they are all listed together in template.args, or do they need to be compiled individually?
I don't think so. Each input file is processed with its own job. Roger Calvert wrote
Also, osmconvert reports 4 IDs in the wrong order in each file (exactly the same in each). Will this cause any problem?
No, mkgmap doesn't care about the order of ids in the input file. Osmconvert only reports the first 4 occurrences of this problem. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Duplicate-IDs-tp5743232p5743262.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Thanks, Gerd. There seems to be a lack of compatibility between SRTM2OSM files and other programs. Having converted them to pbf with OSMConvert, the files would not compile - no errors - just produced essentially empty IMG files. After a lot of experimentation, it turned out that the problem was the 19 digit (64 bit) IDs in the files. But since they all start with the same sequence, I was able to cut this back to 8 digits with Notepad++ (not a quick process). They then compiled. There must be an easier way! I know mkgmap can cope with 11 digit IDs, but it seems it can't handle 19. What is the limit? (During the process I also discovered that Osmosis seems to take 8 but not 10 - I haven't tried 9). Thanks again for the advice. Roger On 07/01/2013 18:44, GerdP wrote:
Roger Calvert wrote
A simple question ( I hope!):
I have a number of pbf format files containing contour information derived from SRTM2OSM.
Since they were downloaded separately, they appear to have duplicate node and way IDs. Will this matter to mkgmap if they are all listed together in template.args, or do they need to be compiled individually? I don't think so. Each input file is processed with its own job.
Roger Calvert wrote
Also, osmconvert reports 4 IDs in the wrong order in each file (exactly the same in each). Will this cause any problem? No, mkgmap doesn't care about the order of ids in the input file. Osmconvert only reports the first 4 occurrences of this problem.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/Duplicate-IDs-tp5743232p5743262.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------
Roger Calvert wrote
There seems to be a lack of compatibility between SRTM2OSM files and other programs. Having converted them to pbf with OSMConvert, the files would not compile - no errors - just produced essentially empty IMG files. After a lot of experimentation, it turned out that the problem was the 19 digit (64 bit) IDs in the files. But since they all start with the same sequence, I was able to cut this back to 8 digits with Notepad++ (not a quick process). They then compiled. There must be an easier way!
In general, mkgmap allows all kinds of ids, but it also uses a FakeIdGenerator to produce ids for some generated objects. These ids start with 1L<<62, or 2.305.843.009.213.693.952 There is no check to make sure that input files do not contain ids in this range, so maybe this cause a problem. Regarding Notepad++ : Maybe sed is a better tool for this, it is also awailable for windows. I don't know any OSM specific tool to "re-number" the ids. It would also be possible to add a conversion routine to mkgmap or splitter as long as you just want to subtract a constant from each id. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Duplicate-IDs-tp5743232p5743285.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
GerdP wrote
These ids start with 1L<<62, or 2.305.843.009.213.693.952
correction: 1L<<62 means 4.611.686.018.427.387.904 Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Duplicate-IDs-tp5743232p5743286.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 07/01/2013 20:12, GerdP wrote:
Regarding Notepad++ : Maybe sed is a better tool for this, it is also awailable for windows. I don't know any OSM specific tool to "re-number" the ids. It would also be possible to add a conversion routine to mkgmap or splitter as long as you just want to subtract a constant from each id. I probably won't want to do this often! And after the first two, I wrote a special purpose filter (in C#) which did it much faster than Notepad++ even allowing for the programming time!
Thanks again Roger -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------
Roger Calvert wrote
I probably won't want to do this often! And after the first two, I wrote a special purpose filter (in C#) which did it much faster than Notepad++ even allowing for the programming time!
FYI: I tried to find out why mkgmap would have problems with the data produced by SRTM2OSM, but I did not see a problem, it can cope with the 19-digit ids . I assume the problem is caused by another program in your tool chain. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Duplicate-IDs-tp5743232p5743374.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Mon, Jan 07, Roger Calvert wrote:
There seems to be a lack of compatibility between SRTM2OSM files and other programs.
You should take a look at phyghtmap. That one works very well for a lot of people and active maintained. And compatible with other OSM tools. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
participants (3)
-
GerdP -
Roger Calvert -
Thorsten Kukuk