Am 12.01.2013 um 02:21 schrieb Svavar Kjarrval <[email protected]>:
> What do you think?
Great news if they'd release the data for all these geographic place names.
>From a practical point of view if they'd do so tomorrow we would probably not
>be ready to import it. There is no established tagging scheme for this kind of
>objects (mostly), and in some circumstances (very big areas) we might not even
>have an adequate data model. The bigger the areas get, the less precise
>(sharp) are usually the borders (if its not a coastline or a river), often
>these areas fade one into another. So it might be better suited to have a
>separate shape file with rough area limits instead of having the same areas in
>the OSM db. Of course point data could be an alternative for osm ("somewhere
>here is a valley called foo") but obviously nodes would be rather suboptimal
>to represent huge areas. The well established tags for these type of objects
>are natural=peak and bay and place=locality in wider use, and there is a
>proposal for features in mountainous areas (ridge, mountain range, …) all the
>rest would have to be invented and established.
The main reason why this wasn't done until now is IMHO what I wrote above: our
current geometric representations are not very suited for this kind of
information. Some time ago we had a discussion about this on the German ML and
there was the idea of an additional datatype, a relation, which contained some
objects like existing ways and nodes, and thereby described a rough area
without explicitly delimiting it (you'd compute the actual area in
preprocessing by drawing a hull around the members). This kind of object would
be quite stable (if there are enough members in it), and it would weigh little
in the db. As a variant you might also have roles like in and out to have the
possibility to state that something is still or not any more part of the area.
cheers,
Martin
_______________________________________________
talk mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk
