IMO, relations are the way to go. It can handle every situation including holes (exclaves/enclaves), multiple names, multiple administrative levels on same border. The only question remaining if you should add the coastlines to it. Also since the import of the Italian data and the reimport of AND boundaries in NL, there are now 10297 boundary relations according to <a href="http://tagwatch.stoecker.eu/Europe/En/top_undocumented_relations.html">http://tagwatch.stoecker.eu/Europe/En/top_undocumented_relations.html</a>.<br>
<br><a href="http://wiki.openstreetmap.org/index.php/Relations/Proposed/Boundaries">http://wiki.openstreetmap.org/index.php/Relations/Proposed/Boundaries</a><br><br><div class="gmail_quote">On Thu, Oct 30, 2008 at 11:11 PM, Roland Olbricht <span dir="ltr"><<a href="mailto:roland.olbricht@gmx.de">roland.olbricht@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hello everybody,<br>
<br>
the boundary in OSM is maybe suboptimal structured. What is the best option?<br>
<br>
1) Leave the data as it is and use precautions in the software using it<br>
2) Silently correct the data by running an appropriate script<br>
3) Discuss somewhere (where?) what the script should correct and what not<br>
4) Encourage somehow (how?) the mapper community to correct it manually<br>
<br>
In detail, there are<br>
a) the "left:country" and "right:country" attributes in the boundary ways.<br>
b) the nodes with tag k="place" v="country" which contain more information on<br>
a country.<br>
<br>
The information in a) is only partially present, it is sensitive to typos or<br>
name variants of countries (e.g. "Belgium", "Belgique" or "Congo", "DR<br>
Congo"), it is redundant, sometimes it is simply inaccurate (e.g. if a way<br>
passes a point where three countries meet, there is no way to note the change<br>
of the country on one side) and it does provide no chance for additional<br>
information, e.g. the names of a country in different languages.<br>
<br>
But nonetheless, it is currently used by tiles@home for giving the borders<br>
names. So silently stripping of the tag might affect the rendering.<br>
<br>
Storing the information in b) would leave more space for information about the<br>
country (currently used for example for the name of the country in different<br>
languages) but it has almost no connection to the boundary itself an it<br>
doesn't provide any information about exclaves of the country.<br>
<br>
A possible solution would be to have instead of b) a relation which contains<br>
all the tags of b) and as members all ways that constitute the border of that<br>
country. A good example would be relation 47796 for the Netherlands.<br>
<br>
Cheers,<br>
Roland<br>
<br>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/dev" target="_blank">http://lists.openstreetmap.org/listinfo/dev</a><br>
</blockquote></div><br>