[mkgmap-dev] [PATCH] Again NullPointerException

Fri Feb 17 20:36:35 GMT 2012

Hi Gerd,

I think something else is wrong.
Your example gives two areas which intersection is empty. That's easy to 
see if you compare the first (x) coordinate of the path. All x values of 
the first path are greater or equal to the x coordinates of the second 
path. So they are not outer and inner element.

WanMil

> Hi WanMil,
>
> attached is a sample source to reproduce the problem.
> It was created with an intersection of r1457666 and r144425 somewhere in
> java.awt.Rectangle[x=121875,y=2039062,width=1562,height=1563]
>
> http://gis.19327.n5.nabble.com/file/n5491830/BoundaryError.java.patch
> BoundaryError.java.patch
>
> Execute it with
> java -ea -classpath mkgmap.jar
> uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryError
>
> The outer element is removed because
> (122570.515625d, 2040290.25d) and (122571.0d, 2040290.0d) are equal when
> rounded to integer.
>
> Using float precision I was not able to reproduce the problem, so I used
> doubles to create the source snippet. Maybe this fact can be used as part of
> the solution. If splitToElements() returns an invalid result, we may use
> this snippet to change the area to float precision and try again:
> 		
> 		Path2D.Float path = new Path2D.Float(area);
> 		Area testArea = new Area(path);
> 		splitToElements(testArea);
>
> In the test case, the returned result seems to be ok.
>
> Gerd
>
>
> WanMil wrote
>>
>>
>> do you have a concrete example for that? I have problems to imagine how
>> that should happen.
>>
>> WanMil
>>
>>> Hi WanMil,
>>>
>>> even with the patch the assertion problem still occurs in the following
>>> situation:
>>> An area with 2 polygons, first polygon has 4 points but two of them are
>>> "equal" using the integer values.
>>> Thus, coords.size() is 3 and the first polygon is not added to outputs.
>>> If the next polygon is an inner one and is
>>> aded to outputs. Result: we hit this assertion:
>>> assert bElements.get(0).isOuter() : log.threadTag()+" first element is
>>> not outer. "+ bElements;
>>>
>>> I am not sure how to handle such cases. I think we have to remove the
>>> test for "equal" coords, instead we
>>> must add all points to coords .
>>>
>>> Do you agree?
>>>
>>> BTW: In my new *.bnd format I'll use a completely different way to save
>>> areas which avoids most of
>>> the rounding errors.
>>> The basic part looks now like this, maybe I'll change it to avoid
>>> writing the type integer for each lineto pair:
>>>
>>> ...
>>> float[] res = new float[6];
>>> PathIterator pit = area.getPathIterator(null);
>>>
>>> dos.writeInt(pit.getWindingRule());
>>> while (!pit.isDone()) {
>>> int type = pit.currentSegment(res);
>>> dos.writeInt(type);
>>> switch (type) {
>>> case PathIterator.SEG_LINETO:
>>> case PathIterator.SEG_MOVETO:
>>> dos.writeFloat(res[0]);
>>> dos.writeFloat(res[1]);
>>> break;
>>> case PathIterator.SEG_CLOSE:
>>> break;
>>> default:
>>> log.error("Unsupported path iterator type " + type
>>> + ". This is an mkgmap error.");
>>> }
>>>
>>> pit.next();
>>> }
>>> dos.writeInt(-1); // isDone flag
>>>
>>> ...
>>>
>>>
>>> public static Area readArea(DataInputStream inpStream) throws
>>> IOException{
>>> Path2D.Float path = new Path2D.Float();
>>>
>>> int windingRule = inpStream.readInt();
>>> path.setWindingRule(windingRule);
>>> int type = inpStream.readInt();
>>> while (type>= 0) {
>>> switch (type) {
>>> case PathIterator.SEG_LINETO:
>>> case PathIterator.SEG_MOVETO:
>>> float x = inpStream.readFloat();
>>> float y = inpStream.readFloat();
>>> if (type == PathIterator.SEG_LINETO)
>>> path.lineTo(x, y);
>>> else
>>> path.moveTo(x, y);
>>> break;
>>> case PathIterator.SEG_CLOSE:
>>> path.closePath();
>>> break;
>>> default:
>>> log.error("Unsupported path iterator type " + type
>>> + ". This is an mkgmap error.");
>>> }
>>>
>>> type = inpStream.readInt();
>>> }
>>> if (type != -1){
>>> log.error("Final type value != -1: " + type);
>>> }
>>> else{
>>> return new Area(path);
>>> }
>>> return null;
>>> }
>>>
>>> ciao,
>>> Gerd
>>>
>>>
>>>   >  Date: Sun, 12 Feb 2012 22:05:58 +0100
>>>   >  From: wmgcnfg@
>>>   >  To: mkgmap-dev at .org
>>>   >  Subject: Re: [mkgmap-dev] [PATCH] Again NullPointerException
>>>   >
>>>   >  Hi Gerd,
>>>   >
>>>   >  >  Hi WanMil,
>>>   >  >
>>>   >  >  thanks, and I like all your changes.
>>>   >  >  Just one small point: You kept this comment:
>>>   >  >  "The outline of the polygon is has clockwise order whereas ..."
>>>   >  >  which I wanted to change to
>>>   >  >  "The outline of the polygon has clockwise order whereas ..."
>>>   >  >
>>>   >  >  Was that intended?
>>>   >
>>>   >  No. I just removed the lines between the old areaToShapes method and
>>> the
>>>   >  new verifyXXX method so this change was removed by mistake.
>>>   >
>>>   >  WanMil
>>>   >
>>>   >  >
>>>   >  >  Gerd
>>>   >  >
>>>   >  >  >  Date: Sun, 12 Feb 2012 21:44:24 +0100
>>>   >  >  >  From: wmgcnfg@
>>>   >  >  >  To: mkgmap-dev at .org
>>>   >  >  >  Subject: Re: [mkgmap-dev] [PATCH] Again NullPointerException
>>>   >  >  >
>>>   >  >  >  Sounds reasonable.
>>>   >  >  >
>>>   >  >  >  I have comitted the patch with some small changes:
>>>   >  >  >  * Removed unused variables
>>>   >  >  >  * Added/changed some comments for (my) better understanding
>>>   >  >  >  * Reduced the depth of if clauses for better reading
>>>   >  >  >  * Removed the duplicate check for the float values. It is not
>>> necessary
>>>   >  >  >  and works only in very few cases. Interestingly there were lots
>>> of cases
>>>   >  >  >  where the printed floats were equal but the check did not remove
>>> them.
>>>   >  >  >  In the end it does not make a difference in the cw/ccw
>>> calculation. (The
>>>   >  >  >  check for the int values is still there.)
>>>   >  >  >
>>>   >  >  >  WanMil
>>>   >  >  >
>>>   >  >  >  >  Hi Thorsten,
>>>   >  >  >  >
>>>   >  >  >  >  well, I think that difference is okay. The patch itself doesn't
>>>   >  >  change the
>>>   >  >  >  >  number of bytes that are written, but it changes the meaning.
>>> The
>>>   >  >  data is
>>>   >  >  >  >  read again by the BoundaryPreparer.workoutBoundaryRelations()
>>>   >  >  >  >  method which interprets the data.
>>>   >  >  >  >  A boundary that is counterclockwise is considered to be a hole
>>> in
>>>   >  >  an outer
>>>   >  >  >  >  area.
>>>   >  >  >  >  Since the patch corrects a few missinterpretations, the
>>>   >  >  >  >  workoutBoundaryRelations() will probably produce different
>>> results
>>>   >  >  when it
>>>   >  >  >  >  tries to find areas that lie within other areas.
>>>   >  >  >  >
>>>   >  >  >  >  Gerd
>>>   >  >  >  >
>>>   >  >  >  >
>>>   >  >  >  >
>>>   >  >  >  >
>>>   >  >  >  >  Thorsten Kukuk wrote
>>>   >  >  >  >>
>>>   >  >  >  >>  Hi Gerd,
>>>   >  >  >  >>
>>>   >  >  >  >>  On Sat, Feb 11, Gerd Petermann wrote:
>>>   >  >  >  >>
>>>   >  >  >  >>>
>>>   >  >  >  >>>  Hi Thorsten,
>>>   >  >  >  >>>
>>>   >  >  >  >>>  okay, so you have to wait until someone with a big machine
>>> tries
>>>   >  >  it. I
>>>   >  >  >  >>>  may be able to download planet data, but I cannot run mkgmap
>>> on a
>>>   >  >  file
>>>   >  >  >  >>>  containing planet boundaries.
>>>   >  >  >  >>>  My machine has max. ~3GB java heap available, that was just
>>>   >  >  enough for
>>>   >  >  >  >>>  europe boundary data.
>>>   >  >  >  >>
>>>   >  >  >  >>
>>>   >  >  >  >>  I tried it now with my DACH extract. The differences are
>>>   >  >  >  >>  only small (two files) and this time the unpatched version
>>>   >  >  >  >>  is bigger than the one with your patch:
>>>   >  >  >  >>
>>>   >  >  >  >>  -bounds_2200000_400000.bnd 2294004
>>>   >  >  >  >>  +bounds_2200000_400000.bnd 2293956
>>>   >  >  >  >>  -bounds_2350000_600000.bnd 1817189
>>>   >  >  >  >>  +bounds_2350000_600000.bnd 1816893
>>>   >  >  >  >>
>>>   >  >  >  >>  All other 82 files have the same size.
>>>   >  >  >  >>
>>>   >  >  >  >>  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)
>>>   >  >  >  >>  _______________________________________________
>>>   >  >  >  >>  mkgmap-dev mailing list
>>>   >  >  >  >>  mkgmap-dev at .org
>>>   >  >  >  >>  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>   >  >  >  >>
>>>   >  >  >  >
>>>   >  >  >  >
>>>   >  >  >  >  --
>>>   >  >  >  >  View this message in context:
>>>   >  >
>>> http://gis.19327.n5.nabble.com/PATCH-Again-NullPointerException-tp5471749p5476975.html
>>>   >  >  >  >  Sent from the Mkgmap Development mailing list archive at
>>> Nabble.com.
>>>   >  >  >  >  _______________________________________________
>>>   >  >  >  >  mkgmap-dev mailing list
>>>   >  >  >  >  mkgmap-dev at .org
>>>   >  >  >  >  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>   >  >  >
>>>   >  >  >  _______________________________________________
>>>   >  >  >  mkgmap-dev mailing list
>>>   >  >  >  mkgmap-dev at .org
>>>   >  >  >  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>   >  >
>>>   >  >
>>>   >  >  _______________________________________________
>>>   >  >  mkgmap-dev mailing list
>>>   >  >  mkgmap-dev at .org
>>>   >  >  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>   >
>>>   >  _______________________________________________
>>>   >  mkgmap-dev mailing list
>>>   >  mkgmap-dev at .org
>>>   >  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>
>>>
>>> _______________________________________________
>>> mkgmap-dev mailing list
>>> mkgmap-dev at .org
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at .org
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>
>
> --
> View this message in context: http://gis.19327.n5.nabble.com/PATCH-Again-NullPointerException-tp5471749p5491830.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev