logo separator

[mkgmap-dev] Fwd: Re: [PATCH] Again NullPointerException

From Thorsten Kukuk kukuk at suse.de on Fri Feb 17 22:45:53 GMT 2012 

On Fri, Feb 17, GerdP wrote:

> Hi WanMil,
> 
> I did not see the problem with trunk, but I think Thorsten did.

Yes, with the full planet file as input I saw this.

  Thorsten

> It is more likely to happen in my new code, because boundaries are
> into many more small areas. I use the splitToAreas() routine to eliminate 
> such unusable areas.
> 
> Today I've finished coding the new BoundaryMerger, so I think I can send a
> new patch
> tomorrow if the tests look good.
> 
> Gerd
> 
> 
> WanMil wrote
> > 
> > Ok, one area - two polygons.
> > 
> >  > 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.
> > 
> > The next polygon can only be an inner polygon if it lies completely 
> > within the outer polygon. In your example both polygons are distinct so 
> > the potential inner polygon does not lie within the outer polygon.
> > This is the main problem that must be analysed.
> > 
> > I am quite sure that one part of this problem is, that the boundary 
> > precompilation in the trunk cuts only horizontal or vertical (cut into 
> > the boundary raster). Your new code also cuts by polygons and the old 
> > code isn't prepared for that. So you got the right solution for that: 
> > keep the float precision for boundaries using your new method.
> > 
> > I think the trunk is not affected or can you give an example for the
> > trunk?
> > 
> > WanMil
> > 
> >> Hi WanMil,
> >>
> >> I am not sure what you mean. The example creates one area, not two.
> >> It is the result of an intersection.
> >>
> >> Gerd
> >>
> >>
> >>  > Date: Fri, 17 Feb 2012 22:29:29 +0100
> >>  > From: wmgcnfg@
> >>  > To: mkgmap-dev at .org
> >>  > Subject: [mkgmap-dev] Fwd: Re: [PATCH] Again NullPointerException
> >>  >
> >>  > It seems that my message was lost so resending it again...
> >>  > WanMil
> >>  >
> >>  > -------- Original-Nachricht --------
> >>  > Betreff: Re: [mkgmap-dev] [PATCH] Again NullPointerException
> >>  > Datum: Fri, 17 Feb 2012 21:36:35 +0100
> >>  > Von: WanMil <wmgcnfg@>
> >>  > An: Development list for mkgmap <mkgmap-dev at .org>
> >>  >
> >>  > 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 .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/Fwd-Re-PATCH-Again-NullPointerException-tp5494099p5494196.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
-- 
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)

More information about the mkgmap-dev mailing list