...

Hi WanMil,

I am hitting a problem in BoundaryUtil.splitToElements()

I create a boundary object with Boundary boundary = new Boundary(nodeElem.area, nodeElem.boundary.getTags());

Now I want to verify it with List<BoundaryElement> boundaryElements = boundary.getBoundaryElements(); if (boundaryElements.size() == 0) continue;

My problem: I am hitting this assertion in BoundaryUtil.splitToElements():

assert bElements.get(0).isOuter() : log.threadTag()+" first element is not outer. "+ bElements;

The area looks like this: [Curve[0, (448156.0, 2442187.0), (448156.0, 2442187.0), D], Curve[1, (448156.0, 2442187.0), (448177.0, 2442274.0), D], Curve[1, (448177.0, 2442274.0), (448176.4834437087, 2442270.543046358), U], Curve[1, (448176.48344370874, 2442270.543046358), (448156.1621621622, 2442187.0), U]]

Can you tell me what's wrong with that? The area is split into one list of coords, and that describes a way that is considered to be anti-clockwise: [2442187/448156, 2442274/448177, 2442271/448176, 2442187/448156]

I am not sure where I should search the error.

Ciao, Gerd

Hi Gerd,

it is possible that a boundary has a hole created by an inner way in a multipolygon. The List<List<Coord>> areaElements = Java2DConverter.areaToShapes(area); call converts the area into distinct polygons where clockwise polygons describe outer ways and counterclockwise polygons describe inner way (holes). As it is mentioned in the comment the areaElements list starts with the most inner polygon and continues with more and more outer polygons. Therefore the last polygon is the most outer polygon (and also the biggest one). As the biggest polygon cannot be an inner polygon it must be an outer one. This is the check.

I haven't played through your testcase but either the Java2DConverter has a bug, or the code if (singleElement.size()<= 3) { // need at least 4 items to describe a polygon continue; } removes the last outer element or the input area is defect (I don't know if that's ever possible).

WanMil

Hi Gerd, I can confirm this problem. The problem is caused by boundary relation 171139 (http://www.openstreetmap.org/browse/relation/171139). As you can see the northeast corner is very pointed. By converting the OSM coordinates to garmin coordinates with less accuracy the north east corner is converted to a line. This line (0.gpx) is stored as boundary and detected as counterclockwise. I am not still sure if the clockwise algorithm is wrong but anyhow this case should be detected and should not lead to an Exception. Attached you find the relation and how it is stored in the bounds file. Each part is stored as one gpx file. WanMil

Hi WanMil, thanks for the investigation. I do not understand why the direction is important until now, but I think a method that removes such useless shapes from a given area would be good to have. Gerd WanMil wrote

...

...

Hi WanMil,

I am hitting a problem in BoundaryUtil.splitToElements()

I create a boundary object with Boundary boundary = new Boundary(nodeElem.area, nodeElem.boundary.getTags());

Now I want to verify it with List<BoundaryElement> boundaryElements = boundary.getBoundaryElements(); if (boundaryElements.size() == 0) continue;

My problem: I am hitting this assertion in BoundaryUtil.splitToElements():

assert bElements.get(0).isOuter() : log.threadTag()+" first element is not outer. "+ bElements;

The area looks like this: [Curve[0, (448156.0, 2442187.0), (448156.0, 2442187.0), D], Curve[1, (448156.0, 2442187.0), (448177.0, 2442274.0), D], Curve[1, (448177.0, 2442274.0), (448176.4834437087, 2442270.543046358), U], Curve[1, (448176.48344370874, 2442270.543046358), (448156.1621621622, 2442187.0), U]]

Can you tell me what's wrong with that? The area is split into one list of coords, and that describes a way that is considered to be anti-clockwise: [2442187/448156, 2442274/448177, 2442271/448176, 2442187/448156]

I am not sure where I should search the error.

Ciao, Gerd

Hi Gerd,

it is possible that a boundary has a hole created by an inner way in a multipolygon. The List<List<Coord>> areaElements = Java2DConverter.areaToShapes(area); call converts the area into distinct polygons where clockwise polygons describe outer ways and counterclockwise polygons describe inner way (holes). As it is mentioned in the comment the areaElements list starts with the most inner polygon and continues with more and more outer polygons. Therefore the last polygon is the most outer polygon (and also the biggest one). As the biggest polygon cannot be an inner polygon it must be an outer one. This is the check.

I haven't played through your testcase but either the Java2DConverter has a bug, or the code if (singleElement.size()<= 3) { // need at least 4 items to describe a polygon continue; } removes the last outer element or the input area is defect (I don't know if that's ever possible).

WanMil

Hi Gerd,

I can confirm this problem. The problem is caused by boundary relation 171139 (http://www.openstreetmap.org/browse/relation/171139). As you can see the northeast corner is very pointed. By converting the OSM coordinates to garmin coordinates with less accuracy the north east corner is converted to a line. This line (0.gpx) is stored as boundary and detected as counterclockwise. I am not still sure if the clockwise algorithm is wrong but anyhow this case should be detected and should not lead to an Exception.

Attached you find the relation and how it is stored in the bounds file. Each part is stored as one gpx file.

WanMil

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

-- View this message in context: http://gis.638310.n2.nabble.com/Question-reg-BoundaryUtil-tp7208126p7211773.... Sent from the Mkgmap Development mailing list archive at Nabble.com.