Re: [Tagging] Feature Proposal - RFC - highway=escape_lane

[AJ Ashton]

As a data consumer, +1 to the idea of highway=service,
service=escape_lane. This combo is enough information to avoid any
confusion about what the purpose of the way is, while also fitting
with existing common data/render schemes. To be absolutely safe with
regard to routing, an appropriate dissuasive access tag could be
added.

-- 
AJ Ashton

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - highway=escape_lane

[David ``Smith'']

I agree this should be highway=service, service=escape_lane.

Also note, if I'm thinking of the right thing, in the US this is usually
called a "runaway truck ramp".  This phrase should appear in the feature
docuentation somewhere.
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Narrow Bridge (was: Reconstructing «Dificult passability» proposal to «Obstacle»)

[Stephen Hope]

Eric,

The English version did say that at one point, as well, before it was
changed back to the current definition.  Maybe the French one was copied
from it during that period.

Stephen


On 13 October 2012 04:49, Eric SIBERT  wrote:

>
>> Indeed, as pointed out by Martin, I have to use lanes=1. I had a
> misunderstanding with the lanes=* key. I thought lanes=* indicated the
> number of lanes in each direction, not the total number in both directions.
> The French wiki lanes=* page need a strong update, compared to the English
> one (todo list...).
>
> So, I will go on with lanes=1.
>
> Éric
>
> __**_
> Tagging mailing list
> Tagging@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reconstructing «Dificult passability» proposal to «Obstacle»

[Martin Koppenhoefer]

2012/10/12 Martin Koppenhoefer :
> 2012/10/12 Eric SIBERT :
>> No. It would indicate that it can't be used by vehicles.


sorry, I got you wrong here, thought you wanted to exclude them (foot-bridge).

cheers,
Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reconstructing «Dificult passability» proposal to «Obstacle»

[Martin Koppenhoefer]

2012/10/12 Eric SIBERT :
> No. It would indicate that it can't be used by vehicles.


if there are no legal restrictions one step or also 2 won't be an
unsurmountable obstacle for most vehicles.

cheers,
Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reconstructing «Dificult passability» proposal to «Obstacle»

[Eric SIBERT]

you could use lanes=1 on the narrow parts.


Agree.



- a bridge or a raft with a bad link to the road/track i.e. a step at each
end of the bridge/raft. obstacle=unevenness ? or obstacle=step? For me
unevenness is to soft for what you describe.



split the way and put a short highway=steps, step_count=1


No. It would indicate that it can't be used by vehicles.


- a road on a dam or a bridge have been damaged : a bailey bridge
(http://en.wikipedia.org/wiki/Bailey_bridge) have been temporary (for ten
years ;-) ) added on it.



is this an obstacle, or is it simply another type of bridge
construction? If it is an obstacle the tagging should line out in what
the obstacle consists (smoothness, width, maxweight, ...)


It's first a lanes=1 and second short connecting slopes at each end. 
Something no so far from the steps I mentioned earlier i.e. you have to 
slow down at entrance and exit of the bridge.


Éric

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] Narrow Bridge (was: Reconstructing «Dificult passability» proposal to «Obstacle»)

[Eric SIBERT]

- a narrow bridge i.e. you can't cross a vehicle in opposite
direction. We may use width=* but it is difficult to get it
precisely. obstacle=narrowness


It's slightly offtopic, but wouldn't it be logical to use "car" as a non
accurate unit of length? So you can have a tag like "width=1car" or
"width=1.5car".



I like it :-)

In Europe, I found :
"1 car" used 2 times
"wide enough for a car" used 1 time

Not wildly used.

Indeed, as pointed out by Martin, I have to use lanes=1. I had a 
misunderstanding with the lanes=* key. I thought lanes=* indicated the 
number of lanes in each direction, not the total number in both 
directions. The French wiki lanes=* page need a strong update, compared 
to the English one (todo list...).


So, I will go on with lanes=1.

Éric

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reconstructing «Dificult passability» proposal to «Obstacle»

[Dudley Ibbett]

Hi

In the UK local authorities are responsible for public rights of way.  Paths, 
bridleways etc.  There are so called Best Value Performance Indicators (BVPI) 
that require them to survey a certain % length of these each year to measure 
the ease of use of the network.

Documentation and forms for this are on the web.  
http://www.iprow.co.uk/gpg/index.php/Performance_Indicators

In this they talk on terms of Obstruction.  These are either points or lengths.

Point Obstructions (i.e. a discrete obstruction, on or too close to the path)

Wall/fence/hedge/electric fence/ other barrier
Tree/bough
Temporary Deposit (e.g. Straw bales)
Illegal or misleading sign
Building
Muddy/Boggy hole
Upgrowth (localised)

Linear Obstruction (Surface)

Cross-field not reinstated
Headland ploughed
Surface path our of repair
Flooded/muddy/boggy/rutted
Upgrowth

Linear Obstruction (Other)

Overgrowth
Standing water e.g. pond/lake
Barbed wire/electric fence adjacent
Intimidating beast/person
Encroachment (not ploughing) e.g. garden extension
Quarry
Plantation

It may be that this should be a different tag i.e. Obstruction as the objective 
of recording the above is to get the Obstruction removed and the right of way 
re-instated.

Regards

Dudley

Date: Fri, 12 Oct 2012 09:47:32 +0200
From: lakonfrariadelav...@gmail.com
To: tagging@openstreetmap.org
Subject: [Tagging] Reconstructing «Dificult passability» proposal to «Obstacle»

Hi!

I'm reconsidering my proposal...
Before introduce in the wiki, I wanted to show you a scheme of the purpose... 
to see the viability of this.
I nedd help and comments ;)

I think that the name «Difficult Passability» could be changed for «Obstacle=*» 
(I see that this name is used in OSM: 
http://taginfo.openstreetmap.org/keys/obstacle#values especially in Germany).


For values, I want to propose:
- obstacle=yes
- obstacle=fallen_tree
- obstacle=dense_vegetation --> you could combined with seasonal=yes

- obstacle=unevenness ---> when you probably need hands, but not only in 
technical hiking also could be a small wall of 1,5 meters height that you 
should overcome to continue the route, for example. It could be combined with 
«Safety measures on hiking trail»

- obstacle=narrowness (like this: 
http://img534.imageshack.us/img534/4315/11passetdelarabosa.jpg )
- obstacle=water --> and you could combine with ford=yes, for example or 
natural=wetland


I'm not sure what to do with the value obstacle=with_precipe... ¿Rename it? 
¿Omit it? ¿obstacle=precipice? ¿obstacle=cliff?

A «obstacle_description=*» key could be added for text (especially if only 
obstacle=yes you use).


The key refers to pedestrian and generalizes for bicycles or motor vehicles... 
perhaps a obstacle affects only to motor vehicles...
In this case, could be interesting to use especification like in the key 
access? obstacle:horse=yes , for example?

Thanks a lot!!
-- 
KONFRARE ALBERT
La Konfraria de la Vila del Pingüí de La Palma 
WEB:http://www.konfraria.org

TWITTER: http://twitter.com/La_Konfraria 
FACEBOOK: 
http://ca-es.facebook.com/people/Konfraria-Vila-Del-Pingui/11918952076





___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging 
  ___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - highway=escape_lane (Craig Wallace)

[José Juan Sánchez del Arco]

Maybe, but I think we shouldn't tag strips of road which are not intended for 
driving in any way but for stopping as highway=service.
  ___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Standard for external links to location based services

[Dave Sutter]

I think we should work on making it easier to link to OSM from outside.

People can discuss which entities should and should not be a part of
the map as opposed to being part of an external database. The same
issue came up with regard to ferry schedules and whether they should
be included in the map. In the end, we can never include all the
information inside of OpenStreetMap that someone would want.

Along with this, I think we should work on an OpenWebYellowPages or
some sort of entity database, possibly more general than just
businesses. Like maybe ferry schedules too. The formalism to link back
to OSM would probably be through street address and ref, for example.

As soon as I have the time I would like to put some ideas up on the
wiki, but I am pretty busy these days. I would invite someone else to
beat me to it.

Dave

On Fri, Oct 12, 2012 at 6:54 AM, Eckhart Wörner  wrote:
> Hi Tobias,
>
> Am Freitag, 12. Oktober 2012, 13:13:47 schrieb Tobias Knerr:
>> New players should indeed be treated the same as dominating platforms
>> (see Flickr): If they want OSM integration, they should link to OSM, not
>> the other way around.
>
> well, except that linking to OSM is notoriously difficult.
>
> Eckhart
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - highway=escape_lane

[Craig Wallace]

On 12/10/2012 16:38, José Juan Sánchez del Arco wrote:

I have updated an old proposal, relating to highways, escape lanes for
trucks and cars alongside motorways to stop them. Please visit the
proposal page:
http://wiki.openstreetmap.org/wiki/Proposed_features/escape_lane


I think this is just a special type of service road, so would be best 
tagged as highway=service, plus something like service=escape_lane.

Plus appropriate tags for surface= and access= etc.

According to Taginfo, service=escape_lane is already used 87 times.

I think this is better than inventing a new highway tag, which won't be 
understood by any software / renderers etc.


Craig


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Standard for external links to location based services

[Eckhart Wörner]

Hi Tobias,

Am Freitag, 12. Oktober 2012, 13:13:47 schrieb Tobias Knerr:
> New players should indeed be treated the same as dominating platforms
> (see Flickr): If they want OSM integration, they should link to OSM, not
> the other way around.

well, except that linking to OSM is notoriously difficult.

Eckhart

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Standard for external links to location based services

[Richard Smith]

On 12/10/2012 09:57, Pieren wrote:

On Fri, Oct 12, 2012 at 10:15 AM, Simone Saviolo
 wrote:


I think that contact info of an amenity (allow me to group shops,
restaurants, bars, and companies under that umbrella just for a minute)
should be considered all of equal importance.

They are amenities that stay for long time like post offices. And
amenities that are changing very fast like shops and restaurants. I
think OSM should concentrate on the first. OSM is not a google-like
bot scanning the web to build automatically a yellow-page db.
Surveying things like commercial streets are inevitably outdated
quickly. I would say that "amenities" that cannot be found in
wikipedia should be considered as commercial advertising.

Pieren

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


Hi Pieren

While the purist inside me likes the idea of keeping OSM as up to date as possible I must disagree with the idea off de-prioritising amenities that could be considered as commercial advertising from 
OSM. In fact I believe that almost the opposite approach is constructive to OSM in the longer run for the following reasons.


For OSM data to reach a tipping point and become a tool and resource that is widely known and used by the public in the way that Google maps is then it needs to offer information on a similar scale. 
The general public don't just want a map to find where they are geographically, they expect this as standard these days, they want to know in detail about the things around them; what they can do, 
where and how they can do it. Data on shops, hotels and general businesses is exactly the sort of thing people are looking for in this respect. As such OSM must offer these locations for other people 
in order to build tools and apps off them. Providing information links on top of these locations as suggested in Alex's original post is only going to extend the usefulness and I believe is the right 
way to do it.


Linking the extra none mapping info rather than try and provide it all as key value pairs in OSM is a great approach and fits neatly in with Tim Bernard Lees talk on the expansion of the web as a form 
of linked data ( http://www.ted.com/talks/tim_berners_lee_on_the_next_web.html ). For example if we start adding tags with hard links to review sites for a particular place it might even be possible 
to provide a positive feedback loop where a site that combined the OSM geo data and the review site data could then scan the link to see if there where any reviews marking the place as closed and in 
turn feed this back into OSM and remove or update the appropriate node if the business closed down (a little far fetched but you have to dream). Drawing up a simple schema that avoids namespace 
collisions and the like early on seems a good way to go (I would encourage Alex to add the info in his email to a page on the wiki).


There may be a number of dedicated mappers out there that keep their local areas up to date as far as shops and day to day amenities but we need to reach a tipping point where it becomes a competitive 
disadvantage for a business not to have their information in OSM due to the large number of services using OSM data for the public good. As such I think we should be tagging businesses as fast as we 
can. If people start turning up at a business find the wrong one they are more likely to update it themselves or ask the shop keeper who has good incentive to change it than if they never found it in 
the first place and never let the shop keeper know about it.


As I said before we should be driving towards building a service with a strong commercial intensive to free data under our licence if we are ever going to compete with the Google and other 
propitiatory mapping services. Without dedicated mappers starting the ball rolling we will be forever stuck in catch 22.


Cheers - Richard







___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reconstructing «Dificult passability» proposal to «Obstacle»

[Martin Koppenhoefer]

2012/10/12 Eric Sibert :
> - a narrow bridge i.e. you can't cross a vehicle in opposite direction. We
> may use width=* but it is difficult to get it precisely. obstacle=narrowness


you could use lanes=1 on the narrow parts. "narrowness" is a very
relative concept and I wouldn't encourage you to use it, IMHO it is
better to use width (or est_width) also with rough estimates  it will
still be more useful.


> - a bridge or a raft with a bad link to the road/track i.e. a step at each
> end of the bridge/raft. obstacle=unevenness ? or obstacle=step? For me
> unevenness is to soft for what you describe.


split the way and put a short highway=steps, step_count=1


> - a road on a dam or a bridge have been damaged : a bailey bridge
> (http://en.wikipedia.org/wiki/Bailey_bridge) have been temporary (for ten
> years ;-) ) added on it.


is this an obstacle, or is it simply another type of bridge
construction? If it is an obstacle the tagging should line out in what
the obstacle consists (smoothness, width, maxweight, ...)


In general the change to "obstacle" as key seems consistent with what
you want to express. I would refrain from narrowness and water, as
there are already other ways to express them.

cheers,
Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reconstructing «Dificult passability» proposal to «Obstacle»

[Janko Mihelić]

2012/10/12 Eric Sibert 

> - a narrow bridge i.e. you can't cross a vehicle in opposite direction. We
> may use width=* but it is difficult to get it precisely. obstacle=narrowness
>

It's slightly offtopic, but wouldn't it be logical to use "car" as a non
accurate unit of length? So you can have a tag like "width=1car" or
"width=1.5car".

I remember people using 1.5 for the lanes=* tag, but this looks better to
me.

And for the obstacle, I think it's a useful tag. I'll vote for it.

Janko
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reconstructing «Dificult passability» proposal to «Obstacle»

[Eric Sibert]

Hi,

During my last travel in Africa, I was thinking on how to map  
obstacles on road. So I support your proposal but in a generalized  
way, not only for pedestrian or bicycle. And I take the opportunity to  
review what I observed:
- a narrow bridge i.e. you can't cross a vehicle in opposite  
direction. We may use width=* but it is difficult to get it precisely.  
obstacle=narrowness
- a bridge or a raft with a bad link to the road/track i.e. a step at  
each end of the bridge/raft. obstacle=unevenness ? or obstacle=step?  
For me unevenness is to soft for what you describe.

- a hole in the road.
  * A small hole you can drive other at full speed but that may  
surprise you when driving during night.
  * A medium hole where you have to use the other side of the road at  
full speed if nobody is arriving in front

  * A big hole where you have to slow down and drive inside.
(For full uneven sections, I use smoothness=*).
- a road on a dam or a bridge have been damaged : a bailey bridge  
(http://en.wikipedia.org/wiki/Bailey_bridge) have been temporary (for  
ten years ;-) ) added on it.


I would no use obstacle for thinks that are deliberate and/or in their  
initial state.


For river and water. If there is water year around (or large fraction  
of the year) : ford=yes. Only flooded few days a year (after heavy  
rain), flood_prone=yes. Use surface=* to indicate whenever you are  
just driving in the river or if there is some raft build. Seasonal?  
Use seasonal=yes in conjunction with access:conditional=* to indicate  
approximative closing period (discussed recently on this mailing list.  
I will update the wiki according soon...).


Same with traffic_calming, check points...

HOT is also dealing with obstacle :

http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/Humanitarian_Data_Model#Obstacle

Eric



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Standard for external links to location based services

[Tobias Knerr]

On 11.10.2012 20:52, Alexander wrote:
> I am trying to establish a standard for external links to various
> platforms (including but not only facbook, qype, foursquare etc.)
[...]
> I wouldn't like to limit the tagging to these dominating platforms. New
> players should be threaten equally. Maybe this could encourage future
> services to use (and contribute to) the OSM.

New players should indeed be treated the same as dominating platforms
(see Flickr): If they want OSM integration, they should link to OSM, not
the other way around. This lets us avoid a lot of problems where e.g.
the startup of the week floods OSM with links to their trendy service
and insists on "equal treatment". There are hundreds of review sites
alone, I don't see how we can reasonably include them all.

So imo we should link the official website and leave it at that. If some
business uses a Facebook page or something similar as their primary
online presence and has no actual website, then you could put that into
url - no need to use a suffix, the domain can already be used to
identify it as a Facebook page.

> And as we have no idea what the upcoming services will be called I
> recommend to prefix them with something like:
> 
> url:[service_name]

If we did catalogue multiple external links, this would probably be the
best key. But I prefer to avoid external links to proprietary services
entirely, mostly because there are too many of them and singling out a
few is inherently unfair. I would also like to point out that we are
struggling to keep even the shops/amenities themselves updated.

Setting up an OpenBusinessDirectory or some other "link hub", with data
under a free license and a much simpler interface for adding and editing
entries than OSM has to offer (due to the specialized focus), would make
more sense than turning OSM into something that bears closer resemblance
to a web directory than a geographic database. That project could then
of course be connected with OSM.

Tobias

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Standard for external links to location based services

[Simone Saviolo]

2012/10/12 Pieren 

> On Fri, Oct 12, 2012 at 11:08 AM, Simone Saviolo
>  wrote:
>
> > by that reasoning, we should remove all the bars, all the shops, all the
> > restaurants, all the companies, all the fuel stations, all the parking
> > information (a free parking may become a ticket-only parking), all the
> names
> > of the buildings (even worldwide famous skyscrapers have changed their
> name
> > as their owner sold them to someone else). Are we sure we want to make a
> map
> > where there is no restaurant?
>
> Read my post carefully. I'm not asking to remove anything. I'm saying
> that most of this information is quickly outdated in OSM and that
> other services like google are doing it better than us.
>

I agree that information gets outdated. Information is "outdated" by
definition, in a sense: I can only say that it was accurate last time I
checked it. But let's not get all philosophical about that.

However, isn't one of the main selling points of OSM the fact that, since
it's user-contributed, it has the potential to be the most up-to-date map
in the world? Just like the death of an actor or the results of the latest
Formula 1 Grand Prix are on Wikipedia within minutes, an area with active
mappers can be updated in just a few hours, or days - which is *very* fast
for a map! Like Martin said, as soon as a restaurant in my city becomes
something else I'll notice it and edit the map - this is not true with a
Google-like Web Yellow Pages of sort: the new owners would have to notice
the service, which will go through all the notifications, and maybe one day
update its database.

To get back to the specifics of the web contact information, I can
understand the risk that, being it information that is not usually shown in
a prominent manner, it may be overlooked and become outdated more easily
than, for instance, the name of the amenity. However, when I, as a mapper,
select the POI of a restaurant to edit it because it changed significantly
(it became a shop, or the owner changed and called it differently), I'll
notice that there are a dozen of tags referring to the old company's social
pages and will remove or update them accordingly.

Granted, in a non-actively-covered area, the data may be weeks, months, or
even years old. But this is not worse than what would happen to a
"Google-like" service if it doesn't notice the change. And often it's not
that bad.

As to the aspect of the commercial advertising, I agree that a restaurant
marked on a map is implicitly being advertised and has an advantage over
another one that is not mapped. However, on one hand nothing prevents
company-owners from adding and maintaining their own geographic information
anyway, and on the other hand the company is not the only one that benefits
from being on the map. Again, "by that reasoning" :-) we could conclude
that mapping a paid parking implies advertising it, but actually we're
giving car drivers the information that a parking is available, if they're
willing to spend.

Ciao,

Simone
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Standard for external links to location based services

[Martin Koppenhoefer]

2012/10/12 Pieren :
> Read my post carefully. I'm not asking to remove anything. I'm saying
> that most of this information is quickly outdated in OSM and that
> other services like google are doing it better than us.


yes, others (like Apple) are doing worse ;-) Unfortunately neither of
them lets us download their complete data, so we can either make our
own, or continue to rely on them.

cheers,
Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Standard for external links to location based services

[Martin Koppenhoefer]

2012/10/12 Pieren :
> On Fri, Oct 12, 2012 at 10:15 AM, Simone Saviolo
>  wrote:
>
>> I think that contact info of an amenity (allow me to group shops,
>> restaurants, bars, and companies under that umbrella just for a minute)
>> should be considered all of equal importance.
>
> They are amenities that stay for long time like post offices. And
> amenities that are changing very fast like shops and restaurants.


this is all relative. If you live in an area where the post is doing
restructuring, it might be the opposite.


> I
> think OSM should concentrate on the first. OSM is not a google-like
> bot scanning the web to build automatically a yellow-page db.
> Surveying things like commercial streets are inevitably outdated
> quickly.


-1, IMHO mapping their own environment in great detail is a main
interest of many mappers, and shops and restaurants etc. are an
important part of it. By declaring that we don't want this data in OSM
we are removing the joy for those mappers.


> I would say that "amenities" that cannot be found in
> wikipedia should be considered as commercial advertising.


this is a rather extreme position and should be rethought IMHO. We
should not let us restrict by third parties when it comes to our key
business, mapping, and especially what to map. Please bear in mind
that there is no such thing as "the wikipedia" if you look at the
rules what to include and what not. Different local chapters might
have quite different rules. For instance the German wikipedia is well
known for being very restrictive on what to include [1], and with this
policy it has already scared away a lot of contributors.

cheers,
Martin

[1] http://de.wikipedia.org/wiki/Wikipedia:Relevanzkriterien

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Standard for external links to location based services

[Pieren]

On Fri, Oct 12, 2012 at 11:08 AM, Simone Saviolo
 wrote:

> by that reasoning, we should remove all the bars, all the shops, all the
> restaurants, all the companies, all the fuel stations, all the parking
> information (a free parking may become a ticket-only parking), all the names
> of the buildings (even worldwide famous skyscrapers have changed their name
> as their owner sold them to someone else). Are we sure we want to make a map
> where there is no restaurant?

Read my post carefully. I'm not asking to remove anything. I'm saying
that most of this information is quickly outdated in OSM and that
other services like google are doing it better than us.

Pieren

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Standard for external links to location based services

[Simone Saviolo]

2012/10/12 Pieren 

> On Fri, Oct 12, 2012 at 10:15 AM, Simone Saviolo
>  wrote:
>
> > I think that contact info of an amenity (allow me to group shops,
> > restaurants, bars, and companies under that umbrella just for a minute)
> > should be considered all of equal importance.
>
> They are amenities that stay for long time like post offices. And
> amenities that are changing very fast like shops and restaurants. I
> think OSM should concentrate on the first. OSM is not a google-like
> bot scanning the web to build automatically a yellow-page db.
> Surveying things like commercial streets are inevitably outdated
> quickly. I would say that "amenities" that cannot be found in
> wikipedia should be considered as commercial advertising.
>

Ok, I see that you decided to be consistent and to go all the way - but
this is what I hoped I'd discourage everybody about :-)

While I understand the logic of this reasoning (I did it myself!), I don't
think this is the direction we should follow. I'll say it again: by that
reasoning, we should remove all the bars, all the shops, all the
restaurants, all the companies, all the fuel stations, all the parking
information (a free parking may become a ticket-only parking), all the
names of the buildings (even worldwide famous skyscrapers have changed
their name as their owner sold them to someone else). Are we sure we want
to make a map where there is no restaurant?
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Standard for external links to location based services

[Pieren]

On Fri, Oct 12, 2012 at 10:15 AM, Simone Saviolo
 wrote:

> I think that contact info of an amenity (allow me to group shops,
> restaurants, bars, and companies under that umbrella just for a minute)
> should be considered all of equal importance.

They are amenities that stay for long time like post offices. And
amenities that are changing very fast like shops and restaurants. I
think OSM should concentrate on the first. OSM is not a google-like
bot scanning the web to build automatically a yellow-page db.
Surveying things like commercial streets are inevitably outdated
quickly. I would say that "amenities" that cannot be found in
wikipedia should be considered as commercial advertising.

Pieren

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Standard for external links to location based services

[Simone Saviolo]

2012/10/12 Eugene Alvin Villar 

> However, I personally don't think your example of putting the URLs to
> a place's webpage on foursquare, Google+, Yelp, TripAdvisor, etc. is
> the way to go.
>
> OSM is not a link directory so adding many such links on the OSM
> database doesn't seem appropriate. One or two is maybe OK.
>

I don't agree. If we follow that reasoning consistently, we may conclude
that tagging a bar on OSM is wrong, because OSM is not a bar directory, and
its name may change, and it may close, etc.

I think that contact info of an amenity (allow me to group shops,
restaurants, bars, and companies under that umbrella just for a minute)
should be considered all of equal importance. The telephone number and the
website are not information that changes every week, and so they're as
stable as the amenity name. If the Facebook page of the amenity should not
be in OSM, then surely the operator should not, and I would even question
the name.

Regards,

Simone
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging