logo separator

[mkgmap-dev] [PATCH] Again NullPointerException

From WanMil wmgcnfg at web.de on Thu Feb 16 18:53:10 GMT 2012

Hi Gerd,

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 at web.de
>  > To: mkgmap-dev at lists.mkgmap.org.uk
>  > 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 at web.de
>  > > > To: mkgmap-dev at lists.mkgmap.org.uk
>  > > > 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 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
>  > >
>  > >
>  > > _______________________________________________
>  > > 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
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




More information about the mkgmap-dev mailing list