[OSM-talk] Prolification of the amenity tag

[guy at graviles-reynolds.org]

Quoting Chris Fleming <me at chrisfleming.org>:

> Robert (Jamie) Munro wrote:
> > SteveC wrote:
> >   
> >> * @ 29/11/06 09:30:36 AM richard at systemeD.net wrote:
> >>     
> >>> Quoting bvh <bvh-osm at irule.be>:
> >>>
> >>>       
> >>>> 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.
> >>>>         
> >>> Though I generally agree with your point, park & ride is a valuable  
> >>> navigation feature for anyone driving into a city. It may  
> >>> significantly alter the route you choose and determine the eventual  
> >>> destination of your journey. I would ask you to reconsider your vote  
> >>> against here.
> >>>       
> >> I read 'park_ride' as 'chessington world of adventures'[1]. Maybe make it
> a
> >> bit more idiot-proof?
> >>     
> >
> > During the Christmas period, Chessington World of Adventures is closed,
> > so it's car park is used to run a park and ride Christmas shopping
> > service for Kingston on Thames(*). Maybe this is why it is tagged that
> > way (if indeed it is - I haven't checked).
> >
> > On the proposal, I disagree completely with the examples given, but not
> > the principle. I think we need a limited list of valid amenities, and we
> > should have something in the back end that enforces this list for this
> > tag (and other lists of other tags). If the list is restricted, it can
> > be translated, and we can make the site useful internationally.
> >
> > However, wifi, park_ride, and clinic all seem like valid amenities to me.
> >   
> I've been thinking about this and following the discussion, and having 
> gone from no particular opinion on this to thinking that we should only 
> tag physical attributes. Therefore things like car parks, park and 
> rides, pubs, petrol stations, churches are physical things, there is no 
> mistaking these and even if they close they will still be there for some 
> time. Also because they are obvious if they change this will be spotted 
> quickly and the data updated.
> 
> Somethings like Wifi is much harder, whilst it does have a physical 
> location (of the base station) it is something that is in the air 
> covering an area. But in addition it is something that can vary day to 
> day on the whim of a business, be turned on or off with little or no 
> notice. It makes sense to me at least that these kind of things should 
> be stored elsewhere. In the same way that we would indicate the location 
> of a pub on the map, but we wouldn't add it's email address or phone 
> number, or if it serves food, or it's opening hours, then why would we 
> indicate if it has wireless or not?
> 
> Cheers
> Chris
> 
As the person who originally requested amenities="wifi", ="park_ride", 
="clinic", it probably about time I added my twopenny worth. 

I can understand some of problems with ="wifi" and I will come onto that later, 
but with regards to the objections to ="clinic" and ="park_ride" I am somewhat 
stumped. I requested ="clinic" because in many parts of the world, and is 
becoming more so in the UK local communities are served not by a hospital which 
already has a tag, but by a clinic, thus it becomes a logical extension that 
the clinc should have a tag. Similarly with ="park_ride", parking already has a 
tag, thus where it exists 'Park and Ride' schemes should be identified and and 
differentiated. Note my employer does not reimburse parking fees if a park and 
ride scheme exists.

When I requested the tag I was thinking as much of street/area based setups, 
such as are appearing in Milton Keynes, Norwich and Brighton as I was of 
individual hotspots in cafes, bars etc, and with the growing use of VIOP 
services as well as computer access, it seemed to follow that just as phones 
are tagged, wifi services should be tagged.

The problem that I have with orginal objection, is that if you follow it to its 
logical conclusion OSM should do nothing other than map/hold data for roads, 
footpaths, cycle paths and railways and everything else should be done either 
with a mashup or by going elsewhere. The problem as I see it with this approach 
is that people will go elsewhere fullstop. My view, comes from a point of 
experience travelling the globe, and is if I have needed to find something   
a feature or amenity then the data should at least be in OSM, whether it is 
rendered as a matter of course and at what zoom level is another question. But 
there is nothing as easy as looking for something.

Take pharmacies for example, a proposed tag that also been voted against, 
during a trip upto Scotland this autumn a member of my family fell ill, the 
condition, we thought, was not too serious and could be treated with medcines 
from a pharmacy, miles from home we hit Perth, our first stop was an out of 
town Tesco (their petrol station is on my SatNav), but they had no pharmacy. We 
then asked about 20 people but none of them knew of a local pharmacy, they all 
knew of one or two but they we located in the depths of Perth. Not knowing 
Perth using the phone directory or yellow pages was pointless as it would have 
meant plotting each Pharmacy on the map in order to find both where it was and 
if it was close to our location. In the end we came across a paramedic who was 
able to point us to a doctor's surgery (another tag that has been voted 
against) with an attached pharmacy, just two streets away. When we arrived the 
parmacist refered my relative to the doctor and they ended up with precription 
medicine. This all took a great length of time and pain and discomfort on the 
part of my relative, which could have been saved simply by having a map which 
showed all the pharmacies in Perth.

Batchoy