[mkgmap-dev] Question reg. BoundaryUtil

Sat Jan 21 19:42:36 GMT 2012

>> 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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1.gpx
Url: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20120121/26c9ef12/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 2.gpx
Url: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20120121/26c9ef12/attachment-0001.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 3.gpx
Url: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20120121/26c9ef12/attachment-0002.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 4.gpx
Url: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20120121/26c9ef12/attachment-0003.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0.gpx
Url: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20120121/26c9ef12/attachment-0004.pl 