[mkgmap-dev] Question reg. BoundaryUtil

Sat Jan 21 20:19:57 GMT 2012

Am 21.01.2012 20:42, schrieb WanMil:
>>> 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
>

That problem is fixed with r2179. Bounds have to be reprepared.
Thanks for reporting!

WanMil