Re: [Tagging] new access value

[Friedrich Volkmann]

On 09.10.2015 23:44, Richard Fairhurst wrote:
> Friedrich Volkmann wrote:
>> Contribute something useful, or get a life.
> 
> Please retract that insult, and agree not to post such comments in the
> future, or you will be removed from this list.

What insult? Do you mean me or him? He offended me by writing: "You dont get
it dont you?" - indicating that I am stupid.

Anyway, I don't see a reason why you interfere in this quarrel. It was
already over. Now you are firing it up again. As a moderator, you should
rather calm people down than inflame. And you should use personal messages
instead of public accusation - which always makes someone lose face.

Consider that neither he nor me are native English speakers. We use phrases
according to our dictionaries. I cautiously check whether phrases like "get
a life" may be insulting. I wouldn't use an insult intentionally. But
dictionaries may contain errors.

For the same reason, I think that Nikita (Xxxzme) should not have been
banned from this list. His alleged "strong language" was mainly due to a
lack of language skills. It is a pity that most russians don't participate
in international discussions. With their limited knowledge of the English
language, most of them don't even try. Those who do, get banned. This is
concerning. Deprived of international communication, they make up their own
tagging schemes, and OSM becomes increasingly balkanized.

So when you moderate a group, keep in mind that sometimes less is more.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 09.10.2015 23:42, ajt1...@gmail.com wrote:
>>> localised meaning does not always have to be parsed into universal
>>> tags.
>>>
>>> Here in the UK we have very specific access legislation for paths. On a
>>> bridleway, for example, cycling is permitted, but cycle racing is forbidden,
>>> and cannot be authorised (whereas it can be authorised on other rights of
>>> way). Then we have "restricted byways". And "byways open to all traffic".
>>> And "unclassified county roads". And so on.
>> Sounds more like a road type issue than an access tags issue.
> 
> It's not a road type issue.  It's not especially uncommon to have a "legal
> right of access" that legally allows vehicles that physically won't fit.

This discussion is about access tags, hence legal right of access. In this
context, physical fit does not matter.

>>> So we use the standard OSM broad-brush duck tagging (highway=track,
>>> highway=footway, highway=cycleway etc.) and add a UK-specific value to
>>> record the legal status of the path (designation=public_bridleway,
>>> designation=restricted_byway, designation=byway_open_to_all_traffic etc.).
>>> That way, it's easy to map, easy to parse in outline, possible to parse in
>>> detail, and doesn't impose a burden on the 95% of non-UK mappers or the 99%
>>> of data consumers who don't care.
>> However, the data consumers who do care have a hard time.
> 
> I do care (I create maps that incorporate these rights of way), and don't
> have a hard time.

Are you UK-based by any chance? Of course everyone incorporates the tags
used by the own community.

How do you handle designation=Državna_cesta?

> "creating a proprietary tag" is effectively exactly what you're proposing
> (the first line of the first message in this thread was "I intend to write a
> proposal for a new access=* value, but I don't know a reasonable tag name.").

This tag will not be proprietary. It will have a clearly defined meaning, it
will be documented in the usal wiki pages, and everyone all over the world
is free to use it.

> You're entirely within your rights to use a new "access" value, and everyone
> else (router developers included) is entirely within their rights (and very
> likely) to ignore it.

Application developers in countries where such roads exist will certainly
support the tag right from the start, and others will follow when usage
numbers increase.

Anyway, I don't care whether the tag is supported. I don't do "mapping for
routers". If they want to use it, that's fine. If they ignore it, that's
fine too. Nobody is forced to use their software.

> This does a worse job of communicating the access
> rights to the intended audience than "access=destination with some sort of
> caveat" would.

A proposal (with certainly plenty of discussion) and the subsequent
documentation at key:access will be sufficient communication. We don't need
to visit every developer on Earth personally for every new tag.

> There are routers out there that don't understand that bicycle access on
> trunk roads is country dependant, or that it might be possible to route
> _through_ gates on tracks; do you really think that they'll cope well with
> an access value that they've never heard of?

Yes, because the new value will neither be country-dependent (as bicycle on
trunk) nor lockable (as a gate).

I reckon that most applications will treat the new tag as a synonym for
access=yes or no, just as they do for
access=destination/delivery/agricultural/etc. But applications will
elaborate over the years, and we don't want to remap all data when
applications happen to be ready.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 08.10.2015 12:16, Lauri Kytömaa wrote:
(...a lot. I try to narrow it down to the critical passages.)

> sometimes the signs restrict the
> traffic by "who", not by destination. I.e. in the Anreinerverkehr case,
> [...] it's no longer about the destination, but which
> group of people you, or the passengers, belong to. It's not about the "for
> a purpose (like agricultural, forestry, delivery), nor "by permission", and
> it's not about how your vehicle is registered as (the key part)
> 
> The number of different access tag values should be kept to a minimum,
[...]
> There's already a list of "by use" keys in on the Key:access page, although
> only "disabled" is directly comparable;

The access tags are built like this:
=

"disabled" is not a mode of transport. Therefore, it should rather be a
value than a key. The reason it is a key is because it was introduced in
OSM's stone age.

Let's have a look at the currently documented values:
yes, private, no, permissive, agricultural, use_sidepath, delivery,
designated, dismount, discouraged, forestry, destination, customers.

Some belong to the "purpose" category, but others belong to the "group of
people" category, and some values don't fit in either category.

yes ... (matches any category)
no ... (matches any category)
private ... owners and people with granted permission => group of people
permissive ... all except people with revoked permisson => group of people
agricultural ... purpose
use_sidepath ... same as "no" + hint to traffic sign
delivery ... purpose
designated ... same as "yes" + hint to traffic sign
dismount ... same as "no" + hint to traffic sign
discouraged ... same as "yes" + hint to traffic sign
forestry ... purpose
destination ... route geometry
customers ... group of people

So we've got 3x "group of people". The new tag will just be the forth in
that category.

> - however, if there are reasons why setting a destination there is subject
> to "doesn't belong to a group of people" limits, let's invent a new key,
> or a group of keys.

If you like to move the "group of people" category to new keys, you need to
deprecate access=private/permissive/customers to stay consistent.

> Those tags could then be used to tell that if the user
> has a destination there, they can go, but there may be reasons that they
> legally can't set a (motor) destination there.
> 
> So, the tags, for example:
> 
> motor_vehicle=destination
> + destination:limited=Anreinerverkehr

Non-English values with uppercase letters? Are you serious?
You misspelled it, and other will misspell it too. And nobody except
German-speaking people will have an idea what this tag means. Even among
them, there's a lot of misconception and dispute regarding that word.

> (latter would apply to whatever mode has =destination)
> + destination:limited:something=Johannesbach fishing resort
> when not obvious and when necessary to describe which is the only
> possible point of "contact" the local system requires.

How are routers supposed to make use of that free-text tag?
What does the "something" part mean?
I am quite puzzled, and I fear that data consumers will be too.

> or, if necessary (doubt it, but for future reference)
> destination:limited:motor_vehicle=Anleiter
> destination:limited:hgv=(something else)
> 
> The values can be indexed and explained in the wiki, and shown to the
> user as-is or with explanations.

Shown to the user? At what stage? And remember that applications are not
limited to route calculation. Displaying lists with explanations for each
single road may get difficult in a paper map.

> The second possible solution is to use only tags that define the restrictions
> group by group:
> - motor_vehicle=private
> - limited:Anreiner=yes
> - limited:Anreinerverkehr=no

Non-English words with uppercase letters even in keys?

> *
> - motor_vehicle=destination
> - limited:Anreiner=yes
> - limited:Anreinerverkehr=yes
> 
> Here, the prefix "limited:" is used to tell that the latter part is a name of
> a group. limited:disabled= and limited:customers= would be possible
> (this is why I opposed using customers as an access value, it's not a
> legal access type but a group).

Anrainerverkehr is not a group. So it does not fit in your tagging scheme.

"limited" sounds like a shortage. When you suggest a tagging scheme about
groups of people, you better name it like motor_vehicle:for=* (compare to
social_facility:for=*).
But it won't work either way, because you are soon getting 2-dimensional.
E.g. for group A it may be vehicle=yes and for group B it may be
vehicle=destination and for group C it may be vehicle=no. You need to
incorporate your scheme into
http://wiki.openstreetmap.org/wiki/Conditional_restrictions.

Anyway, it's already too late. The ship has sailed. You opposed "customers",
but you did not stop it. Let alone "private", which stands for a group as
well. You will never get access=private deprecated.

> For what's it worth, 

Re: [Tagging] new access value

[Friedrich Volkmann]

On 08.10.2015 16:05, Marc Gemis wrote:
> Just as your new value. That is not documented neither. A new value or a new
> key, both have to be documented and implemented.

A new tag value fits more into an existing tagging scheme than a new key.

Some applications (such as even the standard renderer, as I was told) run
with a separate database where only a small list of keys is imported.

And with a new key, you have to handle more conflicts.
Say, vehicle=yes + traffic_sign=no_vehicles.
This causes headache to other mappers as well as application developers.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 08.10.2015 04:21, John Willis wrote:
> How do they enforce it in Europe? Stickers on cars? Stop and ask? 

In cities, there are lots of 30 km/h speed limits, oneways and
traffic_calming=* to deter cutters. Parking requires a sticker on the car.
Residents need to pay for it (around 150 €/year in Vienna), others won't get
it at all. There are police-like troops who roam the streets at night,
looking for parking violators.

In rural settlements, the police can stop you and ask, but it is unlikely
that they come across you on minor roads. When they want to make money, they
usually hide in a bush near a primary road and measure speeds. On minor
roads, you rather get in conflict with residents. When you drive thru a road
where this is forbidden, or when you park on their property, they make a
photo of your car and then sue you.

It also depends on the country. In Germany, only the driver can be fined. So
they need to make a photo of the driver. In Austria, all they need is the
number on your licence plate. Whenever they don't know the driver, they fine
the car owner.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Shop values review

[Friedrich Volkmann]

On 07.10.2015 20:26, Matthijs Melissen wrote:
> On 7 October 2015 at 15:58, Daniel Koć  wrote:
>> builder
> 
> Not sure what this is used for.

I have mapped some craft=builder. Small offices, maybe with some storage for
tools and construction materials. shop=* seems wrong.

>> building_materials
> 
> Possibly duplicate with shop=doityourself, not sure though.

shop=trade

>> craft
> 
> I use this for shops selling coloured paper, glue, knitting supplies etc.

sounds like shop=stationery or shop=fabric

>> hobby
> 
> Similar to shop=craft.

Do you know what hobby this is about? Almost everything can be a hobby.

>> antique - no wiki, mentioned on antiques page so maybe deprecate and propose
>> antiques?
> 
> Yes, shop=antiques is more popular.

They obviously mean the same. Deprecating the rare one will do no harm.

>> car_service - maybe car_repair?
> 
> Agree.

Some companies focus on car service, but all of them can do some repair as
well, so this is certainly a candidate for a subtag of shop=car_repair. But
not service=* as suggested on the shop=car_repair page. There is something
going wrong. service=* is already a subtag of highway=service and
railway=service.

>> souvenir - gift?
> 
> No, for example in Amsterdam shops where tourists buy things to take
> home are very distinct from shops were people go to buy a present for
> a friend they are visiting.

The shop=gift tag definition explicitely covers "tourist gifts (souvenirs)".

What present do you buy for a friend? Jewelry? That's shop=jewelry.
Confectionery? That's shop=confectionery. Flowers? shop=florist.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 06.10.2015 23:11, John Willis wrote:
> 
> 
>> On Oct 6, 2015, at 8:48 PM, Friedrich Volkmann <b...@volki.at> wrote:
>>
>> So if "destination" excludes off-wanderers and sightseers, what tag do you
>> use when you need to include them?
> 
> Yes/permissive under general.
> 
> If I am free to come up park my car for any reason and wander about, that is 
> pretty damn permissive.

Permissive would also mean that we are allowed to drive thru, at least
according to the tag definition in the Wiki. We need to stick to those
definitions, there's too much data based on them.

> I may be wrong, but the signage you are describing is very interesting to me 
> because in general it doesn't exist in the US. Usually private residential 
> streets (not driveways) are still access=yes/permissive unless there is a 
> gate (I lived adjacent to one w/o a gate), and parking on busy streets/ 
> neighborhoods is done with permits - but the road itself is permissive. 

Indeed there are huge differences between our countries. When searching for
translations of legal terms, I stumbled upon pages like
http://blog.al.com/breaking/2011/12/no_through_traffic_signs_in_ne.html.
This case would be unthinkable here in Central Europe. All fields of life
are excessively regulated. There are laws and road signs for everything.
There are all kinds of restrictions on public roads as well as on privately
owned roads. Authorities are imaginative not only at complicating rules, but
also when it comes to fining people. In the given example, they would put up
a proper traffic sign, and police would punish every driver who ignores it.

> If there is some sign that says "residents and people with business with 
> residents only" - that sounds an awful lot like access=destination. 

Well, it may sound like it, but it's really different from the other kind of
destination traffic.

Let's take this example:
http://map.project-osrm.org/?z=14=47.801914%2C16.184020=47.788565%2C16.178441=47.805574%2C16.160095=en
Assume we want to go fishing at the brook (Johannesbach). We probably need
to pay for it. In that case, we are in business with the owners, so we are
allowed to drive directly to the fishing spot. But if fishing is free, or if
we just want to hike along the brook, we are not allowed to drive in. We
need to walk 2,35 km to reach the brook. Or we drive 8 km all around the
forest (as the routing engine suggests) and still have 1 km to walk to reach
the brook. In any case, we lose a lot of time, and we'll be physically
exhausted.

But if the traffic sign said "except for local traffic" or "except for
destinations in the wood", we could legally drive directly to the fishing
spot, no matter what we are doing there.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 06.10.2015 21:41, Florian Lohoff wrote:
> Sorry - no - All of them are *=destination.

Don't be sorry. Think forward. Help find a name for the missing tag.

> If you include them? What would be the legal sign? I know
> of none. You can put up signs which say - "Redheads only on
> mondays" but thats nothing OSM could or should follow.

There are no redheads signs, because they would be discriminating.
There *are* signs for like "only on mondays", and there's an approved
tagging scheme for this:
http://wiki.openstreetmap.org/wiki/Conditional_restrictions

> Simplification - make it a permissive/private ...

Or reduce all access tags to yes or no.
That's not where OSM is heading to.
Tagging is getting more and more fine-grained.

>> In Austria:
> 
>> Fahrverbot + Zusatztafel "Zufahrt gestattet"
>   motor_vehicle=customer/destination/permissive/private depending
>   on use case

What use case? Do you suggest tagging for the renderer?

>> Fahrverbot + Zusatztafel "ausgenommen Ziele in..."
>   Do you have pictures of something like this?

Don't you believe me? I know for sure that I saw signs with that wording,
but I certainly have no photo. So believe it or not.

You can find similar signs here:
http://wandertipp.at/andreasbaumgartner/2008/07/01/durchfahrtsverbot-in-leopoldsdorf-unglaublich-aber-wahr/

>> "Durchfahrt verboten"
>   motor_vehicle=destination or vehicle=destination - depends on
>   what is beeing ment. Might also be a access=private. Varys 
>   on location and usage.
>> "Durchgang verboten"
>   access=destination?

Fine. You see that *=destination has a distinctive meaning.

> You need to accept simplification

Yet again, you are arguing towards access=yes/no.

> - there is NO WAY in the world we can
> accurately a) tag all ways with any combination of blurp and make b) all
> data consumers "do the right thing". 

We *can* do (a), your'e just lacking motivation. You won't get us forward
with such a mindset.

I do not care about (b), as that's not a tagging issue.

> A lot of signs in the countryside are complicated but are only
> interesting for locals e.g. the farm 500m away. Why should i tag this

I will answer questions like this when the RFC is out. At the present stage,
I need suggestions for the tag name. Please get back on the topic.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 06.10.2015 19:31, Florian Lohoff wrote:
>> So if "destination" excludes off-wanderers and sightseers, what tag do you
>> use when you need to include them?
> 
> Whats the possible signage which can induce that?

"no through traffic"
"no thru traffic"
"local traffic only"

In Austria:
Fahrverbot + Zusatztafel "Zufahrt gestattet"
Fahrverbot + Zusatztafel "ausgenommen Ziele in..."
"Durchfahrt verboten"
"Durchgang verboten"

The latter two are no traffic signs in terms of StVO, but they are valid
anyway due to other laws such as ABGB.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 06.10.2015 07:15, Marc Gemis wrote:
> And (Flemish) Dutch "aangelanden (verkeer)". 
> 
> We also have the difference between 
> "uitgezonderd plaatselijk verkeer" = "except destination"
> "uitgezonderd aangelanden" = "except 'visitor'"
> 
> and I even saw
> 
> "uitgezonderd bewoners" = "except inhabitants" 
> 
> once on a street.

I'm glad to see that the tag I'm going to propose will be useful for at
least one other country.

You can then use:
uitgezonderd plaatselijk verkeer ... vehicle=destination
uitgezonderd aangelanden ... vehicle=
uitgezonderd bewoners ... vehicle=private

> Wonder whether a moving or delivery company would be
> allowed in the latter case. Or whether someone would try to enforce it in
> such case.

I don't know Belgian law, but it might be similar to the situation in
Austria where "ausgenommen Anrainer" only means residents, no
moving/delivering companies. That caused lots of problems, because residents
wanted things delivered to their homes. That's why "ausgenommen
Anrainerverkehr" was invented, and many "...Anrainer" signs have been
replaced by "...Anrainerverkehr" signs over the decades. This process will
surely continue.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 06.10.2015 02:08, Georg Feddern wrote:
> Am 05.10.2015 um 12:01 schrieb Friedrich Volkmann:
>> Many people have been using (motor_)vehicle=destination for this, but that's
>> just wrong, because "destination" would mean that you are allowed to drive
>> in to take a walk or shoot photos.
> 
> Sorry, but your interpretation is wrong in my opinion - and "too literally
> translated".

As I already wrote in my reply to Simon, I do not know what translation you
are talking about. The sentence you cited does not contain a translation.

> "destination" can not be used as "you want to drive there" but as "you are
> allowed to drive there"

If I were allowed to drive there (without any condition), it would be
vehicle=yes.

>>   In exchange, "destination" would prohibt
>> residents from driving through - but they are actually allowed to do so.
> 
> Yes - but that's the very rare edge case Simon wrote about.
> Try to think about a router that would be able to handle this case - and its
> preconditions.

Thinking... Done.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 06.10.2015 08:47, Colin Smale wrote:
> Instead of trying to translate the words on the signs, why look at what the
> relevant laws say. There is only room on the sign for one or two words, but
> in the laws which define the signing there will/may be more detailed
> definitions of what is meant; these definitions will of course be
> country-specific.

Sadly enough, most people who participate in discussions do not even know
(or at least not fully understand) the laws in the own country, let alone in
foreign countries. That's why a list of country-specific equivalents cannot
be the target of a proposal. The proposal can only introduce a tag and its
definition, and it's up to the local communities to discuss what their
traffic signs mean and how they relate to the tag definitions.

> In NL there is "uitgezonderd bestemmingsverkeer" (except for destination
> traffic) which sounds clear, but these days there is also "uitgezonderd
> aantoonbare bestemming" (except traffic with demonstrable destination). The
> latter is not defined (yet) in law, but I guess it is an attempt to plug a
> hole in "bestemmingsverkeer" because it is not defined how you have to
> justify being "destination traffic."

The Austrian term "Anrainerverkehr" is not defined by a law either. But it
has been a topic in literature, official websites, court decisions, and
discussions in specific newsgroups and webforums. So there's now a common
understanding what the term means.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 06.10.2015 09:04, Marc Gemis wrote:
> And the Dutch/Flemish "plaatselijk verkeer" is better translated as
> "local traffic"; now what the hell is the (legal) definition of that?
> 
> Same as the Dutch bestemmingsverkeer I assume.

I wouldn't assume that.

> inhabitants, visitors, delivery, emergency, service + horses + bicycles + 
> foot.

If we can include horse-and-cart in that list, it perfectly matches the new tag:
motor_vehicle=visitors (or whatever we name it)

horse=yes + bicycle=yes + foot=yes are certainly implied by the road type.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 06.10.2015 10:35, Martin Koppenhoefer wrote:
> would you be permitted if you wanted to ask for hotel pricing? Or room
> availability?

Yes. Asking means contact, and that's what it is about.

> Many people have been using (motor_)vehicle=destination for this, but 
> that's
> just wrong, because "destination" would mean that you are allowed to drive
> in to take a walk or shoot photos. In exchange, "destination" would 
> prohibt
> residents from driving through - but they are actually allowed to do so.
> 
> 
> IMHO we should change the wiki to make this more explicit, because the
> German situation is similar, it isn't sufficient to want to go there (like
> the wiki currently states), but you have to want to come in contact with
> someone living there or operating his business there.

I am ok with explicitely stating in the wiki that access=destination does
*not* require contact with residents.

> "visitors" would exclude a lot of stuff, including residents. Also "visitor"
> implies IMHO you have to stay. Is the postman a "visitor"? I'd say no.

I don't know either. This is why I started this thread. What value do you
suggest?

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 06.10.2015 10:45, Simon Poole wrote:
> Your Anrainer vs. Anrainerverkehr example for AT doesn't seem to be any
> different than the Anwohner/Anlieger difference in DE, which
> semantically for routing purposes boils down to private/destination
> (which I suspect most routers wouldn't actually differentiate in any case).

It's *not* destination, see my other posts.
To put it more clearly:
"destination" targets a location, while Anrainerverkehr targets people.
You can also see it like this:
"destination" is about where you go, while Anrainerverkehr is about what you
wanna do there.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 06.10.2015 11:09, Colin Smale wrote:
> So to summarise, you are proposing a new value for access=*, which has some
> overlap with "destination", "delivery" and "private" (and others),

There is no overlap with "destination", although many mappers mix it up.
Of course there is overlap with "delivery" and "private" as the new value
will be a superset to them.

> whereby
> the distinction with the existing values can only be made clear by
> refererring to legal texts?

No, that's exactly what I want to avoid. The tag definitions should be
concise, clear and comprehensive, and any traffic signs or legal texts
should go to an examples section at best. We better leave it over to local
communities to discuss those.

> Maybe we can put a matrix in the wiki with the values down the left,
> "traffic classes" across the top, and "yes/no" in the cells?
> 
> Traffic classes would be something like:
> 
> * actual residents
> 
> * visitors to residents, with or without an appointment (including
> delivery/contractor traffic)
> 
> * visitors to residents, with pre-arranged appointment (including
> delivery/contractor traffic)
> 
> * residents of a side-road to the road in question (it may be the intention
> that the side-roads are accessed by entering the road in question from the
> other end)

This is another dimension, so the matrix would become 3-dimensional.

> * visitors to the road itself, not to a resident (e.g. intending to park the
> car and go for a walk)
>  
> 
> * anything else you can think of here?

In order to get the "designated" and "use_sidepath" values in, we'd need to
add a distinction whether the feature is designated, or whether a designated
sidepath is present. That adds one more dimension to the matrix. For
"discouraged" we'd need yet another dimension. So we can hardly get all
values in one matrix. I would prefer a tree structure, similar to how the
keys are documented at
http://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation. Of
course we can do both: a tree for all values, and a matrix for "difficult"
values.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 06.10.2015 11:29, Martin Koppenhoefer wrote:
> I wouldn't do that, but I'd rather make it the opposite way (state that
> destination does require contact).

That would change the meaning of the tag, and how would you tag "Zufahrt
gestattet" (or "Durchfahrt verboten" or "ausgenommen Ziele in ...") then?
This does not require contact.

> I'm not sure about the term "residents".
> Are these signs only found in areas which are "purely residential" (i.e.
> there are no offices if not inside residences and run by the resident, no
> shops, haircutters, agencies, ...)? Otherwise I'd include something
> referring to businesses.

Businesses are included, see my initial post.

> We should check if the currently described
> definition in the wiki for "destination" is correctly describing the
> situation for some place on Earth (some jurisdiction).

Destination is destination, the meaning of this word is obvious, and this
does not depend on some place on Earth.

> If yes we have to
> leave it as it is IMHO, and we'd have to retag a lot of stuff in Germany.

That's the problem of the Germans, and it's their own fault. I corrected the
mistranslation in the German wiki multiple times, and explained it to them
numerous times, to no avail.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 06.10.2015 11:58, Simon Poole wrote:
> Am 06.10.2015 um 11:29 schrieb Friedrich Volkmann:
>> ...
>> It's *not* destination, see my other posts.
>> To put it more clearly:
>> "destination" targets a location, while Anrainerverkehr targets people.
>> You can also see it like this:
>> "destination" is about where you go, while Anrainerverkehr is about what you
>> wanna do there.
>> ...
> As already pointed out multiple times you are translating far too
> literally.

As already pointed out multiple times, you still owe me an explanation what
translation you are talking about.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 06.10.2015 12:25, Martin Koppenhoefer wrote:
> Am 06.10.2015 um 12:10 schrieb Simon Poole
>> Anrainer seems to be clearly covered by private

Correct.

> "private" is "Only with permission of the owner on an individual basis"
> this is kind of vague, but from what it says literally it clearly doesn't 
> apply (because if it's a publicly owned road, the owner can neither permit 
> other people than residents to  use the road, while residents cannot be 
> forbidden to use it,

The owner (i.e. the commune) can extend or revoke the permission by
replacing the signs whenever they like.

> if this would be the meaning of "individual basis" it could just as well be 
> applicable to "delivery", Anrainerverkehr, ), there's not an individual 
> permission but a general one restricted to certain conditions.

The right is granted to registered residents, who are a strictly defined set
of individuals. Deliverers are not a strictly defined set of individuals.
Each of the 8 billion people on Earth can deliver something.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 06.10.2015 13:06, johnw wrote:
> Destination is very good, because it implies people who are going to a
> destination on that street/area. not free to roam around, not free to park
> and wander off. 
> 
> =Destination is for people *visiting* the destination the road services. it
> doesn’t matter the purpose - as long as their destination is one of the
> residences. Which excludes sightseers and shortcut-takers. 

So if "destination" excludes off-wanderers and sightseers, what tag do you
use when you need to include them?

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

[Tagging] new access value

[Friedrich Volkmann]

I intend to write a proposal for a new access=* value, but I don't know a
reasonable tag name. So I'm asking you for suggestions.

We need the tag for Austrian road signs labelled "ausgenommen
Anrainerverkehr" or "ausgenommen Anliegerverkehr", where "ausgenommen" means
"excepted" and "Anrainerverkehr" or "Anliegerverkehr" is the word I am
struggling to translate. These signs are mostly used in conjunction with [no
vehicles] or [no motor vehicles] signs.

There are similar signs in Germany and Switzerland, although there has been
some debate whether the terms mean the same thing. So I am primarily
considering Austrian jurisdiction by now. The Germans or Swiss can then
decide whether they use the new access value or not.

The meaning is a superset of
access=private/customers/delivery/agricultural/forestry. Everyone is
permitted to use the feature (road) if - and only if - he is either a
resident or owner of adjacent property or if he is aiming to get in contact
or business with a resident or owner.

So if you own the property beside the street, you are permitted to use the
street.
If you want to visit a resident for a talk, you are permitted.
If you are delivering to a resident, you are permitted.
Hotel guests are permitted.
If you want to visit a shop, you are permitted.
If you want to visit someone who turns out to be not at home, you are
permitted anyway because you could not know.

But you are *not* permitted to drive in if you just want to park your car
there and take a walk.
Or if you are intending to drive through without being a resident/owner.
Or if you want to shoot photos of the buildings, without visiting them.
Or if you do some mapping for OSM.

Many people have been using (motor_)vehicle=destination for this, but that's
just wrong, because "destination" would mean that you are allowed to drive
in to take a walk or shoot photos. In exchange, "destination" would prohibt
residents from driving through - but they are actually allowed to do so.

I have been using (motor_)vehicle=delivery, because it's more permissive
than private, and I always felt that delivery somewhat implies customers.
But it's not fully correct either, because pedestrian areas exist where
deliverers are permitted to drive in, while customers are not.

So we need a new tag.

Maybe *=visitors?
or *=guests (but this could make believe that deliverers are excluded)
or *=contact (puzzling?)
or *=contact_with_residents (too bulky?)
or *=contact_with_abutters (same)
or *=in_touch... ?

What do you think?

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] new access value

[Friedrich Volkmann]

On 05.10.2015 14:19, Simon Poole wrote:
> IMHO you are translating far far too literally and trying to infer a legal
> meaning from that translation creating an unnecessary and likely
> make-believe edge case.

I don't know what translation you are talking about, but this has been
exhaustingly discussed in the users:Germany webforum, and we'll be able to
discuss it again after the RFC, so please leave it aside by now and let's
focus on the new tag name.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Immigration, asylum, refugee centers

[Friedrich Volkmann]

On 24.09.2015 08:18, Warin wrote:
> I have 'synced' the wiki page
> https://wiki.openstreetmap.org/wiki/Tag:office%3Dgovernment with the Russian
> source page.
> It now reflects the use of the sub tag government= as documented on the
> Russian page.

Why does the yellow box say that the English version is a an out-of-sync
translation of itself?

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Delete not marked walking routes?

[Friedrich Volkmann]

On 20.09.2015 08:45, Pee Wee wrote:
> What do you think?
> 
> Is is OK to have (walking) routes in OSM that have no visible marks on the
> ground and if so under what conditions?

First of all, we need to distinguish ways and relations. A path may be
visible or invisible, and a route may be actually marked/signposted or not.
So there are 4 possible combinations. You certainly mean relations for
unmarked routes consisting of visible paths, but let's have a look at the
opposite combination first: A relation for a marked trail with some section
where no path is visible (e.g. crossing a meadow). If we map only what is
"verifyable on the ground", as was suggested in some answers, we must not
map invisible paths. So we'd end up with incomplete relations that are hardy
routable, and whose statistics (length, heigth profile, % paved, etc.) are
incorrect. That's why most mappers do map those route segments even though
they are not verifyable on the ground. But hang on - are they really not
verifyable? There's a marked trail going off one end of the meadow, and a
marked trail going off the other side of the meadow. So we do see that the
route crosses the meadow. We do not see the invisible path, but we see that
there *is* an invisible path. It is verifyable or not, depending on how we
think about it.

I recently mapped a climbing route that is invisible from start to end. But
is has been documented in climbing guides for decades. I was able to
identify the rocks, ravines etc. described in the books. So the route is
verifyable on the ground - but only in conjunction with the climbing guides.
If all of these get lost in a fire, the verifyability will also be gone. But
hey, that's the same for the names of peaks, ridges, valleys etc. There's no
sign "Mount Everest" on the peak of the Mount Everest. The peak is
verifyable on the ground, its name is not. We map the names because they are
common knowledge. The climbing route I mapped has been common knowledge as well.

A hiking route suggested in one single book by one single author can hardly
be considered common knowledge, especially if the the route is just a
combination of paths that were already known before. That kind of routes do
not belong in OSM.

I should also mention that I did not create a relation for the climbing
route mentioned above. I just mapped the highway=path. Why would we need a
relation if the route is not marked, and all the other tags can be set on
the ways directly? Looking at the relations I found via your first link
(rel-id 2099391, 4108560), I wonder what tags are supposed to justify a
relation. What do ref=*, name=*, colour=* etc. mean when the route is
neither marked nor signposted in situ? Is ref=4b the page number in the
book? Is name=PP_5 the chapter in the book? Is colour=aqua the colour in the
book? What about isbn=978-2-930488-18-9? A route cannot have an ISBN. So
that's obviously the ISBN of the book. This is cleary a misuse of OSM. OSM
is a database for geographic data, not a book index. These relations need to
be removed, there's nothing to discuss about that.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] [OSM-talk] Proposed mechanical edit: surface=soil to surface=dirt

[Friedrich Volkmann]

On 01.09.2015 10:38, Anders Fougner wrote:
> My proposal in case someone wants to help beginners with the surface tag:
> *Illustrate* the surface hierarchy somewhere in the OSM wiki (e.g. at
> ).
> Right now the hierarcy is not illustrated, it is just in two tables (unpaved
> and paved). An illustration works better, and the hierarchy can have more
> than two levels.
> 
> Place surface=paved and surface=unpaved at the top, surface=ground etc on
> the next level and probably surface=wood, clay, mud, etc. at the bottom.

It's similar to the access hierarchy, so we could illustrate the tree in the
same way.

However, be aware that the more levels you create, the more likely we'll
encounter the multiple-parents problem. E.g. when we declare a group for
natural surfaces and one for artificial surfaces, then we need to put gravel
and sand into both groups, which makes it too complicated.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] [OSM-talk] Proposed mechanical edit: surface=soil to surface=dirt

[Friedrich Volkmann]

On 31.08.2015 12:41, moltonel 3x Combo wrote:
> If you do want to consolidate tags, "earth" is a much better synonym
> of "soil" and you should probably use that instead.

It's not a synonym either. The wiki said for years that surface=ground is
"probably the same as surface=ground", and now it incorrecty states that it
is "a duplicate of surface=dirt". So this surface=earth tag is totally
spoiled by bad definitions, whereas the meaning of surface=soil is obvious.

Additionally, I consider soil to be soft, whereas earth may be denser
(compacted or containing stones).

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] [OSM-talk] Proposed mechanical edit: surface=soil to surface=dirt

[Friedrich Volkmann]

On 31.08.2015 11:51, Christoph Hormann wrote:
> On Monday 31 August 2015, Mateusz Konieczny wrote:
>> See
>> http://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny
>> /surface%3Dsoil_to_surface%3Ddirt
>>
>> I plan to change surface=soil to surface=dirt. surface=soil is a
>> clear duplicate of surface=dirt. It is also less popular and
>> undocumented on http://wiki.openstreetmap.org/wiki/Key:surface .
>> surface=soil usage is slowly increasing and recently passed threshold
>> of 400 entries worldwide. It would be a good idea to retag it to
>> already documented tag before this duplicate gets more popular.

This is nonsense. The fact that this tag is getting popular without editor
support proves that there's good reason for this tag. This is a different
issue than woodchip/woodchips or customer/customers, which only differ by
spelling.

> I would be careful here - 'dirt' is essentially a very vague term which 
> probably originates from the concept of 'dirt roads' here.  'Soil' in 
> the other hand is fairly precise, see
> 
> https://en.wikipedia.org/wiki/Soil

I agree. Soil is not dirt. That's why I have used surface=soil myself, and I
will revert any automated edit of such kind.

> In general i think surface=ground is the most sensible tag for tagging 
> ways that are just established somewhere without notible construction 
> work when you can't be more specific - it implies that the way surface 
> is essentially the ground there in its natural state.

Yes, and surface=soil is a subset of surface=ground, which in turn is a
subset of surface=unpaved.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] waterway=derelict_canal

[Friedrich Volkmann]

On 27.08.2015 13:51, Andy Townsend wrote:
 On 27/08/2015 12:15, Friedrich Volkmann wrote:
 There's no point in a disused:foo=bar namespace. That's either historical
 mapping or hiding from the renderer, both of which are wrong in OSM. 
 
 Er, no.  A disused:amenity=pub is something that still exists in its own
 right; it's a building that was a pub, is still a building, is probably
 still usable as a navigational aid

That's why the building=* tag stays in place, and you may leave the name
there as well (particularly when it serves as a navigational aid), just drop
the amenity=pub tag.

With disused:amenity=pub you may get in trouble. What if it was a pub at one
time, a nightclub at another time and a restaurant at yet another time?
Maybe it still looks like a nightclub, although it was used as a pub lately.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] waterway=derelict_canal

[Friedrich Volkmann]

On 26.08.2015 15:16, Chris Hill wrote:
 No, a pub that is closed is simply not open for business until it reopens
 the next day. A pub that is disused is no longer a pub.

What about a pub that is closed for 2 months? What's the limit? Anyway, we
have two points of view:

1) It's still a pub. In that case, use the amenity=pub key with adequate
attributes.

2) It's no more a pub. In that case, just delete the amenity=pub tag.
There's no point in a disused:foo=bar namespace. That's either historical
mapping or hiding from the renderer, both of which are wrong in OSM.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] waterway=derelict_canal

[Friedrich Volkmann]

On 24.08.2015 22:49, Chris Hill wrote:
 I think that 'disused=yes' is a dangerous tag and should be avoided.
 
 Suppose someone uses foo=bar + disused=yes. Someone else searches for
 foo=bar, he will find the objects with and without disused=yes.

That's fine, because disused objects are still there, so they need to remain
retrievable. A disused church may still retain its frescos, a disused adit
may still be visited by chiropterologists, a disused track may still be
usable for tractors and hikers, and a disused canal may be used by bathers
or fishermen, or at least it is still a barrier.

disused=yes is an important tag, used on 46K objects. When someone is
searching for a boat passage, he needs to filter out all disused=yes just as
he does with access=no, boat=no, widthwidth_of_boat, intermittent=yes,
start_date in the future, etc.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] landcover=trees definition

[Friedrich Volkmann]

On 17.08.2015 00:29, John Willis wrote:
 This is the crux of the landcover argument. 
 
 Because landuse=* implies what the land is used for - therefore man-altered 
 and decided usefulness.  natural=* was then interpreted by taggers to be the 
 opposite - the natural state of the land which was heavily influenced by 
 the landuse=forest /natural=wood debacle. 
 
 Landcover=* just says this is here , without adding implications as to its 
 use or origin.

I know what you mean, but you are missing the point that landcover is
layered. This his here applies to bedrock, ground water, soil, surface
water, vegetation (root layer, moss layer, herb layer, shrubs layer, tree
layer), and air. So we need multiple keys to specify them all. Or we just
consider one of these layers, but this needs to be clearly defined.

We already have tags for certain layers, such as surface=*. Unfortunately,
that key is spoiled by surface=grass which means another layer. This would
better go to a vegetation related tag. The most common tag for vegetation is
natural=* - which in turn is even less clean because it covers surface,
water and landforms as well.

Let's not make the same mistake again with landcover=*.

One solution could be a landcover:* scheme instead of a single key. Say,
landcover:surface=* for earth/sand/mud/rock/concrete/asphalt/etc. Then some
vegetation tags:
landcover:vegetation:moss=yes/no/percentage
landcover:vegetation:herbs=yes/no/percentage
landcover:vegetation:herbs=yes/no/percentage
landcover:vegetation:shrubs:=yes/no/percentage
landcover:vegetation:trees=yes/no/percentage
(with percentage = 100 * covered area / total area, so the sum of the
percentages possibly exceeds 100)

as well as
landcover:vegetation:herbs:height=0.2
landcover:vegetation:shrubs:height=1.5
landcover:vegetation:trees:height=10

This would enable nice 3D rendering.

 This also would allow for some man-made landcovers; as several times i am 
 dealing with a place where concrete or asphalt is covering the ground, but 
 not as road or path or building. This is a weaker use case, but it would be 
 nice to say here is 2000sqm of concrete. It is the remnant of an old 
 airport. The airport is gone, it is not a road, a building or a structure. It 
 is now a (currently) purposeless expanse of concrete. Currently I have to map 
 it as the negative space surrounded by other things (meadow) to leave the 
 impression something is there (NAS Alameda in San Francisco is a perfect 
 example: 
 https://www.google.com/maps/@37.7813303,-122.3170894,16z/data=!3m1!1e3 part 
 of it is now roads, tracks, or other facilities, but it is an abandoned 
 airport where most of the feature has no use nor is natural).

We can map the area of a highway as either highway=xxx + area=yes, or
area:highway=xxx. If it is no more in use, we can add disused=yes or
abandoned=yes. We can use a similar approach for abandoned airports. I've
also seen some abandoned primary highways tagged as highway=track, because
they can still be used as tracks. This would also work for abandoned airport
runways. All in all, we've got plenty of possibilities.

Of course, if you just want to store the information that there is an area
sealed with a layer of concrete, some simple surface=concrete would be more
to the point.

 Grass along the sides of manicured roads (like on a cutting or separation for 
 safety or noise control), which are part of the roadway's land, but not part 
 of the road - nearby residential houses, but not part of a residence nor used 
 as a park - its there just to be grass. 

We've got landuse=grass for that.

 Landcover=iceplant would be brilliant for southern California freeway mapping.
 
 Its not used for anything other than being iceplant- occasionally a car 
 will go in it, but it's job os just to be there so the ground isn't dirt or 
 dead meadow grass. Sounds like a landcover to me.

Or landuse=flowerbed and possibly species=Mesembryanthemum crystallinum.

 If I had landcover=trees with a boundary  line like nature reserve, I 
 wouldn't have to decide between wood and forest, when it is a bit of both.

I agree that the forest/wood distinction causes headaches, yet both are more
than just a cluster of trees. I wouldn't oppose landcover=* as much if the
suggested tag für forests/woods were landcover=wood.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] landcover=trees definition

[Friedrich Volkmann]

On 16.08.2015 09:06, Martin Koppenhoefer wrote:
 I'm not very good at refraining from replying to trolls, but I think this 
 time I have to do it...

This is not the first time you refrain from replying when it comes to a
definition of your landcover=* key. You simply have not managed to make up a
definition for years, so whenever I ask you for a definition, you hide out,
waiting for another opportunity to advocate your key, then playing the same
game again and again.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] landcover=trees definition

[Friedrich Volkmann]

On 16.08.2015 04:00, Daniel Koć wrote:
 http://wiki.openstreetmap.org/wiki/Landcover

There is no definition of the landcover=* key. The page features a wide
range of keys including amenity=* and tourism=*.

Even if there were a definition, it would be the wrong place. The definition
belongs to the proposal (Proposed_features/landcover) and/or feature page
(Key:landcover).

 Somebody has just suggested that one should tag the lawns as landuse because
 everything is use, so this key can be stretched too.

Not everything is use. E.h. hazard=* is rather the opposite of use. Most
natural=* features denote what's there, not how it is used. Well, you *can*
use a swamp, but if you don't use it, it is a swamp anyway, so this is
really independent of use.

 Of course this is not a substitute for the forest and I try to be clear that
 I don't like it to be used as a general type.
 
 If you know it's a forest, you should tag it accordingly (once we have
 definition again). But if all you know is there are some trees, you don't
 know if there are all these things, so you can safely tell only about what
 you know, hence landcover=trees is what you really know.

I have a feeling that this landcover=* thing aims mainly at armchair mappers
who map from arial images but don't know how to interpret them because they
have never been outside. So they cannot distinguish urban lawns from rural
meadows, or meadows from heaths, or orchards from parks or gardens. But they
can distinguish trees from no trees. So they use landcover=trees where they
see trees, and landcover=grass where they see no trees. I came across areas
which were tagged landcover=grass although they were mostly covered by
buildings.

 If you cannot decide between landuse=forest and natural=wood, take either
 one. Just like picking a tracktype.
 
 Last resort in case of doubts should be something more general, even
 partially, not rolling the dice! Of course that's what people do now, but
 we're discussing here to help them avoid such wicked games with database.

When picking a tracktype you have to roll a dice as well. There's no clear
line between grade4 and grade5 definitions. When in doubt, you have to
choose one randomly. It's still better than omitting the tracktype, because
grade4 and grade5 are on the same end of the scale, so this bears useful
information.

Same for forest/wood. There's no clear line between their definitions, it's
a pity that we have two first-level tags for them in the first place.
Anyway, they are also very similar to each other, and very different from
other tree-covered areas (such as avenue trees). So it's fine to pick one
of forest/wood, even if it turns out later that the other would be more
correct. The tags in the database are not graved in stone, we can correct
mistakes at any time. After all, we have not a single faultless object in
the entire OSM database. All of the coordinates are inaccurate to some
degree. Mapping is not an act of collecting faultless data, it's a process
to continuously improve the data.

 Your questions about what lancover really is made me read the wiki and it
 seems it's just a twin for surface, which is meanwhile also used to
 indicate the surface type of larger areas, like for a Landuse but is
 generally used as a secondary tag.
 
 This means more or less that maybe surface=trees would be good, however
 people use it very infrequently and I don't know if it is primary or
 secondary tag then:

I agree that landcover=* strongly sounds like surface=*, but we can hardly
compare them as long as there's no definition for the landcover=* key.

There's nothing wrong to use surface=* for areas, but due to its original
use it still describes the surface at ground level. Surface=trees would be
strange, because a barely visible path in the forest typically has the same
surface as its surrounding area, which would imply surface=trees on the path.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] landcover=trees definition

[Friedrich Volkmann]

On 10.08.2015 12:29, Jean-Marc Liotier wrote:
 A pity - I just happen to have a problem that this proposal would solve...
 Take a look at this charming corner of Normandy: http://binged.it/1ht3p7v
 
 On the left, a dense urban location that is clearly landuse=residential. On
 the right, what is most definitely landuse=meadow. So what about the center
 ? We see residential buildings among a predominantly grass cover.

What exact area are you referring to? If it's about lawns within residential
areas, you can nest landuse objects (i.e. a landuse=grass within a
landuse=residential). If it's about houses surrounded by large meadows, you
can us multipolygons to except the houses from the meadows. In any case,
every single spot in that region has at least one use, so you'll be able to
assign a proper landuse=* tag.

 To me, it seems that mapping this area as a combination of
 landuse=residential and landcover=grass would be most fitting.

landcover=grass does not fit, because the lawns do not only consist of
grass, but also of dicotyledons, insects, mosses, algae, fungi, etc. The
landuse may be grass, but the landcover isn't just grass. Not to mention the
buildings, roads, footpaths, parked cars etc.

 I have
 thought about using the landuse=residential + natural=grass combination
 instead, but those lawns do not strike me as natural.

Therefore it's landuse=grass.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] landcover=trees definition

[Friedrich Volkmann]

On 16.08.2015 01:24, Martin Koppenhoefer wrote:
 grass isn't a use, landuse=grass is nonsense.(IMHO)

Why, the land is used to grow grass. Thus, landuse=grass.

 landcover=x doesn't mean there is only x, it says the area appears as covered 
 with x

That depends on observation time. E.g. much of Europe is covered by fog in
Autumn. So this will be landcover=fog.

It also depend on the observation point. When you see arial images, forests
appear to be covered by trees. But when you are inside a forest, you see
more herbaceous plants than trees.

 and x might also imply other stuff that has to do with x, like microorganisms 
 living in the grass, or soil on which the grass grows, etc
 grass might even imply grass like plants (this has still to be defined)

So go on and define these implications in your proposal. Currently, no
implications exist.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] landcover=trees definition

[Friedrich Volkmann]

On 03.08.2015 00:55, Daniel Koć wrote:
 I have just discovered that while landcover=trees has no Wiki page, it's
 quite established tag (I wouldn't say popular here, because it's just
 about 1% of forest/wood uses) and we could officially define as a generic
 tag for trees areas, when it's not clear for the mapper if it's natural or
 not (forest vs wood).
 
 Do you agree with this idea?

No, because the landcover=* key is just nonsense. There is no definition for
that key. What does landcover mean? Vegetation? Soil? Atmosphere? Buildings?
Ocean? Everything we map is landcover in some respect. You could use
landcover=motorway instead of highway=motorway, and landcover=playground
instead of leisure=playground. The landcover key matches all and nothing.

Furthermore, landcover=trees cannot serve as a substitute for landuse=forest
or natural=wood, because forests/woods not only consist of trees, but also
of shrubs, herbs, fungi, mosses, lichens, algae, animals, water, soil,
gases, and diaspores.

If you cannot decide between landuse=forest and natural=wood, take either
one. Just like picking a tracktype.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Multiple values with semicolons (was: Voting - Blood donation 2)

[Friedrich Volkmann]

On 20.07.2015 10:55, Marc Gemis wrote:
 On Mon, Jul 20, 2015 at 10:32 AM, Ruben Maes ruben.mae...@gmail.com
 mailto:ruben.mae...@gmail.com wrote:
 
 He proposes to use a semicolon-separated list, e.g.
 donation:compensation=payment;vouchers.

There is also a third option: Dropping the pure donation:compensation key in
order to just use donation:compensation:something=yes/no. This would be
consistent without a need for semicolons, although I prefer the semicolon
values anyway because they come with shorter keys.

 1) For me the major problem is when you try to further specify the
 semi-colon separated values.
 E.g amenity=pub;hotel, how do you specify different opening hours for the two 
 ? 

That has nothing to do with semicolons. It's a general problem with tag
combinations. Say, if you use pub=yes + hotel=yes, you still cannot specify
different opening hours. Same thing with amenity=pub + tourism=guest_house.
The only solution is to split the object (e.g. 2 separate nodes).

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

[Tagging] oil binding agent?

[Friedrich Volkmann]

I am looking for the English term for granulate that is made to absorb oil
that was spilled due to a leak or a vehicle accident and threatens ground
water. The granulate is often stored in boxes along forest tracks in water
protection areas. In Austria, the boxes are labelled ÖLBINDEMITTEL, which
is the German word for the substance.

Dictionaries return oilbinder, oil binder, oil binding agent and oil
absorbent, but some of them seem to be used for cooking, which is not what
I mean.

In any case, this certainly belongs to the emergency=* key, e.g.
emergency=oil_binding_agent. But amenity=* might also be ok.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Feature Proposal - Voting - Grave

[Friedrich Volkmann]

On 09.07.2015 13:49, Martin Koppenhoefer wrote:
 are you aware of the key tomb?
 http://wiki.openstreetmap.org/wiki/Proposed_features/tombs

This is just a draft. It should be marked as abandoned, as you have not made
an RFC for 4 years.

 and historic=tomb

This has never been approved. The main tag may be in use, but the tomb=*
subtags are not, except for tomb=tombstone (which according to the page is
deprecated, although it does not refer to any decision to deprecate that).

 the tag grave=cenotaph that you propose is in contradiction with your 
 definition.

You already pointed that out on 2015-02-05 12:59. There was no answer.

One other issue is that grave=yes is supposed to be used as a main tag. It
is very uncommon to have yes values in a main tag. There should rather be
a *=grave main tag with an optional grave=* subtag.

No doubt that we need a tag for graves, but it seems to me that both
proposals went seriously wrong.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] access=student and entrance=inter-building: comments?

[Friedrich Volkmann]

On 08.06.2015 08:52, johnw wrote:
 A month or so ago, new entrance=types came up, and I thought I had a couple
 new values for entrance. I’ve been thinking about them, and had these two
 ideas. 
 
 Please comment on both. 
 
 
 1) 
 Access=student - access designated for students of a school/facility,
 similar to customers of a shop or visitors of a facility. Does not imply age
 or gender, though it is used at mostly at K-12 facilities. For use with
 entrance=* or possibly with certain school amenities (Locker rooms,
 bathrooms, bicycle parking). 

Why not a more generic value like access=attendee? This could also be used
for parking places designated for conference, sports or church attendees.

We are also still missing a value representing a superset of
delivery/guests/employees/customers/students/etc. I mean all that are
involved in the facility in some way. In German speaking countries, many
roads are designated for Anliegerverkehr or Anrainerverkehr, which means
all persons who intend contact to abutters. This differs from
access=destination, which also includes people who intend to just walk
around, and on the other hand excludes owners driving through.

 2)
 entrance=inter-building - an entrance that is designated for only moving
 between buildings in a facility, even if physically accessible from outside.
 Usually on the ends of an outdoor walkway considered “indoors because of
 cultural custom rather than physical access restriction (IE: indoor shoes
 required). Not to be used on normal outdoor pathway entrances.

The term inter-building seems too narrow to me. I guess you could also use
the entrance to have a cigarette, then return to the same building. Some
smoking areas or terraces are not connected to another building at all.

We could think about some access=* tag like access=checked-in, but this
would get us to mapping processes instead of geographical data. I think that
specifying one entrance=main is sufficient for everyday needs. Those who are
familiar with the facility already know which entrance when to use, and
those who are not should head to the main entrance.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] How to tag a Driver and Vehicle Licensing Agency (US:DMV)

[Friedrich Volkmann]

On 08.06.2015 16:48, Andreas Goss wrote:
 https://en.wikipedia.org/wiki/Driver_and_Vehicle_Licensing_Agency

office=government
name=Driver and Vehicle Licensing Agency
short_name=DVLA

 https://en.wikipedia.org/wiki/Department_of_Motor_Vehicles

office=government
name=Massachusetts Registry of Motor Vehicles
short_name=Registry of Motor Vehicles

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Feature Proposal - Voting - admin_title=*

[Friedrich Volkmann]

On 10.05.2015 22:48, Eugene Alvin Villar wrote:
 Then there should be an effort to standardize the possible values of
 designation=* when applied to administrative entities. I think your current
 proposal is a good time to discuss that.

The resulting standardized tags would need to be included in the
http://wiki.openstreetmap.org/wiki/Key:designation page, making that page
even more confusing than it already is.

 Do you have any proof that application developers will not implement it,
 other than just personal conjecture?

That's my experience with OSM for 5 years, and with IT for 25 years.

Routing developers have not implemented the tables given on
http://wiki.openstreetmap.org/wiki/Speed_limits#Country_code.2Fcategory_conversion_table,
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed and
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions
for years even though some of them they get payed. They also did not
implement routing over areas although it is a trivial task.

The most important application to incorporate the designation=* or
admin_title=* key would be Carto, because that's what people get to see when
they try out OSM or when an OSM map is included within another site. Carto
is optimized for speed. Changes in data are immediately queued to be
rendered. There is no preprocessing. I know of no wiki table ever
implemented in carto. That would require continuously keeping the
implementation up to date. Who is supposed to do that? Only a few people
have a commit privilegue. And those are reluctant to do anything. I made
lots of comments and suggestions in their bug tracking systems, both old and
new, and none of my suggestions was ever implemented. When I asked them for
their criteria what features to render, they did not give me an answer. How
do you think you get them implement a conversion table and keep it up to
date? I bet you will not even try.

 And as I said before, such automatic
 replacement, if wrong, is not a catastrophic problem.

Maybe not catastrophic, but it is wrong, and I will not write a proposal for
something of which we already know beforehand that it is wrong.

 If a tag
 such as designation=* when applied to administrative entities were to be
 widely and consistently applied, and the documentation on the wiki is clear,
 then developers will find value in supporting such tables.

According to Andy Allen (Gravitystorm), who seems to be the owner of
Carto, this is absolutely not how we decide what things to render.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

[Tagging] Feature Proposal - Voting - admin_title=*

[Friedrich Volkmann]

On 17.12.2014 16:25, I wrote:
 This is about a new attribute for administrative devisions.
 
 http://wiki.openstreetmap.org/wiki/Proposed_features/admin_title

So far there were 3 alternative suggestions, which all have their drawbacks:

1) official_status: It remains unclear what the prefix means (country code?
language code?) and why it is needed, see my entry from 29 December 2014
17:33 on the talk page.

2) designation: contains machine readable values instead of human readable
values, see my entry from 23 December 2014 12:51 on the talk page. A
proposal with machine readable values was already voted down
(http://wiki.openstreetmap.org/wiki/Proposed_features/Designation).

3) admin_centre role: I don't see that purpose documented anywhere, and it
does not work for all countries, see Zverik's entry from 18 December 2014
15:21 on the talk page.

There's no more activity on the talk page, nor is here, so the only way to
get this issue forward is by starting the voting phase, which is what I am
doing now. Anyone who still prefers one of the alternatives will hopefully
come out of the woodwork and append to the discussion.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Feature Proposal - Voting - admin_title=*

[Friedrich Volkmann]

On 10.05.2015 10:38, Eugene Alvin Villar wrote:
 I prefer designation=* since it it already a widely used tag that fits the
 intended purpose of the proposed admin_title=* tag. The question on whether
 the value should be human-readable or machine-readable can be solved by
 using correspondence tables to link the two. Barring such a table, I don't
 see a catastrophic problem in automatically converting civil_parish to
 Civil Parish and vice versa, to use the example in the talk page.

designation=* is widely used (193 293 times), but look at the values in
taginfo. The only relevant value is civil_parish (3346 times). All other
values are just a mess.

The automatic replacement of underscores and lowercase initials with blanks
and uppercase initials would be easy, but no application developer will
implement it, and the uppercase initials may be wrong in some cases.

It would also be easy to put a conversion table in the wiki, similar to the
tables we already have for implicit maxspeed and access values by highway
type and country. But again, application developers will ignore those tables.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] RFC - Criteria for taging as either via_ferrata or path

[Friedrich Volkmann]

On 24.04.2015 11:01, Richard Z. wrote:
 On Fri, Apr 24, 2015 at 04:27:23AM +0200, Friedrich Volkmann wrote:
 On 24.04.2015 02:16, Warin wrote:
 Via ferrata should not be lumped into path or footway .. they are very
 significantly different and cannot be used in place of a path or footway.
 Would you take a 3 year old along it?

 Did you read the discussion tab? Farratas are not more difficult nor more
 dangerous than other paths. Where there's a ferrata and a parallel unsecured
 path in the same terrain, I would take the 3-year-old along the ferrata.
 
 so are you happy that this
   
 http://www.bergsteigen.com/klettersteig/trentino-suedtirol/gardasee-berge/ferrata-rino-pisetta
 is tagged as highway=path ?

Yes.

Of course I wouln't take a 3 year old along that ferrata, but I wouln't take
a 3 year old to that whole area at all. I know of a ferrata
(Frauenluckensteig) of difficulty B where average 10-year-old childs are too
short to reach the next rung. One hiking path called Reißtalersteig is even
easier (A) and you wouln't call it a ferrata, but one rung is hard to reach
even for adults, so people put a pile of stones on the ground to reach that
rung.

Children or bad weather make every path more difficult and dangerous, not
only ferratas.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] RFC - Criteria for taging as either via_ferrata or path

[Friedrich Volkmann]

On 24.04.2015 05:02, Warin wrote:
 The essence of a modern via ferrata is a steel cable which runs along
 the route and is periodically (every 3 to 10 metres (9.8 to 32.8 ft))
 fixed to the rock.

So you certainly agree that this is safer than an unsecured path.

Nevertheless, a ferrata cannot be defined by the cable, because not all
ferratas are that modern. E.g. the Wildenauersteig has no cable but rungs.
Some ferratas have chains instead of cables because the chains do a better
job withstanding rockfall, and they provide a better grip.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] RFC - Criteria for taging as either via_ferrata or path

[Friedrich Volkmann]

On 24.04.2015 02:16, Warin wrote:
 Via ferrata should not be lumped into path or footway .. they are very
 significantly different and cannot be used in place of a path or footway.
 Would you take a 3 year old along it?

Did you read the discussion tab? Farratas are not more difficult nor more
dangerous than other paths. Where there's a ferrata and a parallel unsecured
path in the same terrain, I would take the 3-year-old along the ferrata.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] RFC - Criteria for taging as either via_ferrata or path

[Friedrich Volkmann]

On 23.04.2015 11:59, Richard Z. wrote:
 there were ongoing discussions concerning this subject so
 I have ammended the wiki:
 
 http://wiki.openstreetmap.org/wiki/Proposed_features/via_ferrata#Criteria_for_taging_as_either_via_ferrata_or_path

 use highway=via_ferrata where people commonly use ferrata kits

This is an individual decision. I know someone who did all ferratas
(difficulty A-E) in eastern Austria without a ferrata kit. I also saw people
using a ferrata kit on an easy ladder, and on a short wire rope that is
meant as a handrail.

There are ferratas which are more than hundred years old. Nobody used
ferrata kits back then, because they simply did not exist.

 a path is way where a hiker can walk without a ferrata kit and without 
 extensive use of arm muscles

See above. What's an extensive use? Experienced climbers will tell you
that they do it all by technique instead of muscle power.

 a path should be safely passable without a ferrata kit even in less than 
 optimal weather

So we need to delete all paths in high mountains, because they are neither
ferratas nor safely passable when icy.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Way inside riverbank

[Friedrich Volkmann]

On 14.04.2015 15:59, moltonel 3x Combo wrote:
 Changing topics, I've just stumbled on the wiki on the natural=water,
 water=river tagging that I wasn't aware of and is supposed to replace
 waterway=riverbank. 4 years after being approved, it still
 represents only about 3% of the riverbank tagging. I guess that the
 it's more uniform and logical argument wasn't compeling enough, and
 that tagg...@osm.org != osm community...

I offer you another explanation:
Validator developers may have missed that voting, and therefore they did not
implement a deprecated warning.

Editor support for the new tags may be missing too. (I don't know, because I
use an editor where all tags have to be typed in manually.)

It's not documentation that helps spread new tags. It's editors and validators.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] inuse, defacto

[Friedrich Volkmann]

 On Fri, Apr 17, 2015 at 12:54 PM, Friedrich Volkmann b...@volki.at wrote:
 I recently came across a never proposed tag with some 600 uses marked
 de-facto. If that's the way to bypass the proposal process, I will
 never care about proposals any more.
 
 How do you know there was any intent to bypass the proposal process ?
 Tags can reach widespread use without ever having been discussed or
 documented.

There were no 600 uses when the page was created.

 Somebody documenting this in a de-facto proposal after
 the fact is a good thing.

Not when I had just started a topic called Status on the discussion page.
The user who changed the status to de-facto did not even reply to that topic.

And do you think that 600 is de-facto?

 I will set all the tags I invented to inuse
 as soon as I used them once, and to defacto as soon as I used them
 twice, because 2 uses are widespread compared to 1.
 
 There's obviously some threshold where it's reasonable. Don't mock
 using an extreme value, it just devaluates your good argument.

As a software developer, I use to consider extreme values. And being
somewhat into mathematics, I use to choose the easiest solution for given
parameters.

So you find the 1 / 2 thresholds too low? That's something to start with.

So far we have 3 parameters: number of OSM objects, number of real-word
objects, number of users. Let's put them into a formula in order to enable
objective decisions and avoid edit wars.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Feature Proposal - RFC - trailhead

[Friedrich Volkmann]

On 16.04.2015 06:25, Dave Swarthout wrote:
 But I'd be willing to bet that most trails are not part of a network of
 other trails or a route but are stand-alone. The trails I once hiked in the
 Adirondack Mountains in New York State all have names and trailheads but,
 with a couple of exceptions, are not part of any route. I think the mixed
 approach is best. If a given trail is part of  a larger system of trails, or
 the area where it begins has related amenities, then the relation idea makes
 sense. Otherwise, keeping it simple with a named trailhead node where the
 transition from highway to footway takes place will suffice.

Without a relation, how can applications determine which trail the trailhead
belongs to? Is it all about rendering the trailhead icon?

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Defacto: man_made=storage_tank

[Friedrich Volkmann]

On 15.04.2015 11:54, Martin Koppenhoefer wrote:
 People put building=* on any structure 
 
 +1, and I am fine with it, just wanted to comment on not all tanks are
 buildings and point out that in OSM all structures are buildings.

Bridges? Masts? Fences? Rails? Flagpoles? Power lines?

Maybe everything that looks like a building, smells like a building and
behaves like a building, but not all structures.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Feature Proposal - RFC - trailhead

[Friedrich Volkmann]

On 14.04.2015 23:32, Gmail wrote:
 role=start is used for crosscountry ski routes relations.

I like the idea to include trailheads as members of route relations.

It's a more versatile approach than highway=trailhead.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Fuel shops

[Friedrich Volkmann]

On 23.03.2015 15:11, Martin Koppenhoefer wrote:
 2015-03-23 14:55 GMT+01:00 Friedrich Volkmann b...@volki.at
 mailto:b...@volki.at:
 
 Ok, if it's only 2 or 3 liters, it's not really a fuel station, but 
 rather a
 shop=car_parts.
 
 
 
 2 liters of fuel are as much car_parts as a bakery is bicycle_parts.

The definition says: A place selling auto parts, auto accessories, motor
oil, car chemicals, etc.

That fits perfectly.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Fuel shops

[Friedrich Volkmann]

On 23.03.2015 11:02, Dave Swarthout wrote:
 An amenity is something the /general public/ might like or use or want to
 visit. These little shops are definitely not that. They sell small
 quantities of fuel, usually 2 or 3 liters, to local motorcycle drivers.

That's why the general public might like to visit these shops - or any other
fuel station.

Ok, if it's only 2 or 3 liters, it's not really a fuel station, but rather a
shop=car_parts. Anyway, we don't need to invent a new tag.

 And
 the Wiki's definition of shop is: A place selling retail products or
 services.  Too brief perhaps but it does allow for a wide range of additions.

Cafes, restaurants and theaters sell retail products or services as well.
You can use either of the amenity=* or shop=* keys, you just need to stick
to it.

 Meanwhile, until the renderers get smart, people are going to travel to
 these shops hoping to fill up their SUVs. This is exactly what I'm trying to
 avoid. I do not see why there is so much resistance to adding another value
 to the shop keys in existence. There are some pretty strange special values
 out there:
 shop=bag
 shop=e-cigarette
 shop=fashion  (??)

One evil cannot justify another evil. I never set the shop=fashion tag,
because it's just a useless synonym for shop=clothes.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Proposal : Move smoking tag to active status

[Friedrich Volkmann]

On 21.03.2015 01:54, Bryce Nesbitt wrote:
 Any objection to moving:
 http://wiki.openstreetmap.org/wiki/Proposed_features/Smoking
 because it is heavily used and obviously well established.

I object. The feature page should document actual usage, and actual usage
differs from proposed usage. smoking=outside is the second most common value
and 15x more abundant than the proposed smoking:outside=yes. By the way, I
find the proposed tag smoking:outside=separated ridiculous because you
cannot separate air masses outside.

The proposed keys smokefree=* (65 objects) and smoking_hours=* (14 objects)
should also be removed from the feature page.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Fuel shops

[Friedrich Volkmann]

On 20.03.2015 00:48, Warin wrote:
 On 20/03/2015 9:39 AM, Bryce Nesbitt wrote:
 On Thu, Mar 19, 2015 at 3:01 PM, Andy Mabbett a...@pigsonthewing.org.uk
 mailto:a...@pigsonthewing.org.uk wrote:

 amenity=fuel
 fuel=bottled


 Which would render indistinguishable from a full service fuel station.

That's fine, because selling fuel is what makes it a fuel station.

 fuel=bottled in addition would create some confusion if the fuel was in a
 drum with a pump.

 
 Rendering can change.. if there is enough need. For example some renders
 look for;
  the surface tag to render roads that are unpaved differently from those
 that are paved.
 the tags for bicycle use to determine if paths, footways are available for
 bicycle use..
 
 
 
 As I said
 
 the key fuel= is in use to distinguish the type of fuel .. CNG, diesel,
 petrol, kero etc. Not for the dispensing method.
 
 amenity=fuel
 
 and possibly
 dispenser= bottle, drum, pump (where pump is what Australians call a
 'bowser' .. and what is presently used to render amenity=fuel)
 
 or
 fuel:storage=bottle, drum,tank. Needs words to describe there things,
 particularly that the 'tank' is much larger than the drum.

I agree with amenity=fuel + a subtag like these (if needed).

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Fuel shops

[Friedrich Volkmann]

On 23.03.2015 15:36, Martin Koppenhoefer wrote:
  2 liters of fuel are as much car_parts as a bakery is bicycle_parts.
 
 The definition says: A place selling auto parts, auto accessories, motor
 oil, car chemicals, etc.
 
 That fits perfectly.
 
 can you expand? Someone sitting roadside selling just a few liters of
 petrol, how does he comply with this definition? Petrol is not in the list,
 it is neither auto parts nor auto accessories nor motor oil nor car
 chemicals. Are you after the etc.?

Petrol is similar to motor oil, both are fluids made from mineral oil.
Diesel is identical with light fuel oil. So this is clearly the same group
of products, especially when sold in equally small quantities. What else is
the etc. supposed to mean?

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Accepted or rejected?

[Friedrich Volkmann]

On 18.03.2015 07:29, David Bannon wrote:
 And amazing how many people vote, compared to those that take part in
 the discussion.
 
 Indeed. I find that strange. I'd never vote on something I did not have
 an opinion on. And, as you lot know, if I have an opinion, I share it !
 
 Maybe people just watch the chatter and make up their minds
 accordingly ?  Or do people who are not tagging list subscribers watch
 the wiki and vote when something interesting appears ?

Many people lack the time to watch the chatter, let alone participate.
Mailing lists such as this one demand a lot of time. How is someone who has
a daytime job and a family and who goes around mapping in his spare time
supposed to also spend 2 hours a day participating in mailing lists and web
forums? That's simply impossible!

For the same reason, I think that proposals should stay in proposed state
for at least 2 months, and that voting should also be extended to at least
one month, unless the topic of the proposal is urgent for some reason. Most
mappers don't read this mailing list, but they come across a proposal when
searching the wiki. E.g. when someone wishes to map a beehive he's seen this
morning, he'll search the wiki and he will find Proposed features/apiary.
This is a very good proposal, because it lists various possible tags so that
people can compare and make up their mind. A 2-week voting period after a
2-week discussion period obviously would have messed it up.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

[Friedrich Volkmann]

On 18.03.2015 14:36, fly wrote:
 Am 18.03.2015 um 12:55 schrieb Martin Vonwald:
 2015-03-18 12:47 GMT+01:00 Markus Lindholm markus.lindh...@gmail.com:

 A thought, how difficult would it be to include in the wiki-page how
 many different mappers have actually used a specific tag. Perhaps via
 TagInfo.

 This in fact would be a very helpful information! Although - please
 everyone correct me if I'm wrong - the numbers from taginfo are not what we
 want: as far as I know, taginfo shows the number of mappers, that added or
 changed(!) an object with a given tag. Much more meaningful would be the
 number of mappers, that actually added a specific tag. This is much harder
 to determine and even this number would be biased, because of way-splits.
 
 Exactly, you need to use more of the history, as how do you tread
 replaced objects like node - area ?

That would be easy if editors had implemented the origin=* key as proposed
in http://wiki.openstreetmap.org/wiki/Proposed_features/origin.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Accepted or rejected?

[Friedrich Volkmann]

On 18.03.2015 23:09, Warin wrote:
 A person coming across something that they want to map and then finding it
 on the wiki .. If that person is not on the tagging group then they don't
 want to be concerned with making tags, they simply want to use them.

Compare it to politics. Many people don't participate in politics, but have
clear political opinions, and they will tell their opinions whenever they
can do it without effort.

It's much easier to leave a comment in the wiki on the fly than to
continously participate in a maling list reading hundreds of messages every
week.

 Leaving
 comments and voting open for years won't change that .. it may simply
 confuse them as they want to use a tag

That's fine. People should be encouraged to use their brains.

 .. if it is 'proposed' or 'voting'
 status wise they may be discouraged from using it.

They use it unless they find better alternatives.

 I see no point in having a proposal open for voting over 1 year, those that
 want to vote have done so, the proposals voting should be closed and resolved.

There were some proposals where I wanted to vote, but I missed the short
voting timeframe.

 The apiary proposal 
 http://wiki.openstreetmap.org/wiki/Proposed_features/apiary
 Promotes one tag and list other tags that could be used .. It has been in
 comments stage for a few years .. abandoned?

I think that the abandoned status should be renamed, and that its colour
should be gray or yellow instead of red.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Accepted or rejected?

[Friedrich Volkmann]

On 18.03.2015 22:40, Warin wrote:
 Firstly I see no point in casting a vote of 'abstention'.. why vote at all?

An abstention indicates that someone has neither a strong positive nor
negative feeling even after pondering. The world is not just black and white.

When you look at my abstention votes, you'll find that I always pointed out
my reasons for my abstention. That's what gives sense to these votes. The
same applies to negative votes. A plain no vote is not helpful in any way.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Accepted or rejected?

[Friedrich Volkmann]

On 18.03.2015 22:50, Warin wrote:
 I agree that a 'forum' is far better at engaging a community ... keeps
 topics more organised as replies are localised (that are no isolated
 branches for instance), avoids the 'digest mode' problem, some even have a
 system of not viewing post by someone they don't like!

And it's easier to retrieve and reply to old threads.
And the e-mail addresses are not presented to spammers on a silver platter.
And you don't need to download messages you are not interested in.
And you can log in using any web browser on any computer. No need for a
tuned mailinglist-capable e-mail client, and no need to carry around a USB
stick with old messages.

Mailing lists are an obsolete technology. The may still be useful for topics
where immediate actions or decisions are required, though. E.g. for
discussing changeset reverts.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Accepted or rejected?

[Friedrich Volkmann]

On 14.03.2015 21:11, Bryce Nesbitt wrote:
 On Sat, Mar 14, 2015 at 12:13 PM, Kotya Karapetyan kotya.li...@gmail.com
 mailto:kotya.li...@gmail.com wrote:
 
 Proposal: let's change it to 8 unanimous approval votes or 10 or more
 votes with at least 74 % approval ones?
 
 
 +1 on that.  Anything without a super-majority clearly needs more discussion
 and/or experience.

In that case, we shouldn't mark it as rejected, but rather as something
like not proven.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Accepted or rejected?

[Friedrich Volkmann]

On 14.03.2015 21:27, Clifford Snow wrote:
 I would suggest adopting  Conditional Approval approach. If the proposal
 receives sufficient votes, it becomes Conditionally Approved. Only after
 it becomes widespread and adopted by JOSM and iD it becomes an Approved
 tag.

No. Editor developers aleady have too much power. Editor support often
depends on the mood of one single person. I would rather say that, for a
given number of occurrences, editor support should be considered a counter
indicator for approval. When usage spreads in spite of no editor support,
that means that mappers choose the tag on purpose. When usage remains
intermediate in spite of editor support, that means that mappers use the tag
only because it is imposed by the editor.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Accepted or rejected?

[Friedrich Volkmann]

On 14.03.2015 12:50, Dan S wrote:
 When there is very low interest (i.e. very few votes) - which is
 pretty common - then even one dissenting vote is enough to make us
 step back and think again, whereas if there are enough votes to make
 majority approval a meaningful concept (I admit that 15 is a low
 number for quorum) then we accept that there will always be some
 disagreement, and so we use majority rather than unanimity.

As you are already indicating, 15 is too low a quorum in that case. We
cannot considering 8:7 votes an approval when we cosider 8:1 votes an
approval. That would mean that more negative votes would turn a rejection to
an approval, which is absurd.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Accepted or rejected?

[Friedrich Volkmann]

On 14.03.2015 12:24, Jan van Bekkum wrote:
 The guideline to determine if a proposal is accepted is
 
 A rule of thumb for enough support is /8 unanimous approval votes/ or /15
 total votes with a majority approval/, but other factors may also be
 considered (such as whether a feature is already in use).
 
 This sounds a bit strange to me: a proposal with 8 approval votes and 1
 decline would be rejected, while one with 8 approval votes and 7 declines
 would be accepted.
 
 I suppose that this is what was intended:
 
 enough support is 8 approval votes on a total of 14 votes or less and a
 majority approval otherwise.

Yes, this should be reworded as you suggest. The current wording caused
confusion multiple times.

However, we should keep the mention of other factors ... such as whether a
feature is already in use, especially when it comes to deprecation of
existing tags. I think that this should be even more clearly pointed out. A
majority of 8:7 votes cannot be sufficient for a deprecation of a tag used
by thousands of mappers.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Current status of the key smoothness=*

[Friedrich Volkmann]

On 11.03.2015 23:23, David wrote:
 I am a little unsure what the problem is with the pictures. Could you be a 
 bit more specific please Friedrich ?
 
 It would be very hard to have a set of pictures that cover every case but, as 
 Jan said, if we are only one level out, thats still very useful information. 
 Honestly, while not very clear, the pictures look about right to me.

Ok, let's see...

Now that I look at it in detail, I realize that the verbal descriptions
might be flawed too. When there's a category /excellect/ usable by roller
blade, skate board and all below, there should also be one even better
category like /perfect/ desirable for roller blade and skate board. Raugh
asphalt is usable by roller blade, but fine asphalt is desireable.
Similarly, fine gravel roads are usable by racing bikes, but not desirable.
surface=ground may be usable by racing bikes when dry, but certainly not
when wet. All of this should be pointed out in the text.

BTW: Rollerblade is a trade mark. Better change that to roller skates and/or
inline skates.

One more text issue: the term city bike should be replaced by something
like standard/normal/conventional bicycle, because a city bike is a mountain
bike plus lights and reflectors, thus more robust than a trecking bike.


I'll be numbering the pictures from #1 (excellent line) to #8
(impassable line).

#1 is a scanned paper photo or diapositive. You see dirt and scratches, and
the picture is not quite sharp. But the content of the picture seems
alright. It's intermediate quality asphalt with patches. Not optimal, but
easily usable for all.

#2 What part of the road do they mean? The carriageway looks similar to #1.
(No patches, but on the other hand there's a gully grid.) Or do they mean
the bus stop? Or the footway? The footway surface seems well suited for
roller skates and skateboard too, although some grass creeps in, and you
need to beware the seams and poles.

I suggest a photo depicting sand surface or very coarse-grained and uneven
asphalt or concrete.

#3 This looks like a ford or a temporarily flooded area. The photo should
probably go to the highway=ford wiki page. If you leave away the water, the
road is perfectly suitable for racing bikes, although the dirt indicates
that it may be even more dirty at seasons, making it less usable then.

I suggest a photo of a road with fine gravel or compacted gravel surface
instead.

#4 is a big step from #3. This is indeed unusable for racing bikes, but
usable for trecking bikes and normal cars (although vegetation is near to
the limit). This photo seems to match the description, but I am not shure
about rikshaws.

#5 This track looks like the same as #4 or even better because there's less
vegetation and the surface looks harder and less prone to waterlogging. You
do not need a high-clearance vehicle for that track.

I suggest to move the #5 photo to #4, and to use a photo of a track with
10-20 cm deep ruts (but otherwise similar to #4) for #5.

#6 This shows a track you can use with a normal car. The grass will make
some noise, but it will not damage the car. You can add this photo to the
smoothness=bad examples, i.e. 2 rows up.

The photo for smoothness=horribly should show a very uneven and either muddy
or densely vegetated road.

#7 This photo looks like a clip, you don't see the whole way. Just throw
that photo away.

#8 This looks smooth enough for MTB. It might be to steep to drive uphill,
but experienced MTBers drive this downhill no matter how steep it is.

Steepness (see incline=*) is an important factor we should consider. A track
may be smooth enough for a sports car, but so steep that only a tractor can
make it. I think that we should explicitly include or exclude steepness in
the smoothness definition. Opinions?

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] square_paving_stones:width

[Friedrich Volkmann]

On 11.03.2015 17:18, Mateusz Konieczny wrote:
 As described in paving_stones:n thread there is a problem with
 surface=paving_stones:integer
 values. To offer better alternative for storing information about size of
 square paving stones I am
 proposing this tag.

What about rectangular paving stones? A key paving_stones:length (with a
definition like the length the longest horizontal edge) would be more
universal. And there should be some default unit (m?).

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Current status of the key smoothness=*

[Friedrich Volkmann]

On 11.03.2015 17:29, Jan van Bekkum wrote:
 Perhaps we can extend the library of pictures in the wiki to give people a
 better feeling which rating means what.

I agree that work on the pictures is needed. The values and their verbal
descriptions are approved, and they look sound, while the bogus pictures are
not approved and they do not match the definitions. We should either replace
those pictures or just delete them.

It seems to me that these pictures are the root of most of the controversy
and the reason why these tags are ignored by most mappers and data consumers.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Leaf type of palm for leaf_type

[Friedrich Volkmann]

On 10.03.2015 21:41, Bryce Nesbitt wrote:
 I'm seeking comments on adding palm to the leaf types
 at http://wiki.openstreetmap.org/wiki/Key:leaf_type
 
 A rendering engine can equate palm and broadleaved.  Mappers are mapping 
 palms
 very frequently, and having this key name I think would reduce confusion.

I am glad you added a palm symbol to
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree#Possible_Rendering.
When I created the conversion table in that section, I wondered why there is
no palm symbol. I believed that I had already seen a palm symbol somewhere
in the wiki, but I didn't manage to retrieve it. Then I searched google for
palm symbols, but did not find anything either. So I was finally in doubt
whether palm symbols are in use in carthography at all, although I still
believe that palm symbols add value to maps. If broad and needle leaved
trees get different symbols, palms should get their symbol as well because
of their distinctive look. And - but that's just my subjective opinion -
palm symbols look so cute that a map becomes more appealing when it
incorporates them.

Concerning tagging, there has been an approved and widely used key for a
long time with exactly the values we need to distinguish palms, needle
leaved and broad leaved trees. This key is type=*. This key worked quite
well. However, there were two aesthetic issues with that key: That it is
also used for relation types, and that there's a different key wood=* used
for areas (natural=wood, landuse=forest).

These issues evaporate when you look at them from an analytical perspective.
type=* of trees never collides with type=* of relations, because trees are
not relations. And wood=* has just another purpose. While
type=broad_leaved/coniferous/palm defines the *habitus* of a single plant,
wood=* describes a *behaviour* of an area. wood=evergreen means that
assimilation (photosynthesis) does not change much with the seasons, and
that the tree crowns remain continuously opaque. wood=coniferous means that
the crowns are constantly semi-opaque, and that assimilation remains also at
an intermediate level. wood=deciduous means that both assimilation and
opaqueness have big seasonal amplitudes. This tag has enourmous ecological
and econimical implications, and it may also be used to determine good times
for documention (photographing, creating arial images) and recreational use.

It is absolutely useless to use tags the other way round, i.e. plant habitus
for forests or assimilation amplitudes for single trees. Therefore, no
serious efforts were made to unify these tags, for many years.

Then came Rudolf's surprise attack. He created a flawed proposal that missed
all of the above points, and pushed it to voting just 3 weeks later. This
was a much too short disussion period for a change affecting tremendous
amounts of existing data. Many people, including me, did not have enough
spare time in that time frame to participate in the discussion and to single
out all of the flaws which include:

- The wrong interpretation of the rule that type=* for non-relation
elements should be avoided.
- The mistaken reduction of wood=* to describe the type of leaves.
- The wrong assumption that all of these tags mean the same.
- The wrong assumption that new keys make things easier. Obviously, the
opposite is true, because mappers and applications now need to know the new
tags *in addition* to the conventional tags.
- An ugly key name leaf_type=* although the more sound foliage=* key had
been suggested on Talk:Key:wood as early as in 2012 by Alv.
- broadleaved and needleleaved with no underscores
- information loss due to the missing equivalent to type=palm
- and worst of all, the deprecating established keys thing. There were
more than 1 million of uses for wood=* and type=*. How can a proposal
deprecate tags used a million times? Do 27 votes on a wiki page legitimate
for the deprecation of tags used by 1 distinct mappers on 100 objects?

Well, you could think that a proposal is one thing, and actual usage is
another thing. Let's see how real mappers will accept it in real life. But
in this very case, real world mappers got no chance. Immediately after
voting has ended, Rudolf marked type=* and wood=* as deprecated on the
natural=tree and wood=* wiki pages. I guess that some JOSM developers wanted
to keep their editor cutting-edge by changing templates or suchlike to the
new tagging scheme. And some validators spit out warnings when they come
across the decprecated tags.

As we all now, some sofa mappers spend all day searching for things to
correct, using validators. These people do not care about how map features
represent the real world, or who mapped them or why, or who will ever use
the data. They only care about what the validator says. If a validator
blinks red, there's a need to change something, and if it does not blink
red, everything is fine.

This results in mass edits that violate the mechanical edits policy. But
those people do 

Re: [Tagging] Leaf type of palm for leaf_type

[Friedrich Volkmann]

On 11.03.2015 17:58, Mateusz Konieczny wrote:
 It's all driven by technocrats who have no clue about what a tree
 or forest looks like in the real world.
 
 Small note, phrases like this are unlikely to be a good idea.

Let's assume that technocrats don't read this. :-)

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Current status of the key smoothness=*

[Friedrich Volkmann]

On 11.03.2015 12:56, jgpacker wrote:
 Is this claim over it's verifiability still current?

Yes, it is, because the photos contradict the verbal value definitions.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

[Tagging] Feature Proposal - RFC - courtyard

[Friedrich Volkmann]

On 13.02.2015 13:21, Friedrich Volkmann wrote:
 I'm now in favour of man_made=courtyard, because it is man made (as opposed
 to natural) without doubt, and it is similar to man_made=cutline. Both
 cutlines and courtyards are intentionally empty spaces, and both are only
 defined by their sourroundings.
 
 man_made=courtyard does not conflict with other tags. It can be combined
 with leisure=*, landuse=* etc., and I can't imagine any other man_made=*
 feature that is congruent with a courtyard.

I finally created a proposal:
http://wiki.openstreetmap.org/wiki/Proposed_features/courtyard

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Feature Proposal - RFC - register

[Friedrich Volkmann]

On 06.03.2015 12:09, Paul Johnson wrote:
  May be related to the United States Department of Agriculture's National
 Forest Service use permits.  Typically a small wooden box with some pencils
 and waterproof application cards inside, on which you are either strongly
 encouraged or legally obligated to spell out where you're going, who's with
 you, when you're expected back, what trailhead you parked at and what your
 vehicle's registration plate (or serial number in case of vehicles that
 don't require a plate).  Usually no charge (and often there's a warning
 encouraging people not to donate cash in the box).  Rangers typically check
 these weekly or so, as well as before bad weather, empty out the filled out
 cards and resupply them so they know who didn't come back, who needs rescue,
 and where they need to hike to in order to warn people to get off the 
 mountain.

You may add that to the proposal page if you like.

I heard of one or two fia ferrata where climbers are required to add to the
log, but most registers in central europe are optional to use.

We can tag which registers are optional or obligatory, but I don't know if
that information is of any practical use.

It's similar to obligatory cycleways. I think that the information should
not be set on the cylceways or the register, respectively, because the use
is obligatory only for users of a corresponding feature. Concerning
registers, that corresponding feature is a highway=path, a route relation, a
building, a cave, or similar. In your example, it's certainly a forest.

So we could add some register=yes/no/obligatory (or compulsory?) tag to the
path/route/forest/etc.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

[Tagging] Feature Proposal - RFC - register

[Friedrich Volkmann]

http://wiki.openstreetmap.org/wiki/Proposed_features/register

This is for books where people enter their names, routes and comments. These
books are located on peaks, along trails, in buildings and in caves.
In German we call them Gipfelbuch, Steigbuch, Hüttenbuch, Gästebuch,
Höhlenbuch, Pilgerbuch, Turmbuch...
English terminology seems more ambiguous. I took the word that seems most
common.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Canopy radius for natural=tree

[Friedrich Volkmann]

On 25.02.2015 11:47, Martin Koppenhoefer wrote:
 it is using the natural language notation with space (underscore)
 rather than diameter:crown.

I feel that this differentiation became blurry due to the random use of :
and _ for _type and :type suffixes.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

[Tagging] Feature Proposal - RFC - goods_conveyor

[Friedrich Volkmann]

http://wiki.openstreetmap.org/wiki/Proposed_features/Goods_conveyor

I resurrected this old draft, because we need a tag for this and I know of
no alternative tag currently in use. I wonder if goods may be misleading,
because I think of goods as finished products, while many conveyors carry
raw materials. Anyway, there are 589 uses of man_made=goods_conveyor, so we
better stick with it.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Feature Proposal - RFC - goods_conveyor

[Friedrich Volkmann]

On 25.02.2015 15:42, Martin Koppenhoefer wrote:
 is this for belt conveyors and roller conveyors? There are also pneumatic
 conveyors (with tubes, e.g. postal pneumatic tubes) and there are chain
 conveyors.

See the subtags section in the proposal. By proposal I mean the wiki page.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Feature Proposal - RFC - goods_conveyor

[Friedrich Volkmann]

On 25.02.2015 17:16, Richard Z. wrote:
 there is aerialway=magic_carpet which is intended for human transport only
 but together with usage  access keys could be used to tag that as well.

I don't think so, because:
- goods conveyors are not really aerialways
- goods conveyors are not called magic carpets
- we cannot extend usage to goods while leaving out moving walkways (for
which the conveying=* key has been approved)

 The proposal looks good, add location=* to it.

I dislike location=* for various reasons. But you may use it if you like.
This is another subject with no impact on the proposed
man_made=goods_conveyor key.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Canopy radius for natural=tree

[Friedrich Volkmann]

This construct does not come from a natural language. It's rather computer
programming style, like class::subclass (see maxwidth:physical=*, name:en=*
etc.), and it's also in spirit of mathematical notation (functions,
subscripts), like diameter(crown).

On 23.02.2015 23:48, Colin Smale wrote:
 No adjectives here... Crown diameter is a compound noun composed of two 
 nouns.
 
 More likely a germanic language where the juxtaposition implies a genitive -
 diameter crown -- diameter of the crown. Could certainly be Dutch or
 German - it's a very common construct.
 
  
 
 On 2015-02-23 23:22, John F. Eldredge wrote:
 
 True. English usually has an adjective followed by a noun. I would guess
 that diameter crown was probably written by someone more familiar with a
 language where adjectives follow nouns.

 -- 
 John F. Eldredge -- j...@jfeldredge.com
 Darkness cannot drive out darkness; only light can do that. Hate cannot
 drive out hate; only love can do that. Dr. Martin Luther King, Jr.

 On February 23, 2015 3:17:33 PM Brad Neuhauser brad.neuhau...@gmail.com
 wrote:

 diameter crown also doesn't appear to be vernacular English,
 unfortunately. Crown diameter or crown spread seem to be more
 widely used.  For example, see
 http://www.treeterms.co.uk/definitions/crown-diameter, and
 
 https://en.wikipedia.org/wiki/Tree_crown_measurement#Crown_Spread_Methodologies

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] courtyards

[Friedrich Volkmann]

On 09.02.2015 16:01, Stephen Gower wrote:
 Here in Oxford (where we have many examples of named quadrangles/courtyards)
 I see examples where they are tagged as highway=footway areas (e.g.
 http://www.openstreetmap.org/way/301895528 ) but more often the central
 section of lawn has been named (e.g. 
 http://www.openstreetmap.org/way/228244550 )
 
 In reality, it is neither the paving or the lawn that is the named feature,
 it's the architectual feature containing these and itself bounded by the
 buildings (although in the case of cloistered courtyards, the covered
 arcades around the edge are arguably both part of the building and the
 courtyard). I support creation of a tag for more consistantly marking these
 named features, but I have no idea where in the tagging structure it is
 best placed (building/landuse/amenity/etc all have their problems).

I had essentially the same thoughts. (That's why I started this discussion.)

I'm now in favour of man_made=courtyard, because it is man made (as opposed
to natural) without doubt, and it is similar to man_made=cutline. Both
cutlines and courtyards are intentionally empty spaces, and both are only
defined by their sourroundings.

man_made=courtyard does not conflict with other tags. It can be combined
with leisure=*, landuse=* etc., and I can't imagine any other man_made=*
feature that is congruent with a courtyard.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] courtyards

[Friedrich Volkmann]

On 08.02.2015 22:17, Warin wrote:

 From a technical point of view they are typically associated with fire 
 protection (way to leave the building, access for firefighters), 
 
 If the courtyard is fully enclosed by buildings or by one building .. they
 are not part of a fire escape (protection), those require exit to an open
 area - not one that is fully enclosed. So the use as fire protection will
 depend on  the courtyard. And my thinking is that a true 'courtyard' is
 fully enclosed?

We need to be able to map partially enclosed courtyards as well, e.g.:
https://www.openstreetmap.org/#map=19/48.17839/16.34189
(The courtyards are named Hof 1 ... Hof 7.)

But I agree that a courtyard *typically* is fully enclosed by buildings,
thus not an emergency feature. There's an approved tag entrance=emergency
for emergency exits, and I'd suggest a tag like emergency=access for spots
and alleys designed to be accessible for fire fighters.

I think that, from a technical point view, the main function of a courtyard
is to yield sunlight to building rooms that are not adjacent to the
building's outer margin. All other uses, such as recreation, parking or
emergency access, are subsequent.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

[Tagging] courtyards

[Friedrich Volkmann]

Courtyards use to be mapped as inner members of building multipolygons. We
can also use the multipolygon relation to assign a name to the bullding. If
we want to assign a name to the courtyard, we must assign it to the way. But
then we need some kind of physical tag in addition. Applications won't know
what do do with the name when there aren't any other tags.

Some courtyards are tagged place=locality or highway=pedestrian or
leisure=park, but they all seem wrong. A place=locality wouldn't be that
strictly delimited, and a park or pedestrian area need not occupy the entire
courtyard.

A courtyard really has nothing to do with leisure=*, and it is not a highway
either. It's just a hole in a building. What key can we use for this?

What about place=courtyard (an area spared by a buildng), analogous to
place=island (an area spared by the ocean)?

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] patron saints

[Friedrich Volkmann]

On 29.01.2015 13:24, Satoshi IIDA wrote:
 +1 to use wikidata.
 I had once thinking about same purpose. :)
 https://wiki.openstreetmap.org/wiki/Proposed_features/enshrine

Sorry that I missed your proposal.

Indeed, it seems that the wikidata id makes the tagging of related enshrines
superfluous, as the relation between main and related enshrines can be
defined outside OSM.

 But many place of worship in Japanese have multiple dedication gods.
 And when we would like to express using semi-colon (;),
 multi-lingual approach would be fail into complex array.
 
 e.g.
 If a shrine dedicates 3 gods.
 in Japanese Kanji = 天照大御神; 月讀命; 素戔嗚尊
 in English = Amaterasu-Oomikami; Tsukuyomi-no-Mikoto; Susanoo-no-Mikoto
 
 And each gods has loc_name, alt_name, or alternated writings.
 I was thinking about dedication:N (like Addr:N) once, but it is a bit
 troublesome.

There's a subtle difference to addrN:
addr1:street, addr1:housenumber etc. need to be used in conjunction, while
name:en, name:jp etc. are alternatives.

Of course, local names or alternated spellings complicate things a lot.

Isn't there an official dedication for a given japanese place of worship?
We do have that for churches. It's one fixed wording (and spelling) for a
given church, just like a birth certificate defines one fixed spelling for a
given individual.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] patron saints

[Friedrich Volkmann]

On 28.01.2015 05:01, John F. Eldredge wrote:
 On 01/25/2015 10:29 AM, Friedrich Volkmann wrote:
 Probable all christian churches (buildings) and most chapels are dedicated
 to patron saints.
 E.g. the Basilica Sancti Petri (Saint Peter's Basilica) in Vatican City is
 obviously dedicated to Sanctus Petrus (Saint Peter). As in this example, the
 patron saint is often part of the common name of a church. But this example
 also shows that an automated extraction is almost impossible.
 
 This depends upon which branch of Christianity you are talking about. Many
 Protestant denominations do not recognize the existence of saints in the
 Roman Catholic sense of no-longer-living humans who serve as intermediaries
 between living humans and God.  We colloquially refer to some of the early
 church leaders as saints, referring to Saint Peter or Saint Paul, but feel
 that prayers should be directed to God, not to any lesser being.

That's interesting, because I always thought of christianism as a
polytheistic religion.

Now there seems to be a consensus to use a dedication=* key, which certainly
works for monotheists as well.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] patron saints

[Friedrich Volkmann]

On 28.01.2015 12:34, Andy Mabbett wrote:
 There are sometimes more than one saint with the same name, This is
 where Wikidata tags provide useful disambiguation.
 
 You can either tag with:
 
wikidata = Q12512 (resolves to https://www.wikidata.org/wiki/Q12512
 ; the item for Saint Peter's Basilica)
 
 from which you can determine that the patron saint (P417) is Q33923 (
 https://www.wikidata.org/wiki/Q33923 ; equivalent the articles on St
 Peter in various languages, such as,
 https://en.wikipedia.org/wiki/Saint_Peter )
 
 Or you could tag more explicitly, with
 
patron-saint:wikidata = Q33923

The reference to wikidata has already been suggested elsewhere in this thread.

It currently comes down to dedication=* for the full name(s) in local
language, dedication:en=* etc. for translations, and dedication:wikidata=*
for the wikidata code(s).

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

[Tagging] patron saints

[Friedrich Volkmann]

Probable all christian churches (buildings) and most chapels are dedicated
to patron saints.
E.g. the Basilica Sancti Petri (Saint Peter's Basilica) in Vatican City is
obviously dedicated to Sanctus Petrus (Saint Peter). As in this example, the
patron saint is often part of the common name of a church. But this example
also shows that an automated extraction is almost impossible.

There are also many churches whose common names do not include the patron
saint at all. E.g. http://www.openstreetmap.org/way/30344133 is usually
called Bergkirche or Haydnkirche, but the patron saint is Maria
Heimsuchung. Well, I don't know if a saint named Maria Heimsuchung really
existed, but the church is dedicated to her, so it's a patron saint at least
in an abstract sense.

There has been no tagging rules so far. Some churches have
name=common_name + alt_name=patron, some have it the opposite way, some
have the patron or the common name omitted.

I'd like to suggest a new key for patron saints. Certainly patron_saint=* or
just patron=*. There are some occurrences in Taginfo, although most values
of patron=* do not look like saints.

holy_name=* has also been suggested, but this sounds to me as if the name
were holy. It's actually the saint who is holy.

patronage=* may be ambiguous.

patrociny=* seems to be an extinct word.

What do you think?

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] patron saints

[Friedrich Volkmann]

On 25.01.2015 19:07, André Pirard wrote:
 I think that, when they have a name=* tag (when the mapper cared to find it,
 easy, they're all here (unités pastorales) http://liege.diocese.be/),
 almost all churches around here are tagged with the dedication.

Looking at Liège in OSM, I see names like:
name=Cathédrale Saint-Paul
name=Collégiale Saint-Jean
name=Église Saint Pierre
etc.

So they are not exactly tagged with the dedication, but the dedication is
part of the name.

 So, someone volunteering to change all that to another tag and only when
 it's a dedication would have a terrible job on his hand.

The new tag is optional, so there is no need to do that work.

However, if someone happens to do it, reports like show me all churches
dedicated to Saint Paul or show me the most popular dedication in that
region or show me the region where Saint Paul is most popular become
possible.

 If I came across a case like yours (usual name definitely not the
 dedication) I would simply use
 name=Haydnkirche Heilige Maria Heimsuchung

This would be simple, but wrong, because that is not the name.

 or use alt_name=Heilige ...

This is how we have done it so far, but strictly speaking it is wrong too,
because Heilige Maria Heimsuchung is not the name of the church, it's the
name of the dedication. Kirche zur Heiligen Maria Heimsuchung could be a
name, but then again, the tag value is unusuable for reporting.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Shop for watches

[Friedrich Volkmann]

On 25.01.2015 11:46, Severin Menard wrote:
 I did not find anything on the Map Features regarding shop selling watches,
 what is quite common both in Europe and South America (at least).

shop=jewelry

Watches came out of use when people got mobile phones. The only remaining
reason to wear watches is to show off. That's why all jewelries sell
watches, and you'll hardly find any shop that sells nothing but watches.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] patron saints

[Friedrich Volkmann]

On 25.01.2015 23:30, Eugene Alvin Villar wrote:
 On 1/26/15, Lukas Sommer sommer...@gmail.com wrote:
 And I think it makes sense to define explicitly some things in the
 documentation. Things like
 – use always (or use never) “Saint”: “Saint Paul” vs “Paul”.

That's a good point. In German, there are name variations for many saints,
e.g. Nepomuk = Johannes Nepomuk. There are name variations even for the word
saint: Sankt, St., Heiliger, Hl., none.

But AFAIK the official dedication for a given church is always a fixed
version of the name. Of course that breaks comparability.

 – write the name of the dedication always in the local language (Or
 always in latin? Could become very complicate ;-)

It's the same as with species=*, plant_community=* etc. The values of theses
tags are latin, too. Mappers get used to them quickly. Names in other
languages can be given as species:en=*etc., although the benefit of these
translations remains unclear.

If we use the local language for the value of dedication=*, it's like
name=*. Again there's name:en etc.

So we may think about dedication:language=* in any case, but I'm not sure
about the language of dedication=* itself.

 The clearer these things are defined from the very beginning, the more
 useful will the tag be.
 
 If you are going to use the local language in this tag, then the sort
 of GIS queries suggested (most popular saint in a region, etc.) would
 not be possible. In addition, do you tag Paul or Paul the Apostle
 or Simon Peter? Do you tag Joan or Joan of Arc?
 
 If this tag is to be useful (assuming it is the sort of thing OSM
 should record), maybe using Wikidata should be considered through an
 additional tag such as dedication:wikidata=Q33923 for Saint Peter
 https://www.wikidata.org/wiki/Q33923

I dislike these numbers. They are not human readable, and typos will not be
noticed.

Can we find out how many distinct dedications do exist? Maybe we can create
a list and then visualize it and get inspiration. That list can subsequently
be used for the dedication=* wiki page.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Feature Proposal - RFC - addrN:*

[Friedrich Volkmann]

On 21.01.2015 08:28, Markus Lindholm wrote:
 Before we get carried away by a zillion relations I think we have to
 answer the questions as to what purpose do we want to explicitly
 associate an address with a POI or a building.
 
 Is it so that the data consumer can find her way to a POI? That's
 obviously superfluous as the POI already has a geographical location
 given.

But not the address, according to your suggestion to keep addresses in
separate nodes.

Concerning buildings, an address node is imprecise. It may be on one side of
the building, while you'd better come from the other side of the building.
Search Nominatim for my postal address Davidgasse 76-80 and click the
House in the search results. You couldn't achieve that with a single
address node. In fact, the address node would be at the southern end of the
building complex, while I live at the northern end, so you wouldn't find
your way to my appartement.

 The only purpose I can think of is to facilitate for the data
 consumer to send a physical letter to the POI and that is a bit of a
 fringe use case. With buildings is even murkier as to what the purpose
 would be. Is there any country where the address would be part of the
 ID for the building in the cadastre? Seems unlikely as a building can
 have many addresses.

I think that we don't need to care about the cadastre. It's something
independent from OSM.

I think we should generally not ponder about application purposes too much.
The purpose of tagging is to represent data in a clean and unambigous way.
Leave it over to applications to do something with it or not. If someone
wants to make a carnival report on whether buildings with even or odd
housenumbers are larger, why not?

 So I'm not advocating that a zillion relation be created, just that if
 you REALLY need an EXPLICIT association between an address and a
 POI/building then you should use a relation. And that addresses would
 be stored in the database in a coherent manner.

That mixes the needs of mappers and data consumers. As a mapper, I don't
need such an association at all.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Feature Proposal - RFC - addrN:*

[Friedrich Volkmann]

On 22.01.2015 04:02, John F. Eldredge wrote:
 If you have a strictly delimited plot of land, with no house currently
 built upon it, but which is intended for later construction, does it have a
 house number?  Or is the address only assigned once a building is built?

When it is already intended for later construction, it usually already has
an address (including house number or conscription number) assigned. But
again, I can only speak of Austria.

So we have three levels of estimated vs. fully surveyed address mapping:
1) address nodes: we know that the address is valid somewhere around that point
2) address as building attribute: we know at least one building where the
the address is valid
3) address as plot attribute: we know the entire area where the address is valid

Of course, the building may occupy the whole plot, especially in cities.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] AddrN

[Friedrich Volkmann]

On 19.01.2015 12:06, Paul Johnson wrote:
 This seems like a particularly strange edge case for the address scheme, but
 I'm curious if any of those valid addresses are consider the primary?

Usually the postal address which you give in your official documents is
considered the primary. But this address may not be suitable for other uses.
E.g. I live in an apartment complex that extends over 2 building blocks:
http://www.openstreetmap.org/relation/1060497
The postal address is Davidgasse 76-80, staircase (addr:unit) 14. My windows
are heading to the Buchengasse. The Davidgasse is not even adjacent to the
whole block. So nobody finds to me when I tell them my postal address. I
need to tell them I live in Gußriegelstraße 5, because that's the location
of the building passage that leads to the correct corner of the courtyard.
The chimney sweep uses Buchengasse 151 though, because that's the street
where my apartment (and the chimney) is located.

So I'd say that Davidgasse 76-80 is the primary address (addr:*),
Gußriegelstraße 5 the secondary address (addr2:*), and Buchengasse 151 the
tertiary address (addr3:*).
Malborghetgasse 6 (addr4:*) and Rotenhofgasse 86-88 (addr5:*) are also
equivalent, but are never actually used for my side of the building.

 And
 if that's the case, what's wrong with creating a node on the building for
 each additional valid address?  People looking for an amenity could look up
 closest POIs after finding a secondary address.  It's not a clean situation,

It's a best guess approach, delivering lots of false positives, because
the scope of address nodes is undefined. The address may be valid for the
whole building, or only part of the building, or even for multiple buildings
(take my postal address as an example).

 but it does have a couple advantages:
 
   * Works with existing data consumers

That's fine, but if that were a criterion, OSM wouldn't exist. I think that
addresses are important enough to justify extensions of applications.

   * Simple for users to tag.

addr2 is simple too. It's just one more character. And you don't need to
create additional nodes, let alone relations as suggested somewhere in this
discussion.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] AddrN

[Friedrich Volkmann]

On 21.01.2015 13:00, Andrew Shadura wrote:
 if that's the case, what's wrong with creating a node on the building for
 each additional valid address?  People looking for an amenity could look up
 closest POIs after finding a secondary address.  It's not a clean situation,

 It's a best guess approach, delivering lots of false positives, because
 the scope of address nodes is undefined. The address may be valid for the
 whole building, or only part of the building, or even for multiple buildings
 (take my postal address as an example).
 
 But that's not precisely true. The scope of an address node inside a
 building outline is this building. If you want to specify an address
 for a part of a building only, just split that building.

That's a well-meant advice, but a big portion of buildings in the database
are not split. That's because mappers walking to the street writing down
housenumbers do not measure building lengths, or the seam between two
buildings parts may not even be visible from the outside. You often cannot
see it on arial images either. OGD may help, but many buildings were mapped
before OGD became available for the respective regions.

Moreover, I am not aware of any wiki page stating that the scope of an
address node is the whole building.

The approach comparing address nodes to building outlines may be perfect in
theory, but you'll always get tons of false positives with real data.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] AddrN

[Friedrich Volkmann]

On 19.01.2015 17:41, Clifford Snow wrote:
 If these are conscription numbers, why not use the addr:conscriptionnumber
 tag? It is document in the wiki [1] and appears to be in use. It would also
 appear more accurate and less likely to lead to misuse. 
 
 [1] http://wiki.openstreetmap.org/wiki/Key%3Aaddr%3Aconscriptionnumber

Sadly, that wiki page is not referenced where it should. Particularly,
there's no mention of addr:conscriptionnumber on
http://wiki.openstreetmap.org/wiki/Key:addr. That's the reason why we do not
use addr:conscriptionnumber in Austria.

One further reason may be that we find it difficult sometimes to distinguish
housenumbers and conscriptionnumbers. Actually, we use housenumber
(Hausnummer) as the hypernym for orientation number (Orientierungsnummer)
and conscription number (Konskriptionsnummer). The orientation number is the
number to be used in conjuntion with a street name. However, the street name
is omitted on many housenumber plates, so you won't know for sure if it's an
orientation number or a conscription number when you are just passing by.
You need to look for name signs on the nearby streets. But sometimes you'll
find a settlement name on them, leaving you in doubt. As a consequence,
addr:street, addr:hamlet and addr:place are used almost interchangably in
many rural settlements.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Friedrich Volkmann]

On 19.01.2015 12:10, Richard Z. wrote:
 ##== Disadvantages of semicolon separated lists ==
 
 ##* parsing of values is required
 
 sure parsing is required. How terribly difficult is it to split 
 a string by ;?   

It's trivial.

Xxzme is one of those mappers who try to design tagging rules which simplify
software development, by making assumptions instead of asking those who
know. The resulting tagging rules are actually a burden for both mappers and
developers alike. People like him would better focus on aspects they are
familiar with. OSM is a collaborative project after all.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[Friedrich Volkmann]

On 21.01.2015 02:51, Никита wrote:
 payment=efectivo;visa;mastercard;american␣express
 payment=mastercard;visa;efectivo
 
 Now try to find *efectivo *with your regexes.

With a perl regex:
^[^=]+=(.*;)?\s*efectivo\s*(;.*)?$

Usually you only have the value in your variable, so you only need:
^(.*;)?\s*efectivo\s*(;.*)?$

But it's better programming style to split the values into arrays before you
work with them, like (in perl):
$_-{single_vals} = split /;/, $_-{compound_val} for keys @tags;

Then you need no regexp at all for your comparisons.

 How to query for payment:efectivo=yes? I definitely need regex here.

You have to be aware of values like 1, true, unknown etc.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Feature Proposal - RFC - addrN:*

[Friedrich Volkmann]

On 19.01.2015 12:37, Markus Lindholm wrote:
 Treating addresses as attributes might be fast and convenient but that
 kind of scheme
 becomes incoherent as there is no one-to-one relationship between
 addresses and other features.
 E.g.
 - There are MULTIPLE POIs that all relate to ONE address
 - There are MULTIPLE addresses that all relate to ONE building
 So you would end up with a database where the address information is
 stored all over the place and no coherent way to process it. Better
 to have bare address nodes and when necessary use a relation to create
 an association between the address and other features.

We already have zillions of POIs (e.g. shop nodes) with address attributes.
If you wanted to keep address information separate, you would need to add
just as many address nodes and relations. You would even need to separate
all addresses from buildings. So your vision is not only incompatible with
the addrN scheme, it is incompatible with how addresses are used in OSM
altogether.

You apparently wish to implement a relational database concept for address
information, but this is just impossible because OSM is not a relational
database. All data in OSM directly or indirectly contains geographical
information. When you use a relation to connect a shop node (which has
geographical coordinates) to an address node (which as geographical
coordinates), you have two conflicting sets of geographical coordinates. So
if you are looking for normalisation, you need to get rid of the address
nodes altogether and set the adress tags on the relation directly.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Tagging] Feature Proposal - RFC - addrN:*

[Friedrich Volkmann]

On 19.01.2015 12:47, Andrew Shadura wrote:
 It doesn't actually matter if you agree or not, because it doesn't change
 the fact that buildings in CZ and SK don't have multiple addresses.

I cannot judge this. If this is a fact, addr2 is not needed or even plain
wrong for conscription numbers in CZ and SK. The addrN scheme just offers a
syntax for alternate addresses. Use it where applicable, and don't use it
where it is not applicable. The conscription number example in my version of
the proposal is from Austria, where it is applicable.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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