Andre Hinrichs <[email protected]> writes: > Hi List! > > I've discovered some rendering issues. I believe that all of them are > programming issues and can't be solved by editing the xml rules. > > issue 1) > Tiles with a coastline are sometimes rendered wrong. In many cases the > coastline crosses the neighbor tile without having a node in that tile. > Sometimes the tile itself has no node of the coastline. This of course > can be solved by adding the node but I think that this should not be > necessary. > Excamples: > http://tah.openstreetmap.org/Browse/tile/12/570/924 > http://tah.openstreetmap.org/Browse/tile/12/848/956 > > issue 2) > Water multipolygons are often (always?) rendered wrong if one part of > that polygon is a coastline. > Excample: > http://www.informationfreeway.org/?lat=-30.239925620466867&lon=-51.195482209584156&zoom=10&layers=BF00F0 > > issue 3) > In very rare cases the coastline renders wrong even though everything > seems to be right (no issue 1 or issue 2 and direction of all coastlines > is OK). I couldn't find out what's wrong there. An expert has to do > this... > Excample: > http://www.informationfreeway.org/?lat=31.466007581625224&lon=130.5543945011717&zoom=12&layers=BF00F0 > > issue 4) > Multipolygons with natural=glacier are not rendered. > A simple area with natural=glacier is OK but e.g. tiles in Greenland > fail (are empty).
I believe all these issues have to do with the way TAH works. The rendering client does not get to see the whole planet but a small tile (with a safety margin). If not all the data for a feature are in that tile the client cannot render it correctly. This has two effects: - if a feature does not have a node on the tile (including safety margin) it won't be rendered. This goes for tiles that are completely within a (multi)polygon and for features where the nodes are too far apart. - if a member way of a multipolygon is completely outside the tile it won't be included in the data and the client does not get to see it. Then the client cannot even decide which side of the line is inside the feature. Currently, it simply connects the open ends. The first problem cannot be solved by the client. One could only increase the safety margin to catch a few more corner cases. The second could be solved by the client with downloading incomplete multipolygons. Ideally, these things should be fixed at the server side. If the server (mostly TRAPI, I guess) delivers all the data that is relevant for a tile the client can render it. Matthias _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
