Random changes in img file sizes since r2477
Hi, I think something is wrong. I get different output img file sizes for the same input files and parms and program. With each run, some files are a bit larger or smaller than before. My options: --max-jobs --preserve-element-order -c template.args This doesn't happen with r2476 and older versions, first rel with the problem is r2477 which brought the new mp-cut algo. @WanMil: Is it possible to change that? Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Random-changes-in-img-file-sizes-since-r2477-... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi,
I think something is wrong. I get different output img file sizes for the same input files and parms and program. With each run, some files are a bit larger or smaller than before. My options: --max-jobs --preserve-element-order -c template.args
This doesn't happen with r2476 and older versions, first rel with the problem is r2477 which brought the new mp-cut algo.
@WanMil: Is it possible to change that?
I don't have a clue. As far as I can see the mp cut algorithm is constant - same input should create the same output.
Ciao, Gerd
WanMil wrote
@WanMil: Is it possible to change that?
I don't have a clue. As far as I can see the mp cut algorithm is constant - same input should create the same output.
I did not debug yet, but I assume the HashMap outOfBboxPoints could be the cause. Maybe this must be an IdentityHashMap? I'll try that tomorrow if you can't find anything else. Ciao Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Random-changes-in-img-file-sizes-since-r2477-... Sent from the Mkgmap Development mailing list archive at Nabble.com.
WanMil wrote
@WanMil: Is it possible to change that?
I don't have a clue. As far as I can see the mp cut algorithm is constant - same input should create the same output.
I did not debug yet, but I assume the HashMap outOfBboxPoints could be the cause. Maybe this must be an IdentityHashMap?
This has not been changed since r1953 so it should not be the cause.
I'll try that tomorrow if you can't find anything else.
Ciao Gerd
Hi WanMil, I think the problem is in CutPoint compareTo(). In some cases it uses hashCode() to decide which one is better, but hashCode() is not overwritten, so the result is undetermined. Gerd WanMil wrote
WanMil wrote
@WanMil: Is it possible to change that?
I don't have a clue. As far as I can see the mp cut algorithm is constant - same input should create the same output.
I did not debug yet, but I assume the HashMap outOfBboxPoints could be the cause. Maybe this must be an IdentityHashMap?
This has not been changed since r1953 so it should not be the cause.
I'll try that tomorrow if you can't find anything else.
Ciao Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Random-changes-in-img-file-sizes-since-r2477-... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Thanks Gerd, I overlooked the hashCode(). I have removed the hashCode() from the compare method. Please test attached patch. WanMil
Hi WanMil,
I think the problem is in CutPoint compareTo(). In some cases it uses hashCode() to decide which one is better, but hashCode() is not overwritten, so the result is undetermined.
Gerd
WanMil wrote
WanMil wrote
@WanMil: Is it possible to change that?
I don't have a clue. As far as I can see the mp cut algorithm is constant - same input should create the same output.
I did not debug yet, but I assume the HashMap outOfBboxPoints could be the cause. Maybe this must be an IdentityHashMap?
This has not been changed since r1953 so it should not be the cause.
I'll try that tomorrow if you can't find anything else.
Ciao Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Random-changes-in-img-file-sizes-since-r2477-... 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
Hi WanMil, I did not try, but looking at the patch I am sure that this will fix the problem. Gerd Date: Tue, 26 Feb 2013 22:44:38 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] [PATCH v1] Random changes in img file sizes since r2477 Thanks Gerd, I overlooked the hashCode(). I have removed the hashCode() from the compare method. Please test attached patch. WanMil
Hi WanMil,
I think the problem is in CutPoint compareTo(). In some cases it uses hashCode() to decide which one is better, but hashCode() is not overwritten, so the result is undetermined.
Gerd
WanMil wrote
WanMil wrote
@WanMil: Is it possible to change that?
I don't have a clue. As far as I can see the mp cut algorithm is constant - same input should create the same output.
I did not debug yet, but I assume the HashMap outOfBboxPoints could be the cause. Maybe this must be an IdentityHashMap?
This has not been changed since r1953 so it should not be the cause.
I'll try that tomorrow if you can't find anything else.
Ciao Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Random-changes-in-img-file-sizes-since-r2477-... 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (3)
-
Gerd Petermann -
GerdP
-
WanMil