[OSM-talk] area_with_holes as alternative to multipolygon relation

Igor Brejc igor.brejc at gmail.com
Mon Mar 3 18:12:24 GMT 2008


Robert Vollmert wrote:
> Hello,
>
> On Mar 3, 2008, at 18:03, Frederik Ramm wrote:
>   
>> Until now I was unaware that we currently require the outer/inner ways
>> of polygons to be clockwise/anticlockwise. It seems that some
>> renderers work better if that is the case but nowhere is it a
>> requirement.
>>     
>
>   
 From my experience in developing the multipolygon rendering for Kosmos:

1. I think there is a kind of a requirement in Wiki: "Create the outer 
and inner rings each as a single way. The outer ring should be drawn 
clockwise, the inner ring(s) anticlockwise.".
2. Certain multipolygons were created without explicitly definining 
roles, so the clockwise/anticlockwise mechanism is the only (efficient) 
way for a renderer to distinguish them.
3. Rendering engines typically use clockwise+anticlockwise orientation 
to draw polygons with holes. So if your proposal was accepted, that 
would probably mean additional processing for renderers in reversing the 
order of nodes for inner ways. Okey, this is not a major concern for 
most OSM users, but I think it should be kept in mind anyway.
> And tagging multipolygons as in my proposal (i.e., tag  
> the hole as a separate area) didn't seem to work well with either  
> mapnik or osmarender. From what I remember of reading the code, both  
> renderers skip areas with role=inner when rendering.
>
>   
I'm not sure that's true, but I guess Mapnik/Osmarender guys should 
answer this.
>>> In particular, with the proposed
>>> relation, it's not necessary to create duplicate ways (clockwise and
>>> anti-clockwise) for holes with properties.
>>>       
>> Who said this was necessary today?
>>
>>     
>
> The wiki. And I've seen other people tag like that. I'll update the  
> wiki later if nobody objects, and see what I can do about the renderers.
>
>
>   
I think the existing system is OK. Besides, "holes" are actually 
rendered like holes - the pixels inside holes are not touched when 
rendering the multipolygon (at least not in Kosmos). So the hole should 
not be treated like an inner polygon to be filled with some other color. 
What if you had a lake island with one half of it covered with forest, 
and the other half being a residential area?

Basically when you specify a lake with a multipolygon, you specify its 
(and only its) extents, which exclude the holes. What is outside of its 
extents is not a concern of a lake multipolygon.

Cheers,
Igor


-- 
http://igorbrejc.net





More information about the talk mailing list