[Tilesathome] or/p island issue

[Frederik Ramm]

Hi,

    at some point in the past tiles at home switched to using or/p by 
default. Someone told me so and I said "wow, I didn't notice, they 
haven't even told me". Later someone else said that it wasn't the 
default any more and I said "hm, I wonder why, nobody spoke to me about 
that". At SOTM bobkare told me that this had been because of the island 
problem - islands were not rendered. After some gentle poking by Spaetz 
this morning (a.k.a. hitting me with a stick), I've investigated the issue.

The problem is that Osmarender is very forgiving in how it handles 
multipolygon relations; it doesn't care about the roles, just throws 
them all together into an SVG path and it mostly works.

or/p aims to be a little bit more sophisticated in this respect and 
actually looks at the inner/outer bits. Which didn't work well with 
close-areas.pl, as that piece of software did not create correct 
multipolygon relations. close-areas simply made one big "multipolygon" 
for all contiguous strings of coastline it found; even something like this

,-----,
|  O  |  O
`-----'

- a sea area with an island, and an extra pocket of water next to it - 
would have been one multipolygon with three members.

I have now changed close-areas.pl to actually analyze which costline 
polygons lie inside which, so in the above case it would emit one 
multipolygon relation with one outer and one inner member, and the extra 
way would not receive a relation.

The close-areas+or/p combo now works for my test case (the area just off 
the Oslo coast), but as always there may be some problems left; I'd 
appreciate if you could see for yourselves whether it works as intended 
now. I haven't checked whether it works for the "addBlueRectangle" case 
where you have a sole island sitting in the middle of a level12 tile, 
could somebody check that for me?

Thank you for your patience.

Bye
Frederik

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