[OSM-dev] Coastlines and water - contact and technical

Jon Burgess jburgess777 at googlemail.com
Sun Jul 19 21:01:25 BST 2009


On Sun, 2009-07-19 at 15:29 -0400, Ben Supnik wrote:
> Hi Jon,
> 
> Jon Burgess wrote:
> 
> > This is one of the things which has to be done but is not really
> > documented. The algorithm osm2pgsql uses is to gather together all the
> > tags which are related to the polygon feature (e.g. landuse=, natural=
> > etc) and then compare those against the outer ways. If the way and
> > polygon match then it will exclude the way. If they do not match then
> > the way will be included.
> 
> Ah right - otherwise the outer way will form a no-holes polygon, which 
> is probably wrong..and if the holes don't have their own map rendering 
> representation, the fill might show through.
> 
> (Not to mention the interpretation would be wrong. :-)
> 
> > In particular, there is some legacy data which has no tags on the
> > relation but identical tags on both the outer and inner ways . In this
> > case, the polygon needs to be rendered with the appropriate tags but
> > neither the inner nor outer ways are rendered.
> 
> Oy...that data strikes me as really broken. :-(

This is how the data appeared when the existing polygons with holes were
run through the 0.4->0.5 conversion process. In 0.4 they consisted of a
single tagged way with disjoint segments. In the conversion, the
disjoint segments turned into multiple tagged ways and a relation was
created with them all as members. The conversion process was not
intelligent enough to assign them roles.

> In particular, defining anything as having "same" or "different" tags 
> strikes me as perilous because tags are sets of values...if one of a 
> relation's ways has had additional data tagged onto it, is it now 
> "different"? :-)

Yes, at best it is a best-guess as to what the mapper intended and can
get caught out. If we were designing things with a clean sheet of paper
then we would probably disallow many of these things. We might also have
re-introduced a distinct area or polygon type (these did exist in a very
early version of the API by were not used & got removed).

> (For example, someone tags the boundary of an island as a walking 
> path...the island boundary is tagged as lake because it's the hole in 
> the lake and someone wanted to tag everything...are we now different? 
> Is the island now wet? :-)

It might do something like that. The advice would probably be to remove
the redundant lake tag. I am afraid there will always be some edge cases
which we mis-handle, but these can normally be fixed by making minor
improvements to the tags. 

Things get especially tricky when you think how we have to handle
incremental updates to any of the members of the relations following the
diff stream.

	Jon








More information about the dev mailing list