rendering issues

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

rendering issues

Andre Hinrichs
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).

issue 5)
noexit bars are sometimes angular.
Excample:
http://www.informationfreeway.org/?lat=52.21877205969673&lon=10.63794088678232&zoom=17&layers=BF00F0

issue 6)
i forgot... I will send it later...


Regards
Andre



_______________________________________________
Tilesathome mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tilesathome
Reply | Threaded
Open this post in threaded view
|

Re: rendering issues

Matthias Julius
Andre Hinrichs <[hidden email]> 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
[hidden email]
http://lists.openstreetmap.org/listinfo/tilesathome