Re: [Tagging] Deprecation of non-approved values for diplomatic=?

[Joseph Eisenberg]

Right.

By "deprecated" this is what I mean: should the wiki pages be changed
to make it clear that diplomatic=honorary_consulate is no longer
preferred, and could be changed to diplomatic=consulate +
consulate=honorary_consulate ?

On 6/14/19, Lionel Giard  wrote:
> I think that the only deprecated tag in the accepted proposal is
> "amenity=embassy" (which is indicated on the wiki page too).
>
> The wrong diplomatic value are just what old tagging scheme lead to. It
> doesn't need to be deprecated to me as it never existed officially (i
> think) - and it will probably be fixed at some point in the future when
> contributor update the embassy/consulate/...
>
> The only action i would take is to *add the note on the wiki page of
> "diplomatic=*" for each of the "non-approved" value*, where we specifically
> tell what is the new approved *sub-tag* (so people know that there is an
> alternative). Like for "diplomatic=honorary_consulate", note in the
> description that it could be tagged as "diplomatic=consulate" +
> "consulate=honorary_consul" with the new tagging scheme.
>
> Regards,
>
> Le ven. 14 juin 2019 à 12:32, Frederik Ramm  a écrit :
>
>> Hi,
>>
>> in general, I try to avoid marking anything as deprecated. I think the
>> term only gives people wrong ideas. If anything, try to find wording
>> that says "today, most mappers prefer the X tag", but don't say "this
>> tag is deprecated" except in very clear circumstances, where an
>> overwhelming majority has actually decided that this tag should be
>> listed as "deprecated".
>>
>> Claiming something is "deprecated" should never be a silent side-effect
>> of some other vote.
>>
>> Bye
>> Frederik
>>
>> --
>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>

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

Re: [Tagging] Deprecation of non-approved values for diplomatic=?

[marc marc]

Le 14.06.19 à 15:10, Martin Koppenhoefer a écrit :
> we should be very reluctant to mark tags as deprecated (i.e. it  
> should happen after their usage significantly dropped

in French we say "c'est le chat qui se mord la queue"
tag use changes little as long as presets do not change.
presets sometimes don't change as long as the tag usage doesn't change

having a dual tag for the same meaning is a horror
- each datause must test both if they want to have all the data
- each contributor must add the 2 tags if he wants it to be used
by everyone
- each deletion of one of the 2 tags on an object is ambiguous: did the 
contributor mean that the attribute is deleted but forgot to delete the 
2nd or did he want to delete the tag he doesn't like ?
- somes publishers implement distributed mass publishing rules hidden
in the real changes of contributors.

I think the proposals for a new tag should clearly say:
- add such tag
- edit the old tag description to point the new tag
- write to editors to adapt presets
- propose a mecanical edit, if necessary by splitting it up
to avoid a global opponent blocking everything
- propose the depreciation of the old tag

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

Re: [Tagging] Tagging Digest, Vol 117, Issue 36

[Martin Koppenhoefer]

Am Do., 13. Juni 2019 um 10:43 Uhr schrieb Leif Rasmussen <354...@gmail.com
>:

> The main thing that is hard here is deciding at which width 1 lane becomes
> 2.  In the United States, unmarked roads are usually wide enough for 2 cars
> to easily pass each other, so are practically speaking 2 lanes.  Here in
> Europe, many rural roads are only wide enough for 1 car, meaning that a car
> must pull off the road in order to let another one pass.
>


for 2 lanes I would require two big vehicles can pass (at least by slowing
down) and 2 cars can pass without slowing down. If width is below, I am
using 1.5 as lanes value. I am not the only one, but it isn't widely
established either: https://taginfo.openstreetmap.org/keys/lanes#values
Standard vehicles can typically (?) be up to 2.50 m wide, which means the
road must have a width of at least 5.5-6m in order to be 2 lanes. Cars are
typically between 1,60 and 2m wide.

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

[Tagging] Feature Proposal - Voting - Tag:tourism=camp_pitch

[Joseph Eisenberg]

The proposal for the feature tag tourism=camp_pitch is now open for voting.

This is a follow-up to the rejected proposal for camp_site=camp_pitch

The proposed tag tourism=camp_pitch provides a way to tag individual
pitches within a campsite (a.k.a. "campground" in American English) or
caravan site ("RV Park, American English).

A "camp pitch" in this context is the free space used to place a tent
or or caravan within a tourism=camp_site or tourism=caravan_site area.
The pitch must be located within an area tagged with one of these two
existing tags.

This proposal would deprecate the currently in-use tags
camp_site=camp_pitch and camp_site=pitch, preferring instead
tourism=camp_pitch

Please read the proposal and vote:
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:tourism%3Dcamp_pitch

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

[Tagging] extend unsigned key to describe "no info on the ground" for a key

[marc marc]

Hello,

Le 13.06.19 à 15:15, Tobias Zwick a écrit :
> it semantically refers to the <...> key
it is a problem common to many keys but there is no overall coherence.

extend unsigned used for name with unsigned=
is easy to make a link betweeen the key and "no info on the ground".

it avoids:
- using funny no*=yes
- inconsistency (namespace <> underscore <> no <> ..) between usecase
- to be generalizable : any key can be filled in this way without having 
to discuss the value of the key and without having to code/learn
a "matching table".

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

Re: [Tagging] Deprecation of non-approved values for diplomatic=?

[Martin Koppenhoefer]

Am Fr., 14. Juni 2019 um 13:40 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> Right.
>
> By "deprecated" this is what I mean: should the wiki pages be changed
> to make it clear that diplomatic=honorary_consulate is no longer
> preferred, and could be changed to diplomatic=consulate +
> consulate=honorary_consulate ?



could be ok in this case (actually much more ok than listing
amenity=embassy with its stable 11000+ uses as deprecated).
It seems a bit strange there are only 1447 office=diplomatic but 5500
diplomatic=*, seems the office key isn't needed here.

Generally I agree with Frederik, we should be very reluctant to mark tags
as deprecated (i.e. it should happen after their usage significantly
dropped in favor of another tag, not for cases where the usage is stable or
still raising, and multiples of the alternative tagging).

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

Re: [Tagging] Feature Proposal - Voting - Tag:tourism=camp_pitch

[marc marc]

Le 14.06.19 à 16:34, Joseph Eisenberg a écrit :
> The proposal for the feature tag tourism=camp_pitch is now open for voting.
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:tourism%3Dcamp_pitch

I hope that the size of the proposal and its ambiguity will not harm it 
(it is presented as a vote for a new tag but not new when it aims
to depreciate 2 conflicting tags).
fortunately I am for both (the new tag and the depreciation
of the 2 conflicting tags): -D
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=cannabis including medical cannabis

[marc marc]

Le 14.06.19 à 18:26, Jmapb a écrit :
> the subtags cannabis:medical and cannabis:recreational are proposed

or usage=medical|recreational
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=cannabis including medical cannabis

[Mark Wagner via Tagging]

Not in most parts of the world where medical cannabis is sold.  In most
places, medical cannabis is in a legal grey area, and no reputable
pharmacy would risk its license by dispensing something that is still
on the books as an illegal drug.

-- 
Mark

On Fri, 14 Jun 2019 19:15:14 +0200
Tobias Zwick  wrote:

> Wouldn't medical cannabis be sold in pharmacies?
> 
> On 14/06/2019 18:26, Jmapb wrote:
> > An accepted answer to a recent question on help.openstreetmap.org (
> > https://help.openstreetmap.org/questions/69593/how-to-tag-a-medical-cannabis-dispensary
> > ) suggested expanding the definition of shop=cannabis to include
> > dispensaries for medical cannabis.
> > 
> > This makes sense to me, and the original discussion (
> > https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/shop%3Dcannabis
> > ) doesn't really give any clear reason for excluding medical
> > cannabis shops. (In fact, the subtags cannabis:medical and
> > cannabis:recreational are proposed and not disputed.)
> > 
> > I'm inclined to go ahead and edit the shop=cannabis wiki page (also
> > take out some of the verbiage... the history in Colorado is
> > interesting but not really relevant to the map) but I'd first like
> > to fish for objections. (Agreement also welcome!)
> > 

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

Re: [Tagging] Deprecation of non-approved values for diplomatic=?

[Lionel Giard]

The editor presets are already changed (so any modification or new creation
of embassy, consulate or liaison use the new tagging scheme). The number of
diplomatic=* tag compared to the number of office=* tag is due to the fact
that the "diplomatic"=* tag was already existing but used slightly
differently and without any consensus. The new scheme is just a refinement
to better represent what it is.

After the proposal was accepted, the old main tag amenity=embassy was added
to the deprecated value. But it didn't mention diplomatic values used as it
was never properly referenced anywhere at this time ! ;-)
As usual, we don't massively change the objects tagged with a deprecated
value, as we need an human review to check whether it is still correct to
tag this object as embassy or consulate...
So it will change with time and become more and more prevalent, but it
takes time. We could always makes some sort of challenge by country to
check the embassy/consulate/... to speed things up. And I suppose that
adding the note on the wiki for diplomatic values will help and reflect
what is already applied in editor presets ?!


Le ven. 14 juin 2019 à 17:51, marc marc  a
écrit :

> Le 14.06.19 à 15:10, Martin Koppenhoefer a écrit :
> > we should be very reluctant to mark tags as deprecated (i.e. it
> > should happen after their usage significantly dropped
>
> in French we say "c'est le chat qui se mord la queue"
> tag use changes little as long as presets do not change.
> presets sometimes don't change as long as the tag usage doesn't change
>
> having a dual tag for the same meaning is a horror
> - each datause must test both if they want to have all the data
> - each contributor must add the 2 tags if he wants it to be used
> by everyone
> - each deletion of one of the 2 tags on an object is ambiguous: did the
> contributor mean that the attribute is deleted but forgot to delete the
> 2nd or did he want to delete the tag he doesn't like ?
> - somes publishers implement distributed mass publishing rules hidden
> in the real changes of contributors.
>
> I think the proposals for a new tag should clearly say:
> - add such tag
> - edit the old tag description to point the new tag
> - write to editors to adapt presets
> - propose a mecanical edit, if necessary by splitting it up
> to avoid a global opponent blocking everything
> - propose the depreciation of the old tag
>
> Regards,
> Marc
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=cannabis including medical cannabis

[Jmapb]

On 6/14/2019 1:15 PM, Tobias Zwick wrote:

Wouldn't medical cannabis be sold in pharmacies?


The world is vast and diverse, so I imagine the answer is yes. But in
the places I map most (USA), medical cannabis is sold in single-purpose
shops called dispensaries, which do not stock any other medicines.
Calling them pharmacies would be a form of "troll tagging."

(Of course a pharmacy that does sell cannabis, wherever and whenever
that exists, could be tagged cannabis=yes or cannabis:medical=yes.)

J


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

Re: [Tagging] shop=cannabis including medical cannabis

[Jmapb]

On 6/14/2019 2:12 PM, Dave Swarthout wrote:


I strongly agree that the Wiki should be updated to include the tags
already in use for medical and recreational use of marijuana. I'm
don't understand why the Wiki authors made it so restrictive in the
first place.

Furthermore, in the U.S. normal pharmacies do not, AFAIK, sell
cannabis.


Thanks. FYI many pharmacies in my area (NYC) have started selling CBD
products, no prescription needed. It seems to be more or less
unregulated at the moment. (Technically it depends on exactly which
species of plant is the source.)

There's also one shop I know that's explicitly only for CBD, which I've
tagged as shop=cannabis + cannabis:cbd=only. (Strict adherence to the
"don't use abbreviations in tags" rule would suggest tagging
cannabis:cannabidiol=only instead, but literally nobody calls it that,
or knows how to spell it. Plus it probably has an extra vowel or two in
British.)

J


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

Re: [Tagging] shop=cannabis including medical cannabis

[Dave Swarthout]

I strongly agree that the Wiki should be updated to include the tags
already in use for medical and recreational use of marijuana. I'm don't
understand why the Wiki authors made it so restrictive in the first place.

I also agree that these dispensaries are merely special purpose shops and
not pharmacies. Furthermore, in the U.S. normal pharmacies do not, AFAIK,
sell cannabis. I suggest:

cannabis:medical=yes/only
cannabis:recreational=yes/only

Using these optional tags, shops that sell only medical or only
recreational cannabis can be better distinguished.

Also, agree that the verbiage about Colorado could be removed.

Thanks,

Dave

On Fri, Jun 14, 2019 at 9:49 AM Jmapb  wrote:

> On 6/14/2019 1:15 PM, Tobias Zwick wrote:
> > Wouldn't medical cannabis be sold in pharmacies?
>
> The world is vast and diverse, so I imagine the answer is yes. But in
> the places I map most (USA), medical cannabis is sold in single-purpose
> shops called dispensaries, which do not stock any other medicines.
> Calling them pharmacies would be a form of "troll tagging."
>
> (Of course a pharmacy that does sell cannabis, wherever and whenever
> that exists, could be tagged cannabis=yes or cannabis:medical=yes.)
>
> J
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=cannabis including medical cannabis

[Paul Allen]

On Fri, 14 Jun 2019 at 19:13, Dave Swarthout 
wrote:

>
> Furthermore, in the U.S. normal pharmacies do not, AFAIK, sell cannabis.
>

Yet.  I'd expect that in some jurisdictions pharmacies will eventually sell
medicinal cannabis,
if only on prescription.  I'd expect that eventually, in some
jurisdictions, other outlets licensed to
sell alcohol and/or tobacco will be licensed to sell cannabis.  It's only a
matter of time.

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

[Tagging] Ho to tag the position of objects on highways

[Volker Schmidt]

If I have an object on a highway, like a manhole on a road, or a traffic
sign pole or lamp post on a footway, how do I map this object, when it is
not on the centreline of the road or footway (and without mapping the
highway as an area).
Here   is a nice
example of three objects on a combined foot-cycle-way with more ore less
the same longitudinal position (with respect of the way that represents it
in OSM).

Volker


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] shop=cannabis including medical cannabis

[Jmapb]

An accepted answer to a recent question on help.openstreetmap.org (
https://help.openstreetmap.org/questions/69593/how-to-tag-a-medical-cannabis-dispensary
) suggested expanding the definition of shop=cannabis to include
dispensaries for medical cannabis.

This makes sense to me, and the original discussion (
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/shop%3Dcannabis
) doesn't really give any clear reason for excluding medical cannabis
shops. (In fact, the subtags cannabis:medical and cannabis:recreational
are proposed and not disputed.)

I'm inclined to go ahead and edit the shop=cannabis wiki page (also take
out some of the verbiage... the history in Colorado is interesting but
not really relevant to the map) but I'd first like to fish for
objections. (Agreement also welcome!)

Thanks, Jason


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

Re: [Tagging] shop=cannabis including medical cannabis

[Tobias Zwick]

Wouldn't medical cannabis be sold in pharmacies?

On 14/06/2019 18:26, Jmapb wrote:
> An accepted answer to a recent question on help.openstreetmap.org (
> https://help.openstreetmap.org/questions/69593/how-to-tag-a-medical-cannabis-dispensary
> ) suggested expanding the definition of shop=cannabis to include
> dispensaries for medical cannabis.
> 
> This makes sense to me, and the original discussion (
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/shop%3Dcannabis
> ) doesn't really give any clear reason for excluding medical cannabis
> shops. (In fact, the subtags cannabis:medical and cannabis:recreational
> are proposed and not disputed.)
> 
> I'm inclined to go ahead and edit the shop=cannabis wiki page (also take
> out some of the verbiage... the history in Colorado is interesting but
> not really relevant to the map) but I'd first like to fish for
> objections. (Agreement also welcome!)
> 
> Thanks, Jason
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] A modest proposal to increase the usefulness of the tagging list

[bkil]

On Wed, Jun 5, 2019 at 6:05 AM John Willis via Tagging
 wrote:
> On Jun 4, 2019, at 2:40 PM, Mateusz Konieczny  wrote:
>
> Or you will use.
> Thanks for handling man_made bridge. I use it a lot.
>
> The only comment to this idea of “make tags for you to use” is that if you 
> invent a tagging method for a particular type of object, that you include 
> similar objects that people would like to map to avoid tag fragmentation.
>
> If you propose amenity=foobar, I expect you to consider a subtag like 
> foobar=* or foobar:type=* to be able to define different types of the foobar 
> people encounter.
>
> if you are proposing a new tag foo_bar=* to handle x, y, & z, I expect you to 
> consider l,m,n,o & p as well - even if you don't use them -  because trying 
> to get them “approved” later is very difficult, and people will use incorrect 
> tags on objects just to complete mapping if that is the case.
>
> the Tagging mailing list extends the **tagging system**, It’s not just for 
> solving a single particular mapping issue for an individual.
>
> Tags can be extended later, but it means convincing people to support a 
> sinlge tag value they don't care about individually or don't understand the 
> usefulness of, when it probably would have easily been approved without 
> objection if it was included in the original proposal. the golf=cart_path 
> recently comes to mind.
>
> Javbw
>

Agreed on all points.

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

[Tagging] man-made missing-manhole mistery

[Volker Schmidt]

I stumbled upon this:
According to the manhole 
wikipage  "manhole=drain" has as a prerequisite "man_made=manhole"
BUT, according to taginfo, there are
10337 instances of " manhole=drain", but only 1809 instances of
"man_made=manhole"

Is it time to change the wiki page to describe the actual use or am I
missing something?

Volker


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=cannabis including medical cannabis

[Jmapb via Tagging]

On 6/14/2019 5:33 PM, Dave Swarthout wrote:


Martin wrote:

>It would imply adding shop=cannabis to pharmacies? In some countries
the sale of medicine is restricted to pharmacies.

Not necessarily. IMO, we could also use the cannabis:medical=yes/only
tag to pharmacies offering it.


Yes, my understanding is that shop=cannabis is only for shops whose sole
purpose (or at least clear primary purpose) is the sale of cannabis. It
shouldn't automatically be added to any POI where legal cannabis is
available.

A pharmacy that sells a variety of medicines should not be tagged as
shop=cannabis, but could still be tagged with cannabis:*=* (similar to
drink:wine=yes at shop=deli.)

IMO the shop=cannabis tag should not be used at all in any jurisdiction
where legal cannabis is only available through general purpose
pharmacies. (I don't know of any such places, but I assume they exist
somewhere, or will at some point.) And obviously it also shouldn't be
used in jurisdictions where all cannabis sales are illegal.

J


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

Re: [Tagging] Deprecation of non-approved values for diplomatic=?

[Joseph Eisenberg]

Some people disapprove of editing a database object without checking
if it still exists, because an edit implies that you have confirmed
that the information about the feature is still correct.

Back to the original question: should diplomatic=honorary_consulate
and the related tags be marked as deprecated on it's wiki page and on
the Key:diplomatic page?

On 6/15/19, marc marc  wrote:
> Le 14.06.19 à 21:26, Lionel Giard a écrit :
>> we need an human review
>
> I wonder what the added value to make a human review for changing
> diplomatic=honorary_consulate
> into
> diplomatic=consulate + consulate=honorary_consulate
>
> of course, some may be wrong, but this has nothing
> to do with the tag change
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Tagging] man-made missing-manhole mistery

[Joseph Eisenberg]

The page https://wiki.openstreetmap.org/wiki/Key:manhole implies that
manhole=drain is for manholes that provide access to an underground
"surface water drain for removing rainwater", so they should not be
the opening or grate for water.

However, I don't know if this is how the tag is actually used. It
would be good for someone to download the instances in their area and
and check vs aerial imagery or survey.

On 6/15/19, Graeme Fitzpatrick  wrote:

> manhole=drain for a storm water drain (opening / grate that allows heavy
> runoff from street gutters down into the storm water system) doesn't seem
> quite right to me, as a manhole is an access point for people to climb down
> into pipes etc.
>
> Have seen man_made=storm_drain in use which seems a better choice to me.
>
> Thanks
>
> Graeme
>

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

Re: [Tagging] lanes = 0

[Allroads]

First, the consensus in OSM is, that only the tag key  lanes=* is used, when 
there is are visual markings for lanes.
Then the question is, are there lanes? Yes or no. How many?

lane_marking= no, we agreed (OSM), when no visual lanes there are no lanes, 
lane_marking, it is referring to lanes, that are not there, so useless tag.

If lanes=no is not right, lanes=0 zero means, that there are no lanes, zero is 
nothing.
I tagged a few , as you named two way road with no lane marking lanes=1, they 
told me that is wrong, I agree, it have no lanes/rijstroken/fahrstreifen, 
retagged them.

Width tag is way to go. For roads without lanes.
Estimation is difficult, maybe one day Mapillary can measure the width of the 
road.
In JOSM you can measure the width of a road, drag a line and see width.

Some countries, Goverment produce open data, look or agree with them if you can 
use it in OSM. (lisence)
Here a third party, https://bgtviewer.nl/ visualise the data. We can use it. To 
realign roads.
(A lot of the data is measured in, correct) We can not do better ;-).

Wider use of  lanes. We can not do that.
Just read all the dictionaries, wikipedia, etc. according to lanes, it is 
always lanes/rijstrook/fahrstreifen (images with markings)
First these must be rewritten, global accepted. This is not happening.
So OSM stays, lanes are a part of a road with markings.

lanes= is used for lanes, when there are no lanes, there should me a 
possibility to give a tag, lanes= is used, either it is lanes=no or lanes=0.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecation of non-approved values for diplomatic=?

[Graeme Fitzpatrick]

On Sat, 15 Jun 2019 at 05:30, Lionel Giard  wrote:

> So it will change with time and become more and more prevalent, but it
> takes time. We could always makes some sort of challenge by country to
> check the embassy/consulate/... to speed things up.
>

Wouldn't / shouldn't the name show what it is?

They "should" all be named: "US Embassy", "French Consulate" etc, shouldn't
they?

Thanks

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

Re: [Tagging] Deprecation of non-approved values for diplomatic=?

[marc marc]

Le 14.06.19 à 21:26, Lionel Giard a écrit :
> we need an human review

I wonder what the added value to make a human review for changing
diplomatic=honorary_consulate
into
diplomatic=consulate + consulate=honorary_consulate

of course, some may be wrong, but this has nothing
to do with the tag change
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] lanes = 0

[Joseph Eisenberg]

This requirement is fine for Europe, but the presence of lane markings
is not reliable in all of the world.

In developing countries, such as here in Indonesia, the presence of
painted lane markings is inconsistent. Often cheap pain is used
instead of more durable thermoplastic, so the markings only last a
year. After that the road still functions the same, even though the
markings are no longer visible.

There are also sections of primary or trunk road that are at least 6
or 7 meters wide and freshly painted, but have not yet been marked and
may not be for a number of years. I tag these as lanes=2 because the
road is clearly wide enough for two lanes.

And here in town the main road was recently marked with 2 lanes in
each direction, but before it already functioned as 4 lanes because
the width was sufficient.

While tagging the width is useful, I believe tagging the presence of
"de facto" lanes is reasonable in developing countries and places
where painted lane markings are not frequently used.

On 6/15/19, Allroads  wrote:
> First, the consensus in OSM is, that only the tag key  lanes=* is used, when
> there is are visual markings for lanes.
> Then the question is, are there lanes? Yes or no. How many?
>
> lane_marking= no, we agreed (OSM), when no visual lanes there are no lanes,
> lane_marking, it is referring to lanes, that are not there, so useless tag.
>
> If lanes=no is not right, lanes=0 zero means, that there are no lanes, zero
> is nothing.
> I tagged a few , as you named two way road with no lane marking lanes=1,
> they told me that is wrong, I agree, it have no
> lanes/rijstroken/fahrstreifen, retagged them.
>
> Width tag is way to go. For roads without lanes.
> Estimation is difficult, maybe one day Mapillary can measure the width of
> the road.
> In JOSM you can measure the width of a road, drag a line and see width.
>
> Some countries, Goverment produce open data, look or agree with them if you
> can use it in OSM. (lisence)
> Here a third party, https://bgtviewer.nl/ visualise the data. We can use it.
> To realign roads.
> (A lot of the data is measured in, correct) We can not do better ;-).
>
> Wider use of  lanes. We can not do that.
> Just read all the dictionaries, wikipedia, etc. according to lanes, it is
> always lanes/rijstrook/fahrstreifen (images with markings)
> First these must be rewritten, global accepted. This is not happening.
> So OSM stays, lanes are a part of a road with markings.
>
> lanes= is used for lanes, when there are no lanes, there should me a
> possibility to give a tag, lanes= is used, either it is lanes=no or
> lanes=0.
>

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

Re: [Tagging] lanes = 0

[Warin]

+1 with Joseph

OSM is world wide. What is suitable in one place may not work in another.

The use of the tags should follow local customs, the presence of lanes should 
be judged by local customs,

in Australia they are legally required to be marked for multi lane roads, a 
road with a lane in each direction does not require markings.

Elsewhere in the world they not be marked but used as multiple lanes.

Tagging the presence/absence of lane markings looks to be a requirement for 
some.

It could be done as a country wide default, this could ease concerns of some.

I have seen one instance of lane=0 to mean that the 'road' is not wide enough 
for one lane...
lane=0 is undocumented and has been taken to mean different things by different 
people.

To me, lane=0 has no true meaning and indicates a problem.




On 15/06/19 09:10, Joseph Eisenberg wrote:

This requirement is fine for Europe, but the presence of lane markings
is not reliable in all of the world.

In developing countries, such as here in Indonesia, the presence of
painted lane markings is inconsistent. Often cheap pain is used
instead of more durable thermoplastic, so the markings only last a
year. After that the road still functions the same, even though the
markings are no longer visible.

There are also sections of primary or trunk road that are at least 6
or 7 meters wide and freshly painted, but have not yet been marked and
may not be for a number of years. I tag these as lanes=2 because the
road is clearly wide enough for two lanes.

And here in town the main road was recently marked with 2 lanes in
each direction, but before it already functioned as 4 lanes because
the width was sufficient.

While tagging the width is useful, I believe tagging the presence of
"de facto" lanes is reasonable in developing countries and places
where painted lane markings are not frequently used.

On 6/15/19, Allroads  wrote:

First, the consensus in OSM is, that only the tag key  lanes=* is used, when
there is are visual markings for lanes.
Then the question is, are there lanes? Yes or no. How many?

lane_marking= no, we agreed (OSM), when no visual lanes there are no lanes,
lane_marking, it is referring to lanes, that are not there, so useless tag.

If lanes=no is not right, lanes=0 zero means, that there are no lanes, zero
is nothing.
I tagged a few , as you named two way road with no lane marking lanes=1,
they told me that is wrong, I agree, it have no
lanes/rijstroken/fahrstreifen, retagged them.

Width tag is way to go. For roads without lanes.
Estimation is difficult, maybe one day Mapillary can measure the width of
the road.
In JOSM you can measure the width of a road, drag a line and see width.

Some countries, Goverment produce open data, look or agree with them if you
can use it in OSM. (lisence)
Here a third party, https://bgtviewer.nl/ visualise the data. We can use it.
To realign roads.
(A lot of the data is measured in, correct) We can not do better ;-).

Wider use of  lanes. We can not do that.
Just read all the dictionaries, wikipedia, etc. according to lanes, it is
always lanes/rijstrook/fahrstreifen (images with markings)
First these must be rewritten, global accepted. This is not happening.
So OSM stays, lanes are a part of a road with markings.

lanes= is used for lanes, when there are no lanes, there should me a
possibility to give a tag, lanes= is used, either it is lanes=no or
lanes=0.


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




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

Re: [Tagging] shop=cannabis including medical cannabis

[Martin Koppenhoefer]

sent from a phone

> On 14. Jun 2019, at 18:26, Jmapb  wrote:
> 
> An accepted answer to a recent question on help.openstreetmap.org (
> https://help.openstreetmap.org/questions/69593/how-to-tag-a-medical-cannabis-dispensary
> ) suggested expanding the definition of shop=cannabis to include
> dispensaries for medical cannabis.
> 
> This makes sense to me, and the original discussion (
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/shop%3Dcannabis
> ) doesn't really give any clear reason for excluding medical cannabis
> shops. (In fact, the subtags cannabis:medical and cannabis:recreational
> are proposed and not disputed.)


It would imply adding shop=cannabis to pharmacies? In some countries the sale 
of medicine is restricted to pharmacies.


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

Re: [Tagging] shop=cannabis including medical cannabis

[Dave Swarthout]

Martin wrote:

>It would imply adding shop=cannabis to pharmacies? In some countries the
sale of medicine is restricted to pharmacies.

Not necessarily. IMO, we could also use the cannabis:medical=yes/only tag
to pharmacies offering it.

On Fri, Jun 14, 2019 at 12:58 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 14. Jun 2019, at 18:26, Jmapb  wrote:
> >
> > An accepted answer to a recent question on help.openstreetmap.org (
> >
> https://help.openstreetmap.org/questions/69593/how-to-tag-a-medical-cannabis-dispensary
> > ) suggested expanding the definition of shop=cannabis to include
> > dispensaries for medical cannabis.
> >
> > This makes sense to me, and the original discussion (
> >
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/shop%3Dcannabis
> > ) doesn't really give any clear reason for excluding medical cannabis
> > shops. (In fact, the subtags cannabis:medical and cannabis:recreational
> > are proposed and not disputed.)
>
>
> It would imply adding shop=cannabis to pharmacies? In some countries the
> sale of medicine is restricted to pharmacies.
>
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] man-made missing-manhole mistery

[Graeme Fitzpatrick]

On Sat, 15 Jun 2019 at 06:11, Volker Schmidt  wrote:

> I stumbled upon this:
> According to the manhole 
> wikipage  "manhole=drain" has as a prerequisite "man_made=manhole"
> BUT, according to taginfo, there are
> 10337 instances of " manhole=drain", but only 1809 instances of
> "man_made=manhole"
>
> Is it time to change the wiki page to describe the actual use or am I
> missing something?
>

Are we even allowed to call them *man*holes? :-)

manhole=drain for a storm water drain (opening / grate that allows heavy
runoff from street gutters down into the storm water system) doesn't seem
quite right to me, as a manhole is an access point for people to climb down
into pipes etc.

Have seen man_made=storm_drain in use which seems a better choice to me.

Thanks

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

Re: [Tagging] Deprecation of non-approved values for diplomatic=?

[Warin]

On 15/06/19 08:57, Joseph Eisenberg wrote:

Some people disapprove of editing a database object without checking
if it still exists, because an edit implies that you have confirmed
that the information about the feature is still correct.


I usually check on a web page, most of them have a government web page giving 
details.



Back to the original question: should diplomatic=honorary_consulate
and the related tags be marked as deprecated on it's wiki page and on
the Key:diplomatic page?


No. Far too few uses to determine what would 'win out'.

 


On 6/15/19, marc marc  wrote:

Le 14.06.19 à 21:26, Lionel Giard a écrit :

we need an human review

I wonder what the added value to make a human review for changing
diplomatic=honorary_consulate
into
diplomatic=consulate + consulate=honorary_consulate


I see no advantage. But then I seldom use the services!

Possibly the services offered are so similar that when you want that service 
you are only interested in any type of consulate?

Need Alans expertise here?
If no one else has any idea I'll try to track him down.


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

Re: [Tagging] shop=cannabis including medical cannabis

[Dave Swarthout]

@Jmapb

I agree with all of your points.

Reiterating a bit: Using the cannabis:*.* tag to designate a place where
one can buy cannabis, be it a pharmacy or a shop=cannabis, or be it for
recreational or medical use, will go a long way toward making this scenario
both understandable and logical.

I wouldn't like using shop=cannabis with amenity=pharmacy on the same
object. No way. There would also be an ugly "tag collision" with
shop=chemist (whatever that is, LOL). IMO, it would be best to use the tag
of cannabis:medical=only for such dispensaries.

On Fri, Jun 14, 2019 at 2:56 PM Jmapb via Tagging 
wrote:

> On 6/14/2019 5:33 PM, Dave Swarthout wrote:
>
> > Martin wrote:
> >
> > >It would imply adding shop=cannabis to pharmacies? In some countries
> > the sale of medicine is restricted to pharmacies.
> >
> > Not necessarily. IMO, we could also use the cannabis:medical=yes/only
> > tag to pharmacies offering it.
> >
> Yes, my understanding is that shop=cannabis is only for shops whose sole
> purpose (or at least clear primary purpose) is the sale of cannabis. It
> shouldn't automatically be added to any POI where legal cannabis is
> available.
>
> A pharmacy that sells a variety of medicines should not be tagged as
> shop=cannabis, but could still be tagged with cannabis:*=* (similar to
> drink:wine=yes at shop=deli.)
>
> IMO the shop=cannabis tag should not be used at all in any jurisdiction
> where legal cannabis is only available through general purpose
> pharmacies. (I don't know of any such places, but I assume they exist
> somewhere, or will at some point.) And obviously it also shouldn't be
> used in jurisdictions where all cannabis sales are illegal.
>
> J
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Landuse=farmyard vs residential

[Paul Allen]

On Fri, 14 Jun 2019 at 03:04, John Willis via Tagging <
tagging@openstreetmap.org> wrote:

>
>
> > On Jun 13, 2019, at 4:22 PM, Paul Allen  wrote:
> >
> > Conversion of farm buildings to residential buildings is not only
> possible, it's frequent in
> > some parts of the world.
>
> Very true, but even a house or cottage inside a working farmyard would
> still be on a landuse mapped as a farmyard.


That's how I've handled it.

The building may no longer be =shed or farm_auxiliary,


I think you will find there is some dispute over that.  Some people would
insist that the building is
still a farm_auxiliary or cowshed or stable because building=* is meant to
describe physical
characteristics not usage.  I'm not a purist on the matter, but when I read
that a holiday cottage
is a converted stable, building=stable seems natural.


> but unless the activity of the farm ceases (and becomes merely a
> residential living area or a commercial resort), I think it would still be
> on a landuse=farmyard.
>

I'd generally agree.  If you can have tractors and muck-spreaders going
past your window all
day long, it's still a farmyard.  One exception I made is where part of the
farmyard has been
sold off with walls/fencing erected to separate it and each chunk of land
having its own
driveway.  In that particular case the split-off land has two holiday
cottages run by different
individuals than the farmer who has his own holiday cottage in a converted
building in the
farmyard.

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

Re: [Tagging] Deprecation of non-approved values for diplomatic=?

[Frederik Ramm]

Hi,

in general, I try to avoid marking anything as deprecated. I think the
term only gives people wrong ideas. If anything, try to find wording
that says "today, most mappers prefer the X tag", but don't say "this
tag is deprecated" except in very clear circumstances, where an
overwhelming majority has actually decided that this tag should be
listed as "deprecated".

Claiming something is "deprecated" should never be a silent side-effect
of some other vote.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Tagging] Deprecation of non-approved values for diplomatic=?

[Warin]

On 14/06/19 20:06, Joseph Eisenberg wrote:

I was checking the pages related to the office=diplomatic proposal,
which approved the tags diplomatic=embassy, diplomatic=consulate and
diplomatic=liaison - I just made pages for these 3 tags and added
=liaison to the key:diplomatic page.

Based on the proposal, I suspect that the other values could be marked
as deprecated, but I'm not sure if this was clear enough during the
proposal process. Do others agree that tags like
diplomatic=honorary_consulate should be listed as deprecated, replaced
by consulate=honorary_consulate (for example)?

- Joseph


Link  https://wiki.openstreetmap.org/wiki/Key:diplomatic

Taginfo https://taginfo.openstreetmap.org/keys/diplomatic#values

Usage

diplomatic=honorary_consulate ~450
consulate=* ~190 ..

Clearly the consulate key lacks use. And there is no wiki page for it... I see 
no point in making this key?
diplomatic=consulate was an older part of the now approved office=diplomatic .. 
as such it is not approved!
There are several iterations of the proposal. It is only the final version that 
has been approved.

-

Editorials.. to the wiki page https://wiki.openstreetmap.org/wiki/Key:diplomatic

I have removed duplication of amenity=embassy from the 'usefull combination' 
but have left it in the 'requires' section.

Moved office=diplomatic to 'requires' section.

I think at the moment both of these tags are 'required' when using the key 
diplomatic=*, not just a 'useful combination'.

Reinstated to the 'usefull combination' ; sending and receiving countries. Both 
of these could be usefull with the key diplomatic=*.


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

Re: [Tagging] Deprecation of non-approved values for diplomatic=?

[Lionel Giard]

I think that the only deprecated tag in the accepted proposal is
"amenity=embassy" (which is indicated on the wiki page too).

The wrong diplomatic value are just what old tagging scheme lead to. It
doesn't need to be deprecated to me as it never existed officially (i
think) - and it will probably be fixed at some point in the future when
contributor update the embassy/consulate/...

The only action i would take is to *add the note on the wiki page of
"diplomatic=*" for each of the "non-approved" value*, where we specifically
tell what is the new approved *sub-tag* (so people know that there is an
alternative). Like for "diplomatic=honorary_consulate", note in the
description that it could be tagged as "diplomatic=consulate" +
"consulate=honorary_consul" with the new tagging scheme.

Regards,

Le ven. 14 juin 2019 à 12:32, Frederik Ramm  a écrit :

> Hi,
>
> in general, I try to avoid marking anything as deprecated. I think the
> term only gives people wrong ideas. If anything, try to find wording
> that says "today, most mappers prefer the X tag", but don't say "this
> tag is deprecated" except in very clear circumstances, where an
> overwhelming majority has actually decided that this tag should be
> listed as "deprecated".
>
> Claiming something is "deprecated" should never be a silent side-effect
> of some other vote.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] lanes = 0

[Tobias Zwick via Tagging]

Ok so to recap. All fairly weak reasons (except 2) here, but let's find the 
best tag:

1. Allroads did not favour nolanes=yes because it is a double negative

2. lanes=no is not so good because there are people who estimate the lanes 
value if no markings are present (see ael's message). Adding "no" as a possible 
value that is to be applied when no visual markings are present would make a 
portion of the currently tagged lanes-tags wrong and thus would be a 
redefinition of the lanes key.

3. lane_marking=no has of the proposed tags the least semantic similarity to 
the lanes tag but on the other hand is used a few times already and is safe for 
the "_" instead of the ":" what Warin suggested

4. lanes:mark...=no would maybe imply that lanes=X must be tagged as well?

On 13/06/2019 15:15, Tobias Zwick wrote:
>> I think a tag to say "lane:marking=no" could be better for that situation???
> 
> 1. or lanes:marked=no? (mark_ed_ instead of mark_ing_)
> 
> Would be (more) consistent with the naming of opening_hours:signed, 
> collection_times:signed, (1k-2k usages each)
> 
> 2. or nolanes=yes?
> 
> Would be consistent with noname=yes, noaddress=yes, ...
> 
> 3. or lane_marking=no? I found this on taginfo, it has 90 usages. Personally, 
> I like either 1 or 2 better though.
> 
> Point 1 and your (Warin's) suggestion have the advantage that it semantically 
> refers to the lanes-key. Though on the other hand, would that imply that 
> lanes=X should always be tagged if lanes:marked=no is tagged?
> 
> Cheers
> Tobias
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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

[Tagging] Deprecation of non-approved values for diplomatic=?

[Joseph Eisenberg]

I was checking the pages related to the office=diplomatic proposal,
which approved the tags diplomatic=embassy, diplomatic=consulate and
diplomatic=liaison - I just made pages for these 3 tags and added
=liaison to the key:diplomatic page.

Based on the proposal, I suspect that the other values could be marked
as deprecated, but I'm not sure if this was clear enough during the
proposal process. Do others agree that tags like
diplomatic=honorary_consulate should be listed as deprecated, replaced
by consulate=honorary_consulate (for example)?

- Joseph

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