Nicola I've been promoting the idea of namespaces for some time.  When I create tags which are for my own personal use, and not have any specific meaning to anyone else then I prefix them with my user Id.   So any tags, or values starting 80n: are mine and will not have (much) meaning to anyone else.

One example.  When I tag a way with a street name, I add the filename of photo that I used as a source as image=80n:dsc01234.jpg.  Many people may have a photo with a filename of dsc01234.jpg, but the 80n prefix identifies it as referring to _my_ photo.

<br><br>Another example.  I wanted to render a map that showed all major roads in an area but only a selected few unclassified roads.  I tagged those roads I wanted with 80n:ibm=yes and then used a modified version of the osmarender rules file to only select ways that had that tag, like this:

<rule e="way" k="80n:ibm" v="yes">   <rule e="way" k="highway" v="unclassified">...</rule> </rule> The purpose here was to show only the relevant roads leading to a particular IBM facility, and suppress all the irrelevant roads in the area.  It worked quite well.

<br><br>Etienne<br><br><br><div><span class="gmail_quote">On 7/20/06, <b class="gmail_sendername">Nicola Ranaldo</b> <<a href="mailto:ranaldo@unina.it">ranaldo@unina.it</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On Thursday 20 July 2006 10:28, Andy Robinson wrote:<br>> No, you are absolutely right, nearly everyone wishes to see a level of<br>> consistency. The trouble is not everyone wants to use the OSM data for the<br><br>

[...]<br><br>> tags that are already there. Existing tags should never be deleted if<br>> possible in case they are being used by someone.<br><br>From a developer point of view:<br><br>* when a user enter a tag for an osm object, this information is available for

<br>everyone in the world<br>* this information should be useful for the community and not for private<br>needs (use your hard disk for that :))<br>* this information in the 99% of cases will be used by the software and not by

humans! * the software does not know the human meaning of a tag but has to follow a well-defined set of rules ==> * you should enter data in osm if well defined! * you should fix data in osm if not well defined!

<br>* before adding an undocumented tag in the system post an rfc on the<br>mailing-list<br><br>If this is against the freedom (to construct an unusable data set?), we should<br>separate tags in "namespaces", and reserve an XXX official namespace only for

common rendering/viewing/routeplanning where data integrity is strongly enforced. Other namespaces could be free (to construct private data set?) if we really need them. Editors and viewers could be free or XXX compliant.

<br><br>The same concept should be applied to data primitives, we should strongly<br>define them and enforce data integrity on the database, for example the id is<br>an integer > 0 and in the osmplanet there are ways with segs with a negative

<br>id. Are two segments from x to y and from y to x admitted? Are two nodes with<br>the same lat,lon admitted? Actual editors take care of those?<br>As specified in the "Data Primitives" wiki page, ways and areas are objects

<br>with the same elements. Is necessary to separate them? If not what are the<br>differences? these are simple examples, but while coding osm "clients" they<br>affects data structures more then a bit, and shows strange paths when doing

<br>route-planning!<br><br>        Niko<br><br><br>_______________________________________________<br>talk mailing list<br><a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk">

http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk</a><br></blockquote></div><br>