Hi Steve, WanMil, I think the FakeIdGenerator should be changed. As Rogert Calvert pointed out, other tools like SRTM2OSM generate OSM data with IDs like "9223372036854775807" These ids may be treated as fake ids by the FakeIdGenerator.isFakeId() method which is too simple. Possible solutions: - the reader should stop with an error message if an OSM id is found that is higher than FakeIdGenerator.START_ID or - the FakeIdGenerator should be changed to allow a parameter which gives a start value (or maybe a range ) What do you think? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/FakeIdGenerator-tp5743379.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd,
Hi Steve, WanMil,
I think the FakeIdGenerator should be changed. As Rogert Calvert pointed out, other tools like SRTM2OSM generate OSM data with IDs like "9223372036854775807"
do you know any other tool than SRTM2OSM? If it's only SRTM2OSM I guess there is no problem. The history of SRTM2OSM tells that version 1.10 starts with IDs at 2^63-1 counting down. So there are 4611686018427387903 ids until it conflicts with mkgmaps FakeIdGenerator. I haven't followed the whole thread. Did Roger use the latest version of SRTM2OSM?
These ids may be treated as fake ids by the FakeIdGenerator.isFakeId() method which is too simple.
Possible solutions: - the reader should stop with an error message if an OSM id is found that is higher than FakeIdGenerator.START_ID
A warning doesn't harm. But I would not stop the reader because otherwise you cannot use SRTM2OSM any more.
or - the FakeIdGenerator should be changed to allow a parameter which gives a start value (or maybe a range )
At the moment we try to reduce the number of options. So I don't want to create a new one here. There might be some other strategies: 1. Using negative Ids. I don't know if that conflicts with other tools. 2. Using a new generator for each file. This could be implemented as ThreadLocal and resetted each time a file starts. This reduces the id range that is required. Of course if another tool uses the same id range you will have the same problems again. But the only tool which I can remember that caused problems is SRTM2OSM. WanMil
What do you think?
Gerd
WanMil wrote
do you know any other tool than SRTM2OSM? If it's only SRTM2OSM I guess there is no problem. The history of SRTM2OSM tells that version 1.10 starts with IDs at 2^63-1 counting down. So there are 4611686018427387903 ids until it conflicts with mkgmaps FakeIdGenerator.
No, I don't know other tools, but you are not right. Any id larger than 2^62 is considered to be a fakeid: public static boolean isFakeId(long id) { return id >= startId; } I think we should at least limit this range. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/FakeIdGenerator-tp5743379p5743475.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
As Thorsten said phyghtmap. Pain to set up on 64 bit system but good results. Geoff GerdP <gpetermann_muenchen@hotmail.com> wrote:
WanMil wrote
do you know any other tool than SRTM2OSM? If it's only SRTM2OSM I guess there is no problem. The history of SRTM2OSM tells that version 1.10 starts with IDs at 2^63-1 counting down. So there are 4611686018427387903 ids until it conflicts with mkgmaps FakeIdGenerator.
No, I don't know other tools, but you are not right. Any id larger than 2^62 is considered to be a fakeid:
public static boolean isFakeId(long id) { return id >= startId; }
I think we should at least limit this range.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/FakeIdGenerator-tp5743379p5743475.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
Geoff Sherlock wrote
As Thorsten said phyghtmap. Pain to set up on 64 bit system but good results.
Geoff
I think WanMil asked for other tools that generate OSM ids with 64 bits. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/FakeIdGenerator-tp5743379p5743483.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Tue, Jan 08, GerdP wrote:
Geoff Sherlock wrote
As Thorsten said phyghtmap. Pain to set up on 64 bit system but good results.
Geoff
I think WanMil asked for other tools that generate OSM ids with 64 bits.
phyghtmap generates 64 bit IDs if there are enough nodes or if you specify a large enough start ID. So call "phyghtmap --start-node-id=9223372036854775800 ..." 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)
I have (eventually) got phyghtmap working - gave up on Python 3.3 and 64 bit and installed Python 2.7 and 32 bit, which works OK. The main problem I have with phyghtmap is spelling it! So that problem has gone away for me, but It might be good defensive programming to issue a warning if there is likely to be a problem with IDs. Thanks to all for advice on this. Roger On 08/01/2013 19:50, Geoff Sherlock wrote:
As Thorsten said phyghtmap. Pain to set up on 64 bit system but good results.
Geoff
GerdP <gpetermann_muenchen@hotmail.com> wrote:
WanMil wrote
do you know any other tool than SRTM2OSM? If it's only SRTM2OSM I guess there is no problem. The history of SRTM2OSM tells that version 1.10 starts with IDs at 2^63-1 counting down. So there are 4611686018427387903 ids until it conflicts with mkgmaps FakeIdGenerator.
No, I don't know other tools, but you are not right. Any id larger than 2^62 is considered to be a fakeid:
public static boolean isFakeId(long id) { return id >= startId; }
I think we should at least limit this range.
Gerd
-- View this message in context:http://gis.19327.n5.nabble.com/FakeIdGenerator-tp5743379p5743475.html Sent from the Mkgmap Development mailing list archive atNabble.com <http://Nabble.com>. ------------------------------------------------------------------------
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------
WanMil wrote
do you know any other tool than SRTM2OSM? If it's only SRTM2OSM I guess there is no problem. The history of SRTM2OSM tells that version 1.10 starts with IDs at 2^63-1 counting down. So there are 4611686018427387903 ids until it conflicts with mkgmaps FakeIdGenerator.
No, I don't know other tools, but you are not right. Any id larger than 2^62 is considered to be a fakeid:
public static boolean isFakeId(long id) { return id >= startId; }
I think we should at least limit this range.
Why? mkgmap checks for a fake id only at 2 points: Multipolygon: some logging is changed in case it is a fake id or not. SeaGenerator: some coastline ways are copied when they don't have a fake id.
Gerd
WanMil wrote
I think we should at least limit this range.
Why? mkgmap checks for a fake id only at 2 points: Multipolygon: some logging is changed in case it is a fake id or not. SeaGenerator: some coastline ways are copied when they don't have a fake id.
OK, so the potential problem is small, but would it be a problem to change isFakeId() to something like this? public static boolean isFakeId(long id) { return id >= startId && id < startId + 1L << 32; } Gerd -- View this message in context: http://gis.19327.n5.nabble.com/FakeIdGenerator-tp5743379p5743507.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
WanMil wrote
I think we should at least limit this range.
Why? mkgmap checks for a fake id only at 2 points: Multipolygon: some logging is changed in case it is a fake id or not. SeaGenerator: some coastline ways are copied when they don't have a fake id.
OK, so the potential problem is small, but would it be a problem to change isFakeId() to something like this? public static boolean isFakeId(long id) { return id >= startId && id < startId + 1L << 32; }
Gerd
Sorry, I do not understand which problem you want to fix with that. I don't see a problem :-) Anyhow I don't know how many fake id's are generated in a common tile or in all tiles of a whole planet. This number must be lower than 1L<<32 and it should be much lower than 1L<<32 for a long time. Otherwise this patch will create problems in future when this limit is exceeded. So I would not apply this patch without a good reason. WanMil
WanMil wrote
Sorry, I do not understand which problem you want to fix with that. I don't see a problem :-)
Anyhow I don't know how many fake id's are generated in a common tile or in all tiles of a whole planet. This number must be lower than 1L<<32 and it should be much lower than 1L<<32 for a long time. Otherwise this patch will create problems in future when this limit is exceeded. So I would not apply this patch without a good reason.
Well, I just don't like the fact the this method can return wrong results for the 19 digit ids. But you are right that my simple patch will exchange one potential problem with another. I'd prefer a patch that checks the generated ids and the ids in the input file as well. I can post that tomorrow. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/FakeIdGenerator-tp5743379p5743819.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (5)
-
Geoff Sherlock -
GerdP -
Roger Calvert -
Thorsten Kukuk -
WanMil