[OSM-talk] Prolification of the amenity tag

[bvh]

On Wed, Nov 29, 2006 at 05:27:50PM +0000, guy at graviles-reynolds.org wrote:
> 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 

One, we can clearly stop somewhere (and we will) there is no need to
say that one approach must be followed to its logical extreme. It
also goes the other way : do you want to tag amenity="bluetooth-cellphone"
and have me update it in real time?  Of course not.

> is that people will go elsewhere fullstop. My view, comes from a point of 

Why? And where?

> 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.

But exactly that is nearly impossible with Openstreetmap. If you go
to yellowiki the data is easily available.

Suppose you want to know if there is a butcher in your area and all you
have is openstreetmap. That would require you to look up your area
with an editor, find all nodes with amenity="butcher" 
(manually, no editor does this automatically) and then go sift through
the tags to find out if it is open today, if they speak English and
if they sell Halal meat.

While most of that could be automated with better client support,
what is not going to go away is the heavy mmap=? lookup. It's a scheme
that is bound to not scale...

Contrast with having that data in yellowiki. You'd just search for
"butcher halal london" and there you go. Combine with a mashup with
Openstreetmap (seems someone already did the work, the link has been
quoted in this thread) and everything is already working _right now_
and much quicker and easier!

> 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.

Which you can already get _today_ if that pharmacy had been in the
yellowiki database. However if that pharmacy had been in openstreetmap
database as a node with appropriate tags you'd be _none_ the wiser...

That is the situation as it is right now!

cu bart