This looks like a candidate for using a tag prefix to demarcate it from the main map features collection. Anyone can use a wiki username as a prefix without risk of conflict with some other tag that has the same name but a different purpose.  The owner of that wiki username can then dictate policy about how those tags can be used.

So, if you wanted to create a set of wardriving tags for example, register a wiki username, such as wd, or war, or wardrive, and then add tags like war:amenity=wifi, war:channel=6, war:encryption=WAP, etc.  You can also document the tagging scheme on the war user page so that others can understand the meaning of these tags and create them when appropriate.

I don't think there should be any rigid limits put on what data can be stored although it seems like in many cases it is better to store a link to some external source than to store the data in OSM where it most likely wouldn't get updated and will become stale.  In the above example the detailed attributes of the wifi source might be better described by reference to some external web site.  But that decision is entirely up to the person collecting and maintaining the data.

<br><br>80n<br><br><br><br><div><span class="gmail_quote">On 11/29/06, <b class="gmail_sendername">Andy Robinson</b> <<a href="mailto:Andy_J_Robinson@blueyonder.co.uk">Andy_J_Robinson@blueyonder.co.uk</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;">>-----Original Message-----<br>>From: <a href="mailto:talk-bounces@openstreetmap.org">

talk-bounces@openstreetmap.org</a> [mailto:<a href="mailto:talk-">talk-</a><br>><a href="mailto:bounces@openstreetmap.org">bounces@openstreetmap.org</a>] On Behalf Of bvh<br>>Sent: 29 November 2006 9:49 AM<br>>To: 

<a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>>Subject: [OSM-talk] Prolification of the amenity tag<br>><br>>While this mail has been triggered by the proposal for<br>>amenity="wifi", it is more about the amenities tag in general and

<br>>that is why I bring it up here instead of on the wiki.<br>><br>>My take on the amenities tag is that recent proposals have drifted to<br>>uses that are better served outside the openstreetmap database.<br>

><br>>For starters a (maybe) trivial conclusion : we do not want to tag<br>>everything that has a location (even if we could). So the question<br>>is where do we draw the line?<br>><br>>My take on it is that we should try to tag everything that is needed

>to find your way (the purpose of a map, no?) So it's perfectly >reasonable to tag football stadiums and churches because by virtue >of being easily recognizable they serve as a point of reference >out there in the field.

> >However, amenities="wifi", ="park_ride", ="clinic" etc don't share >that purpose. There is little value to add them to a map. > >That is not to say there is no value in knowing where these things are.

<br>>But that purpose is better served with a seperate project<br>>(let's call it openyellowpages). And certainly in Web 2.0 spirit<br>>of things there would be a mash-up so that if a user searches for<br>>all wifi zones in her neighbourhoud she'd get back a map from

>openstreetmap and an overlay from openyellowpages. > >So, I'll be voting against nearly all amenities proposals that are >currently being considered and I hope to find some people who think >the same about this.

<br>><br>>(Coincidently don't we need a page in the wiki with refused proposals?<br>>one thing we can immediatly add is flight paths.)<br><br>While I agree on gpx uploads of flightpaths being withheld from OSM I do

<br>that only because it confuses. However with respect to other geo data that<br>represents physical features (and the wifi access point hardware is a<br>physical feature) then why do we care what type of geo data the database

<br>holds. I'm concerned that we are not thinking outside the box if we set<br>restrictions based on traditional mapping. If my kids want to produce a map<br>of all the bubble gum machines in the area why would I not want to let them

(tooth decay permitting!), they would be producing an innovative map and one which has value to a certain group of society. It was the potential for this innovation in mapping that drew me to OSM in the first place.

<br><br>The counter argument is that the location of bubble gum machines should be<br>held in someone else's database. Fine if it exists and is free and open. But<br>in reality few sites are collecting data right now in the way OSM does and I

<br>think we should encourage others to go forward with this rather than block<br>them from the head start they can gain by using existing OSM data. Look at<br>Freethepostcode, ok its not within the OSM database as such but its founded

<br>on the same principals and we now have the NPE site collecting and extending<br>from the same idea. OSM is the ideal jumping off point from which to extend<br>a specific area of mapping.<br><br>Thus personally I believe that there should be few restrictions on the type

<br>of geo data but that the way information is tagged and associated needs some<br>additional work. Bubble gum machines are arguably not an amenity although I<br>think wifi access points certainly are in our modern world. Improvements in

<br>the extensibility of the Map Features tagging schema is something I'm<br>working on and hopefully will make some of these issues less contentious.<br><br>Cheers<br><br>Andy<br><br>><br>>cu bart<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><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>