[mkgmap-dev] Fwd: Re: [PATCH] Again NullPointerException
From Thorsten Kukuk kukuk at suse.de on Sat Feb 18 18:58:28 GMT 2012
Hi, On Sat, Feb 18, WanMil wrote: > So you see it with the latest trunk release, correct? Yes, I still see it with r2207. > Apart from that I really have problems to construct a case where that > should happen. Maybe I am very blind but I haven't found one yet. So > please enlighten me with a real example using the latest trunk release. How can I find out what the problem creates? I don't see anything relevant in the logs or in the backtrace. Thorsten > Thanks > WanMil > > > 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 > > _______________________________________________ > 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)
- Previous message: [mkgmap-dev] Fwd: Re: [PATCH] Again NullPointerException
- Next message: [mkgmap-dev] Commit: r2209: Do not throw away polygons that potentially cover the complete bounding box.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list