[mkgmap-dev] Question reg. BoundaryUtil

Sat Jan 21 20:22:35 GMT 2012

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&lt;List&lt;Coord&gt;>  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 at .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.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.