Hi Thorsten, I think something must be wrong. I would not expect a change in file sizes and I did not see one in my test data. The patch verify_boundary_v3.patch doesn't remove any data, so I assume that you have applied one of the older patches. Can you please verify that ? The correct patch contains a line with Collections.reverse(coords); Gerd

Date: Sat, 11 Feb 2012 16:49:59 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH] Again NullPointerException

Hi,

On Thu, Feb 09, GerdP wrote:

...

Hi,

as a result of previous discussions here is th new patch.

http://gis.19327.n5.nabble.com/file/n5471749/verify_boundary_v3.patch verify_boundary_v3.patch

With mkgmap-r2205, with and without this patch, I get an expecption on the planet data from 2012-02-10:

Exception in thread "main" java.lang.AssertionError at uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryUtil.loadBoundaryFile(BoundaryUtil.java:145)

If I disable the assert, mkgmap-r2205 finishes building boundarys without problems.

There is only one big difference in the boundary data: The boundary data created by mkgmap with this patch is 15% smaller than the one created without this patch.

I don't know how to compare best which data is missing, but I think 15% is a lot. Or is this expected?

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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Thorsten, I still don't understand. If you enable assertions and you hit one, the program stops and you will have incomplete data. It makes no sense to use that data or compare sizes. If you disable assertions, the program should finish (both r2205 and the patched version) and I don't expect different file sizes. I don't understand yet how you can run into the assertion with my patch applied If your input file is not too big, I like to try it. Ciao, Gerd

Date: Sat, 11 Feb 2012 17:54:47 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH] Again NullPointerException

On Sat, Feb 11, Gerd Petermann wrote:

...

Hi Thorsten,

I think something must be wrong. I would not expect a change in file sizes and I did not see one in my test data. The patch verify_boundary_v3.patch doesn't remove any data, so I assume that you have applied one of the older patches. Can you please verify that ? The correct patch contains a line with Collections.reverse(coords);

Yes, I only applied the correct patch.

The only difference between your tests and my I see is, that I run into this assert check. Maybe that makes the difference?

Thorsten

...

Gerd

...

Date: Sat, 11 Feb 2012 16:49:59 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH] Again NullPointerException

Hi,

On Thu, Feb 09, GerdP wrote:

...

Hi,

as a result of previous discussions here is th new patch.

http://gis.19327.n5.nabble.com/file/n5471749/verify_boundary_v3.patch verify_boundary_v3.patch

With mkgmap-r2205, with and without this patch, I get an expecption on the planet data from 2012-02-10:

Exception in thread "main" java.lang.AssertionError at uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryUtil.loadBoundaryFile(BoundaryUtil.java:145)

If I disable the assert, mkgmap-r2205 finishes building boundarys without problems.

There is only one big difference in the boundary data: The boundary data created by mkgmap with this patch is 15% smaller than the one created without this patch.

I don't know how to compare best which data is missing, but I think 15% is a lot. Or is this expected?

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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ 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) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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. Sorry ! Gerd

Date: Sat, 11 Feb 2012 18:38:48 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH] Again NullPointerException

On Sat, Feb 11, Gerd Petermann wrote:

...

Hi Thorsten,

I still don't understand. If you enable assertions and you hit one, the program stops and you will have incomplete data. It makes no sense to use that data or compare sizes.

Correct, and I didn't compared that.

...

If you disable assertions, the program should finish (both r2205 and the patched version) and I don't expect different file sizes. I don't understand yet how you can run into the assertion with my patch applied If your input file is not too big, I like to try it.

As written: it's the planet file from yesterday.

Thorsten

...

...

Date: Sat, 11 Feb 2012 17:54:47 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH] Again NullPointerException

On Sat, Feb 11, Gerd Petermann wrote:

...

Hi Thorsten,

I think something must be wrong. I would not expect a change in file sizes and I did not see one in my test data. The patch verify_boundary_v3.patch doesn't remove any data, so I assume that you have applied one of the older patches. Can you please verify that ? The correct patch contains a line with Collections.reverse(coords);

Yes, I only applied the correct patch.

The only difference between your tests and my I see is, that I run into this assert check. Maybe that makes the difference?

Thorsten

...

Gerd

...

Date: Sat, 11 Feb 2012 16:49:59 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH] Again NullPointerException

Hi,

On Thu, Feb 09, GerdP wrote:

...

Hi,

as a result of previous discussions here is th new patch.

http://gis.19327.n5.nabble.com/file/n5471749/verify_boundary_v3.patch verify_boundary_v3.patch

With mkgmap-r2205, with and without this patch, I get an expecption on the planet data from 2012-02-10:

Exception in thread "main" java.lang.AssertionError at uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryUtil.loadBoundaryFile(BoundaryUtil.java:145)

If I disable the assert, mkgmap-r2205 finishes building boundarys without problems.

There is only one big difference in the boundary data: The boundary data created by mkgmap with this patch is 15% smaller than the one created without this patch.

I don't know how to compare best which data is missing, but I think 15% is a lot. Or is this expected?

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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ 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) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ 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) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Thorsten, can you check the differences between patched and unpatched version? There is a tool which compares two boundary directories and saves the differences as GPX files. It is called: java -cp mkgmap.jar uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryDiff <dir1> <dir2> It creates a subdirectory named gpx with the differences. That should give a quick answer what happened. Thanks! WanMil

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

Hi Thorsten, If I got that right, you should have the files either in subdir removed, the program considers the 2nd dir in the parameter list to be the newer one: java -cp mkgmap.jar uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryDiff <dir1> <dir2> The four gpx files describe the areas that are covered (I prefer JOSM to look at them, but many orher tools are available), the _o at the end of the file name means that the area is an outer area (_i would mean a hole within an other area) Does that help? Gerd

Date: Sun, 12 Feb 2012 23:26:36 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH] Again NullPointerException

Hi,

On Sun, Feb 12, WanMil wrote:

...

Thorsten,

can you check the differences between patched and unpatched version?

There is a tool which compares two boundary directories and saves the differences as GPX files.

It is called: java -cp mkgmap.jar uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryDiff <dir1> <dir2>

It creates a subdirectory named gpx with the differences. That should give a quick answer what happened.

Ok, I did that, but don't know how to interpret them. I have directories with files 0_o.gpx up to 3_o.gpx, which all contains a trkseg with 4 trkpt.

...

Thanks! WanMil

...

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

_______________________________________________ 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) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Thorsten, it is very unlikely that you find a significant change. The error did only occur for extremly small or narrow areas where the rounding error,

Date: Mon, 13 Feb 2012 12:04:15 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH] Again NullPointerException

Hi Gerd,

On Mon, Feb 13, Gerd Petermann wrote:

...

Hi Thorsten,

If I got that right, you should have the files either in subdir removed, the program considers the 2nd dir in the parameter list to be the newer one:

Ok, which means for DACH I have new entries.

...

Does that help?

Yes, thanks!

So for DACH, the difference are some small areas, where the boundary is nearly touching itself. This areas are now added with your patch, but not relevant at all, there is nothing.

Next I will compare the planet file, which data is missing there.

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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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.

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? Gerd

Date: Sun, 12 Feb 2012 21:44:24 +0100 From: wmgcnfg@web.de To: mkgmap-dev@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@.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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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@web.de To: mkgmap-dev@lists.mkgmap.org.uk 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@web.de> An: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk>

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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi WanMil, I did not see the problem with trunk, but I think Thorsten did. 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.

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@.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

Am 12.02.2012 12:25, schrieb Gerd Petermann:

Hi WanMil,

...

Date: Sun, 12 Feb 2012 12:05:55 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH] Again NullPointerException

Hi Gerd,

thanks for the patch.

The verifiedAreaToShapes should replace the areaToShapes method. The only reason it should not replace is if the performance is noticeably slower.

I did not see a notble impact during my tests.

...

The clockwise check before reversing is superfluous: Way w = new Way(0, coords); if (w.clockwise() != (realAreaSize <= 0)){ Collections.reverse(coords); } outputs.add(coords);

The direction might change in both situations so it should also be checked if the direction changes from ccw to cw. Do you agree?

No. I think the code is exactly doing what you want. It reverses the order if way.clockwise() returns a wrong result, no matter if ccw or cw is correct. At least that's what I want it to do. Are you sure that it doesn't work?

Uups. You are right. I just read the code and didn't test it yet. It works as it should :-)

...

WanMil

...

Hi,

as a result of previous discussions here is th new patch.

http://gis.19327.n5.nabble.com/file/n5471749/verify_boundary_v3.patch verify_boundary_v3.patch

Changes: Verify if rounding errors change the direction of a way (clockwise/counterclockwise order), if that happens, change the order so that Way.clockwise() returns the wanted result.

The patch introduces a new method

Java2DConverter.verifiedAreaToShapes()

instead of changing the existing

Java2DConverter.areaToShapes(area)

I did this because Java2DConverter.areaToShapes(area) is called in

other

...

...

places and I wanted to avoid side effects. Maybe someone who knows the sources in PolygonSplitterBase.java and PolygonClipper.java can look at this and see if they benefit also from the verified routine?

Gerd

-- 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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi WanMil, you are right, they are obsolete. Gerd WanMil wrote

Gerd,

one more question about the patch: Are the min/max lat/lon variables used? I think they can be removed but I fear that I have overseen something important again.... ;-)?

WanMil

...

...

...

...

Hi,

as a result of previous discussions here is th new patch.

http://gis.19327.n5.nabble.com/file/n5471749/verify_boundary_v3.patch

...

verify_boundary_v3.patch

Changes: Verify if rounding errors change the direction of a way (clockwise/counterclockwise order), if that happens, change the order so that Way.clockwise() returns the wanted result.

The patch introduces a new method

Java2DConverter.verifiedAreaToShapes()

instead of changing the existing

Java2DConverter.areaToShapes(area)

I did this because Java2DConverter.areaToShapes(area) is called in other places and I wanted to avoid side effects. Maybe someone who knows the sources in PolygonSplitterBase.java and PolygonClipper.java can look at this and see if they benefit also from the verified routine?

Gerd

---

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.