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@.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@.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@.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@.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@.org > > > > >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > >> > > > > > > > > > > > > > > > -- > > > > > View this message in context: > > > > http://gis.19327.n5.nabble.com/PATCH-Again-NullPointerException-tp5471749p54... > > > > > Sent from the Mkgmap Development mailing list archive at > Nabble.com. > > > > > _______________________________________________ > > > > > mkgmap-dev mailing list > > > > > mkgmap-dev@.org > > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > _______________________________________________ > > > > mkgmap-dev mailing list > > > > mkgmap-dev@.org > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > _______________________________________________ > > > mkgmap-dev mailing list > > > mkgmap-dev@.org > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev@.org > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@.org > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n5.nabble.com/PATCH-Again-NullPointerException-tp5471749p54... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.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-tp549... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@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)