[mkgmap-dev] Fwd: Re: [PATCH] Again NullPointerException
From WanMil wmgcnfg at web.de on Sat Feb 18 12:55:01 GMT 2012
So you see it with the latest trunk release, correct? 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. 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
- Previous message: [mkgmap-dev] Fwd: Re: [PATCH] Again NullPointerException
- Next message: [mkgmap-dev] Fwd: Re: [PATCH] Again NullPointerException
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list