[Tilesathome] Frustrated about oceantiles

[Dirk-Lüder Kreie]

Andre Hinrichs schrieb:

> I'm working on the oceantiles for three weeks now changing over 2200 tile 
> definitions and am getting more and more frustrated. The decision about 
> whether a tile is sea/land/mixed is sometimes very hard and often vague. I've 
> seen cases where the coastline is about 0.5 meters away or within a tile. So 
> the next time somebody is moving a single node there may harm the tile 
> rendering.

Thanks for your effort on fixing oceantiles.
I hope you know the wiki article about How Oceantiles Work[1]?

> I've also seen cases where the rendering of a tile depends on the state of a 
> neighbor tile. Very strange!

That's necessary due to close-areas.pl currently not being able to
discern the direction of a closed polygon. So it has to look into
neighboring tile definitions to discern wether the closed coastline is
an island (most of the time) or a small lake (seldom, deprecated).

> And the situation at the pole areas is even more frustrating. I assume, that 
> there are still thousands of tiles to be fixed especially in Canada and 
> Russia. But also in Indonesia is still a lot of work to do.
> 
> I was thinking a lot about this and already dreamed of it... I cannot see the 
> necessarity for a 'mixed' state. The oceantiles.dat should give the server 
> the possibility to serve a colored image where no tile information is present 
> and the renderer should only upload an empty tile if it really cannot decide 
> whether there is land or sea. The renderer should only take the state of the 
> tile as background color if there is no coastline or water or land in the 
> rendered OSM data. Wherever the renderer is able to decide this on basis of 
> the OSM data it should do so where the oceantiles.dat is not necessary for, 
> is it? If there is a coastline or water or land, then the renderer should 
> now, where there is land and where sea. That would make the definition of the 
> oceantiles much more easy and flexible. The tile could be defined as 'sea' 
> even if there is a node of the coastline whithin that tile. And the movement 
> of a coastline by a few meters due to a storm or a tsunami would not force 
> the oceantiles.dat to be changed.
>
> The download of a bigger area by the renderer would also no longer be 
> necessary, I think. Only probably slightly bigger for bezier curves where no 
> node of that line is whithin the rendered tile. This would reduce the load of 
> the OSM servers.
> 
> Furthermore, it would probably be useful if there are more states for the 
> oceantiles.dat in case of big areas of wood (national park, rain forrests, 
> etc.) and other areas I currently don't think of...

There is also a small bug in close-areas.pl that will trigger on very
coarse coastlines where it will not properly detect which polygon is
enclosing which. I haven't had time to look at it more closely, and
AFAIK neither has Frederik, the original author.

You are very welcome to find a method that's better than the current
oceantiles.dat, but be aware, that not only the t at h client (and server)
use it, but others as well.

[1] http://wiki.openstreetmap.org/wiki/Tiles%40home/How_Oceantiles_work
-- 

Dirk-Lüder "Deelkar" Kreie
Bremen - 53.0952°N 8.8652°E

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20081215/44b2e8d4/attachment.pgp>