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...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
