error in NumberPreparer?
Hi Steve, it seems that NumberPreparer (in trunk) doesn't completely ignore the start/end values when numberStyle == NONE. See line 116: if (first.getLeftStart() > first.getLeftEnd() || first.getRightStart() > first.getRightEnd()) initial = Math.max(initial, rightStart); else if (rightStart > 0) initial = Math.min(initial, rightStart); In normal processing, the fields are 0 when style is NONE, but NumberRangeTest.java sets them to -1 and this really produces different bit streams in some cases, e.g. when iter == 306 the following test case is generated: [0,O,9,7,O,7,5, 1,B,8,2,O,3,5, 2,O,1,1,N,-1,-1] and the patch numbers-v0.patch causes a test failure. Attached version 1 of the patch solves this issue, but I think the problem should be fixed in the preparer and the test should be adapted? Gerd
Hi Gerd
it seems that NumberPreparer (in trunk) doesn't completely ignore the start/end values when numberStyle == NONE.
I was just going to post that the patch failed with NumberRangeTest, wheras trunk passes. It seems you may have found the answer but I don't think this code should be reached when both styles are NONE since it should have exited at numbers.isEmpty() -- at least in the original code.
See line 116: if (first.getLeftStart() > first.getLeftEnd() || first.getRightStart() > first.getRightEnd()) initial = Math.max(initial, rightStart); else if (rightStart > 0) initial = Math.min(initial, rightStart);
I've got to go out now, I will try to have a look at it later. ..Steve
Hi Steve, thanks, problem occurs when one side has NONE and the other hasn't. I think the test should not produce values which the normal program never does (NONE with -1 for start + end). Or do you find such data in Garmin maps? In that case meaby it has a special meaning? Gerd
Date: Tue, 21 Apr 2015 10:24:47 +0100 From: steve@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] error in NumberPreparer?
Hi Gerd
it seems that NumberPreparer (in trunk) doesn't completely ignore the start/end values when numberStyle == NONE.
I was just going to post that the patch failed with NumberRangeTest, wheras trunk passes. It seems you may have found the answer but I don't think this code should be reached when both styles are NONE since it should have exited at numbers.isEmpty() -- at least in the original code.
See line 116: if (first.getLeftStart() > first.getLeftEnd() || first.getRightStart() > first.getRightEnd()) initial = Math.max(initial, rightStart); else if (rightStart > 0) initial = Math.min(initial, rightStart);
I've got to go out now, I will try to have a look at it later.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd The -1 is used by convention in the Polish format. It doesn't have any meaning to the img format itself. On 21 April 2015 10:36:32 GMT+01:00, Gerd Petermann <gpetermann_muenchen@hotmail.com> wrote:
Hi Steve,
thanks, problem occurs when one side has NONE and the other hasn't. I think the test should not produce values which the normal program never does (NONE with -1 for start + end). Or do you find such data in Garmin maps? In that case meaby it has a special meaning?
Gerd
Date: Tue, 21 Apr 2015 10:24:47 +0100 From: steve@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] error in NumberPreparer?
Hi Gerd
it seems that NumberPreparer (in trunk) doesn't completely ignore the start/end values when numberStyle == NONE.
I was just going to post that the patch failed with NumberRangeTest, wheras trunk passes. It seems you may have found the answer but I don't think this code should be reached when both styles are NONE since it should have exited at numbers.isEmpty() -- at least in the original code.
See line 116: if (first.getLeftStart() > first.getLeftEnd() || first.getRightStart() > first.getRightEnd()) initial = Math.max(initial, rightStart); else if (rightStart > 0) initial = Math.min(initial, rightStart);
I've got to go out now, I will try to have a look at it later.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Steve, I was surprised to see that these values are written. I've assumed that NONE means something like "don't try to read start and end" to safe some bits, but it seems the values are written (and read) and because of our tests we want to (have to) be able to distinguish between N,0,0 and N,-1,-1 . Well, I can change the patch so that a null pointer means "N,0,0" so that we don't have to waste memory for that default. I did not yet try to find out if there is a best value regarding the number of bits. Gerd From: steve@parabola.me.uk Date: Tue, 21 Apr 2015 11:04:04 +0100 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] error in NumberPreparer? Hi Gerd The -1 is used by convention in the Polish format. It doesn't have any meaning to the img format itself. On 21 April 2015 10:36:32 GMT+01:00, Gerd Petermann <gpetermann_muenchen@hotmail.com> wrote: Hi Steve, thanks, problem occurs when one side has NONE and the other hasn't. I think the test should not produce values which the normal program never does (NONE with -1 for start + end). Or do you find such data in Garmin maps? In that case meaby it has a special meaning? Gerd
Date: Tue, 21 Apr 2015 10:24:47 +0100 From: steve@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] error in NumberPreparer?
Hi Gerd
it seems that NumberPreparer (in trunk) doesn't completely ignore the start/end values when numberStyle == NONE.
I was just going to post that the patch failed with NumberRangeTest, wheras trunk passes. It seems you may have found the answer but I don't think this code should be reached when both styles are N ONE since it should have exited at numbers.isEmpty() -- at least in the original code.
See line 116: if (first.getLeftStart() > first.getLeftEnd() || first.getRightStart() > first.getRightEnd()) initial = Math.max(initial, rightStart); else if (rightStart > 0) initial = Math.min(initial, rightStart);
I've got to go out now, I will try to have a look at it later.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd
I was surprised to see that these values are written. I've assumed that NONE means something like "don't try to read start and end" to safe some bits,
It doesn't always take more bits to represent both sides of the road. For example if the numbers are 4-10 and 5-11 and these numbers follow from the previous segment, you can just use the one number to add 6 to both sides. ..Steve
Hi Gerd
In normal processing, the fields are 0 when style is NONE, but NumberRangeTest.java sets them to -1 and this really produces different bit streams in some cases, e.g. when iter == 306 the following test case is generated: [0,O,9,7,O,7,5, 1,B,8,2,O,3,5, 2,O,1,1,N,-1,-1]
I had time to look into this. The ones that go wrong are where there is 'O' on the left beginning with 1, and 'N' on the right. As in your example above. It turns out that using -1 as the default value of getRightStart() is required or else the value of zero must be treated specially in equalizeBases() by adding 'if (right.targetStart == 0) return false;' ..Steve
Hi Steve, I think that means that the current code is not correct. HousenumberGenerator may create Numbers with O,1,x,N,0,0 When I change Numbers to set default -1 for the start and end values the resulting img file changes and NetDisplay followed by grep Numbers shows different numbers, e.g. | | | Numbers 43,O,1,1,N,-1,-1 | | | Numbers 44,N,-1,-1,E,36,36 instead of the trunk result: | | | Numbers 43,O,-31,-31,N,-1,-1 | | | Numbers 44,N,-1,-1,E,6,4 Besides that the img file with defaults -1 is a bit smaller, so I think we should change that in trunk (with the attached patch) Gerd
Date: Wed, 22 Apr 2015 00:06:56 +0100 From: steve@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] error in NumberPreparer?
Hi Gerd
In normal processing, the fields are 0 when style is NONE, but NumberRangeTest.java sets them to -1 and this really produces different bit streams in some cases, e.g. when iter == 306 the following test case is generated: [0,O,9,7,O,7,5, 1,B,8,2,O,3,5, 2,O,1,1,N,-1,-1]
I had time to look into this. The ones that go wrong are where there is 'O' on the left beginning with 1, and 'N' on the right. As in your example above.
It turns out that using -1 as the default value of getRightStart() is required or else the value of zero must be treated specially in equalizeBases() by adding 'if (right.targetStart == 0) return false;'
..Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 22/04/15 08:11, Gerd Petermann wrote:
Besides that the img file with defaults -1 is a bit smaller, so I think we should change that in trunk (with the attached patch)
OK that would be safer. I guess that no test showed up the problem because both the Polish format and the tests make everything initialized with -1, whereas I guess that the HousenumberGenerator did not. I think I will add a check to NetCheck for negative or zero house numbers when read in, since they cannot be correct. I would also like to add the following patch to the number preparer to prevent any invalid number being used as a target in the equalizeBases() method. ..Steve
Hi Steve, yes, problem is that HousenumberGenerator only sets style to NONE when no numbers are found for a part of the road. Reg. your patch: fine for me as don't yet understand that part of the img file structure ;-) Gerd Date: Wed, 22 Apr 2015 10:55:36 +0100 From: steve@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] error in NumberPreparer? On 22/04/15 08:11, Gerd Petermann wrote:
Besides that the img file with defaults -1 is a bit smaller, so I think we should change that in trunk (with the attached patch)
OK that would be safer. I guess that no test showed up the problem because both the Polish format and the tests make everything initialized with -1, whereas I guess that the HousenumberGenerator did not. I think I will add a check to NetCheck for negative or zero house numbers when read in, since they cannot be correct. I would also like to add the following patch to the number preparer to prevent any invalid number being used as a target in the equalizeBases() method. ..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (2)
-
Gerd Petermann -
Steve Ratcliffe