[Tilesathome] Extended Multipolygon support

[Frederik Ramm]

Hi,

Frederik Ramm wrote:
> I'll look at it now.

Ok, I have some coding style issues ;-)

This:

while (my ($key, $val) = each(%{@$inputways[$index]->{'tags'}}))
{
    $tags->{$key}=$val;
}

looks like PHP!!!eleven!!!

(And I've seldom seen @$x[$y] favoured over $x->[$y].)


You chose to introduce a new object type that you bless as 
"multipolygon", but then there are a lot of places where you have to do 
things like

     next if defined($e) and ref($_) ne $e and not ($e eq 'way' and 
ref($_) eq 'multipolygon');

- would it perhaps have been easier to bless the multipolygons as ways 
and, where required, use an extra hash element to distinguish 
multipolygons from ways?

In fact, should we perhaps have the vision to change our rule files from 
distinguishing only between "node" and "way" to distinguish between 
"node", "way", and "area", and then bless closed ways and multipolygons 
as areas and normal ways as ways? But that is probably looking a bit too 
far ahead and would cause a lot of changes in the XSLT as well. (I fully 
expect a native area data type in 0.8 or 0.9... but don't tell anybody 
just yet.)

All in all I think this is a clever patch that should be applied. Maybe 
there's the odd quirk that I overlooked but I'm sure it will straighten 
itself out!

It has been suggested on the multipolygon page in the Wiki that when you 
have two or more touching inner or outer rings, they should be treated 
as one ring that only includes those edges that are not shared. This is 
for the benefit of backwards compatibility with today's workarounds 
where people draw two "C" shaped areas of wood around a landing. I'm not 
very fond of this concept but maybe it could be implemented. Not 
something that has any priority though.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"