Re: [Tagging] Tagging venues which give away free condoms?

[marc marc]

or in stead of a full list of =yes
do the same as with vending=product1;product2
with a key like giving=* offering=*

Le 21.02.20 à 13:30, Florimond Berthoux a écrit :
> Hi,
> 
> condom=yes
> condom:fee=no
> 
> (condom is available here)
> (free condom, yeah!)
> 
> As I suggested in the free drinking_water thread, fee is already used a
> lot and has its wiki page.
> 
> 
> Le jeu. 20 févr. 2020 à 21:45, Rory McCann  > a écrit :
> 
> Hello fellow tagging fans,
> 
> 
> Some places give away free condoms to fight the spread of STDs (incl.
> HIV/AIDS). Is there a good way to map that in OSM?
> 
> I suggest `free:condoms=yes/no`, since it's descriptive, matches the
> `sells:X=yes/no` scheme. And the `vending:X=yes/no` scheme.
> `vending:condoms=yes/no` has 17 uses, but `vending=condoms` has 1800
> uses. "vending" implies a _machine_. But what I imagine is a place with
> a pile of free condoms ready to take. Either bars, or sexual health
> clinics might have this.
> 
> `free=condoms` doesn't read as obvious as `Free Condoms? Yes!"
> (`free:condoms=yes`). A tagging scheme which data consumers can easy
> "deduce" when a human reads the text is a good tagging scheme IMO.
> 
> There is `medical_service:condom_distribution=yes/no` with 94 uses,
> which reads too medical. A nighclub with a bowl of free condoms doesn't
> seem like a "medical service", and doesn't sound like a "distribution
> centre".
> 
> Clearly if the `free:condoms` tag is missing, you should presume it's
> the same a `free:condoms=no`.
> 
> Any feedback? Thoughts? (Hopes? Fears? Dreams? )
> 
> 
> -- 
> Rory
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> 
> -- 
> Florimond Berthoux
> 
> ___
> 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] Feature Proposal - RFC - Tag:amenity=motorcycle_taxi

[marc marc]

Le 20.02.20 à 12:45, Joseph Eisenberg a écrit :
> Can't we have an easy to use top-level feature tag, instead of having
> to add 3 tags like amenity=taxi + motorcar=no + motorcycle=yes to
> define one very common, unique feature?

did we need to have a top-level feature for every "unique" combination
of the same service ?
if yes, we need a lot of them
amenity=foot_taxi
amenity=moto_taxi
amenity=sidecar_taxi
amenity=taxi_low_local_pollution
amenity=taxi_powered_by_renewable_energy etc.
but all of these are part of the same type of service,
regardless of the number of wheels and the driving force.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] decide on a meaning for what is not documented [way: Expressway=yes/no versus new tags "dual_carriageway=yes/no", "limited_access=", "grade_separated"=?]

[marc marc]

Hello,

Le 20.02.20 à 07:41, Joseph Eisenberg a écrit :
> I've created a page for Key:dual_carriageway based on existing usage
> in the database:
> https://wiki.openstreetmap.org/wiki/Key:dual_carriageway

how did you proceed? is the tag added by only one contributor to whom
you asked the question to create the page based on his answer?
or did several contributors suing this tag answer consistently ?

Because I noticed it with the depreciation of the undocumented tag
camp_site=camp_pitch : when a tag is undocumented, the real meaning of
the objects in the database depends on what was going through the heads
of the different contributors (for this particular tag, we have found 5
meanings each used more than 100x and it took hours and numerous
messages to ).

The great advantage of an undocumented tag is that we know that the
meaning is not documented. the contributors aiming at quality can
therefore avoid it. the users of the data too.
Conversely, a tag documented "by hidden guessing" degrades the quality :
Some people will believe that this is really the meaning of the objects
in the database when it's only a guess. at the very least, it would
require a big banner "a contributor guess that the meaning of the tag"

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

Re: [Tagging] Tagging the presence or absence of signs for surveillance cameras

[marc marc]

Le 19.02.20 à 04:29, Victor/tuxayo a écrit :
> Coincidentally there was a recent discussion[2] about these signs in the
> french mailing list (talk-fr) which lead to adding the following section
> in the page
> https://wiki.openstreetmap.org/wiki/Tag:man_made=surveillance

I warn that this addition does not reflect the discussion that took
place on talk-fr, but is "self-declared as consensus"
more than half of the opinions are that a regulatory sign of this kind
is not tourist information (imho I think it is closer to a sign that
announces a pedestrian crossing or a maxspeed zone)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[marc marc]

On Fri, 7 Feb 2020 at 10:26, Christoph Hormann wrote:
> it would make a lot of sense for OSM-Carto to stop indicating this is valid 
> tagging.

it would make more sense to
1) decide what a valid/ideal schema is.
2) decide what a invalid/bad schema is.
3) making sure that the new schema is at least as well rendered in the
default style as the old one. if not, some mapper wouldn't move from
"it's rendered" to "not anymore"
4) propose a collective effort or automated edit to migrate from one to
the other
5) AFTER some time and/or after its use has strongly decreased, remove
the old schema from the default style.

of course, this implies that the tagging discussion takes place here and
the rendering takes place there, instead of the current bad-bad situation.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] barrier=hedge

[marc marc]

Le 07.02.20 à 13:59, Peter Elderson a écrit :
> intentionally mapped hedge areas. Not leisure/natural/landuse etc.

https://overpass-turbo.eu/s/Qwl exclude it
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Relation for multi-part artworks

[marc marc]

Le 06.02.20 à 13:20, Andy Mabbett a écrit :
> We could use relation_type:set

why not using relation type=site that already exist ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - give box

[marc marc]

the proposals (I'm talking generally, not just about this one) have
often 2 flaws:
- often too big (not this one)
- often rfc too short, even active people still have remarks to make
that the vote is already open, so they are stuck to sink the proposal
(with the risk that its author gets demotivated) or to accept it hoping
that the defects will be corrected later (which is always much more
difficult in the osm world).
with your opinion, I would have voted against it without hesitation.
because it's the best way to improve what you think should be improved.
i have in mind the proposal diaper<>changing table: totally ok for the
idea, i voted against the first version because of the negative elements
it contained.

Le 06.02.20 à 01:10, Joseph Eisenberg a écrit :
> Ok, so we should consider it approved in this case.
> 
> (For context, both Mateusz Konieczny and myself have abstained, along
> with 3 others, but had comments expressing concern about using
> "give_box" instead of "free_box" or something easier to understand.)
> 
> But hypothetically, what if there were even more comments expressing
> reservations. This time it was over 25%, but what if it was 40% or
> even 50%?
> 
> Since the idea of this process is to reach consensus about a tag,
> shouldn't critical comments be addressed by those voting "yes"?
> 
> One thing that might help would be to recommend a comment along with
> positive votes. Right now you can vote to approve without saying
> anything about the objections voiced, and the template suggest this is
> the usual way to do it.
> 
> This seems to put too much weight on the percentage of approved vs
> disapproved rather than the actual reasons for the votes.
> 
> - Joseph Eisenberg
> 
> On 2/6/20, Andrew Davidson  wrote:
>> On 6/2/20 4:02 am, Mateusz Konieczny via Tagging wrote:
>>> I see no good reason to count explicit "abstain but have comments"
>>> exactly like "vote against".
>>>
>>
>> +1
>>
>> To abstain from voting is to not cast a vote. So there were 14 votes
>> with just under 93% approving.
>>
>>
>> ___
>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[marc marc]

Le 05.02.20 à 22:08, Christoph Hormann a écrit :
> (either 'invalid', '1d barrier' or '2d barrier'):

Here is my view AND I known that osm consensus is not that :

> closed way, barrier=fence

1d barrier

> closed way, barrier=fence, area=yes

2d barrier

> closed way, barrier=fence, leisure=playground

bad idea

> closed way, barrier=fence, leisure=playground, area=yes

2d barrier

> multipolygon, barrier=fence

2d barrier

> multipolygon, barrier=fence, area=yes

2d barrier

> multipolygon, barrier=fence, leisure=playground

2d barrier

> multipolygon, barrier=fence, leisure=playground, area=yes

2d barrier

> closed way, barrier=hedge

1d barrier

> closed way, barrier=hedge, area=yes

2d barrier

> closed way, barrier=hedge, leisure=playground

2d barrier

> closed way, barrier=hedge, leisure=playground, area=yes

2d barrier

> multipolygon, barrier=hedge
> multipolygon, barrier=hedge, area=yes
> multipolygon, barrier=hedge, leisure=playground
> multipolygon, barrier=hedge, leisure=playground, area=yes

all : 2d barrier

> closed way, barrier=ditch, waterway=ditch
> closed way, barrier=ditch, waterway=ditch, area=yes
> closed way, barrier=ditch, waterway=ditch, leisure=playground
> closed way, barrier=ditch, waterway=ditch, leisure=playground, area=yes

all : same as for barrier=hedge
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[marc marc]

Le 05.02.20 à 18:41, Andy Townsend a écrit :
> On 05/02/2020 17:24, Christoph Hormann wrote:
> About the "removing tags where they may clash" point

> "if something is mapped as a brewery and also as
> tourist attraction, remove the tourist attraction tags

if osm-carto goal is to trying to give a feedback to mapper,
I'm more fan for a tule "fill it with a flashing red and don't render
any other tag" :)

of course, it need that an alternative exist (mapping 2 objets, one for
the area, another for the barrier is fine, but does a style use it ?
another alternative is to use a subtag, for ex fenced=* oups no,
it's deprecated
https://wiki.openstreetmap.org/wiki/Key:fenced
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] the current situation of camp_site=camp_pitch

[marc marc]

Hello,

Some time ago, the proposal of tourism=camp_pitch was approved in order
to respect/return to the initial meaning of camp_site=* (the level of
infrastructure of a tourism=camp_site).
This involved a lot of work in reviewing site by site existing objects
to migrate them to the new scheme.

this has the perverse effect of bringing out even more tag errors on
objects remaining with camp_site=camp_pitch
A large number of the remaining objects are indeed either
tourism=camp_site camp_site=basic or impromptu, or duplicates of them
an example https://www.openstreetmap.org/node/5069983850

As a result, the old documentation of camp_site=camp_pitch introduces
people in error, some people think it is wrong to correct a
camp_site=camp_pitch other than with tourism=camp_pitch
I therefore modified the page to talk about the historical meaning that
melted <> the most common errors/meaning of the remaining objects
I also add on the page tourism=camp_pitch the frequent errors that
I had already documented on the French page.

a rereading and improved wording are welcome :)
https://wiki.openstreetmap.org/wiki/Tag:camp_site=camp_pitch
https://wiki.openstreetmap.org/wiki/Tag:tourism=camp_pitch

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

Re: [Tagging] road names and refs

[marc marc]

Le 30.01.20 à 23:51, Warin a écrit :
> comment=local name is used verbally, not on signs as yet.'

unsigned=name or unsigned=yes
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecate healthcare=pharmacy and healthcare=hospital

[marc marc]

Le 28.01.20 à 13:45, Joseph Eisenberg a écrit :
> I think it would be reasonable to show healthcare=pharmacy,
> healthcare=hospital, healthcare=dentist and healthcare=doctor as
> discouraged and unnecessary in the wiki.

you take 2 tags out of their context, these 2 tags have their logic in
the hope of one day migrating health in their own namespace (as is done
with power=* for example) which has the merit of consistency even if we
know the inertia of the community to migrate.
Ideally, someone should take up the proposal on this subject again to
try to validate everything that can be validated. This would give more
weight and coherence.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Disputed territory mapped as a country

[marc marc]

Le 27.01.20 à 17:07, Захаренков Алексей a écrit :
> https://www.openstreetmap.org/relation/10629103
> Me and the changeset author could not come to agreement 

nobody ca have an agreement with him.
that isn't a country there. if p_v doesn't stop,
ask DWG for a ban
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] a kind of name:XX-modern-not-used

[marc marc]

Hello,

some words in the name of some street is not understood by some people.
these are often old notations, sometimes borrowed from another language
but used in the official language to name this street.
street sign have those "one-name-but-in-mixed-language" and only that.

a contributor spends time trying to find the meaning of these words and
replaces the name with a modern version, absent both from the ground and
from use, in favour of a name that is the one that could have been
written if this street had been created today.
it's a bit as if this contributor added to Big Ben name:fr="Grand Ben"
or "Nouveau York" for "New York"
it's obviously wrong. but how could we keep track of the meanings
of the words from the old days?
I thinking about a kind of tag name:fr-modern-not-used or a kind of
name:etymology but which does not inform a person but an object, a
building, a profession, ...

Any ideas?

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

Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

[marc marc]

I'm using operation_status when I see a such one.
and I'm trying to survey again later to see if it was a temporary
problem or if it's disused:
but to switch to disused: if there's no water on the day of the survey,
I think that's excessive.

Le 20.01.20 à 15:59, European Water Project a écrit :
> Dear Martin,
> 
> Wouldn't it make more sense for mappers to tag status=broken or
> status=out_of_order instead of deleting ?
> 
> best regards,
> 
> Stuart 
> 
> On Mon, 20 Jan 2020 at 15:53, Martin Koppenhoefer
> mailto:dieterdre...@gmail.com>> wrote:
> 
> Am Do., 16. Jan. 2020 um 03:16 Uhr schrieb Jarek Piórkowski
> mailto:ja...@piorkowski.ca>>:
> 
> Ah, good point! So I guess for a drinking fountain seasonal=yes
> is the
> most reasonable when I don't know the months when it's active
> (I'm in
> a climate that freezes, so they get shut down sometime before that).
> That's decently human-readable and I'd guess most people will guess
> right when informed that the fountain is "seasonal".
> 
> Unfortunately I've just now started noticing that these are shut off
> and while I guess they were actually shut down closer to November...
> 
> 
> 
> it is complicated. Last time when most drinking fountains in Rome
> were shut down was about 2 years ago in a dry period in the summer
> (as a side note and very unfortunately, some mappers have deleted
> the whole thing in this time just because the (internal) tap was
> closed for some weeks). So the reason for seasonal availability
> could be various, from shutting them in winter for frost protection
> to shutting them in the summer for saving resources in a drought.
> 
> Cheers
> Martin
> ___
> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] building=disused

[marc marc]

Le 17.01.20 à 02:49, Joseph Eisenberg a écrit :
>>>  I'm unsure why Carto ignores such a popular tagging scheme.
>>>
>> Is it actually popular?
> 
> The place to request changed to Openstreetmap-carto is
> http://github.com/gravitystorm/openstreetmap-carto/issues
> 
> According to taginfo, there are a total of 11,158 occurence of
> disused:man_made and disused:building http://overpass-turbo.eu/s/POy
> vs
> 27,446 uses of man_made=* and building=* with disused=yes:
> http://overpass-turbo.eu/s/POz
> 
> So the "disused=yes" form is 2.5 times more popular for these
> features.

the issue with disused=yes on building is http://overpass-turbo.eu/s/PPd
1166 building + amnenity + disused=yes (same issue with shop)
what's the meaning ?
the amenity is disused and it's better to fix amenity=* with
disused:amnenity=* ?
the building was disused and after a new amenity was added and the
mapper forget (or don't known) to remove disused=yes ?

Replacing disused=yes with building:use=no/vacant or disused:amnenity=*
depending on the context would at least make it possible to know the tag
concerned by the disused information
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Tax free shopping

[marc marc]

Le 17.01.20 à 12:48, Hauke Stieler a écrit :
> A shop at an airport where travelers generally pay no taxes would be
> tagged with "duty_free=yes" and optionally with "duty_free:refund=no".
> 
> I hope this also makes sense to you.

no, sorry.
I don't see the advantage of using 2 keys when only one is enough to
describe the situation about taxes (don't pay, pay and get help for the
refund, pay without help for the refund).

by anolgy with the wheelchair key, it's as if we had created
wheelchair:assisted=yes/no or wheelchair:limited=yes/no instead
of wheelchair=limited

if you dislike duty_free=limited, maybe duty_free=refund
is more understandable
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Tax free shopping

[marc marc]

Le 17.01.20 à 01:32, Hauke Stieler a écrit :
>> I see 3 levels :
>> the customer doesn't pay the tax duty_free=yes
>> the customer pay the tax but the shop help for a refund
>> the customer pay the tax and the shop doesn't help a refund duty_free=no
> 
> Exactly, this is the basic idea for the scheme (added these points to
> the wiki page). There might be some special cases, but they're probably
> very rare.

if so, the level between =no and =yes is imho better tagged
with duty_free=limited like it exist for wheelchair.
it would avoid having incompatible combinations between 2 tags (like
duty_free=yes duty_free:refund=yes... you can't get help for a refund if
you didn't pay the tax at all)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Disused/abandoned bunkers (was Re: building=disused)

[marc marc]

Le 17.01.20 à 09:58, Marc Gemis a écrit :
> abandoned:military=bunker
> + building=bunker

that look fine for me.

> Not sure about the ruins:building

I have never yet seen a building=bunker in ruins because of the mass
of concrete used, but if structurally one of them is a ruin and not
a bunker anymore, it would seem correct to me

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

Re: [Tagging] Question about capacity:*=* on parking_space

[marc marc]

Le 17.01.20 à 09:36, Lionel Giard a écrit :
> What do you think about this?

keep simple.
if a parking space is only for disabled ppl with access restriction,
why not using capacity=* on it ?
it's not wrong but useless to use namespace capacity:disable=*
in this case.
especially since capacity:disabled=1 doesn't say it's reserved for the
disabled, it just says there's a place for them (you can use an object
parking_space for an entire row)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Tax free shopping

[marc marc]

Le 17.01.20 à 00:51, Hauke Stieler a écrit :
>> about : duty_free:refund=yes
>> is it an intermediate level between duty_free=yes and duty_free=no ?
>> if yes, wouldn't it be better to use duty_free=limited ?
> I wouldn't say "duty_free:refund=yes" is something in between
> "duty_free=yes" and "=no" but rather a different type of duty_free-ness.

I see 3 levels :
the customer doesn't pay the tax duty_free=yes
the customer pay the tax but the shop help for a refund
the customer pay the tax and the shop doesn't help a refund duty_free=no
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Tax free shopping

[marc marc]

about : duty_free:refund=yes
is it an intermediate level between duty_free=yes and duty_free=no ?
if yes, wouldn't it be better to use duty_free=limited ?

about "global_blue" and the following : what is that ?
maybe add a link.

Le 16.01.20 à 21:28, Hauke Stieler a écrit :
> Hi,
> 
> just a reminder, that the proposal "tax_free_shopping" [0] is still in
> the state "proposed". However, I'd like to start voting soon, so please
> take a look at the proposal and let me know if something needs to be
> changed.
> 
> Hauke
> 
> [0] https://wiki.openstreetmap.org/wiki/Proposed_features/tax_free_shopping
> 
> On 04.01.20 19:47, Hauke Stieler wrote:
>> Hi,
>>
>> you may noticed the discussion "Tag for 'tax free shopping'" on this
>> mailing list. This is the proposal for the new "duty_free" tag.
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/tax_free_shopping
>>
>> Basically the new tag has three values:
>>
>> * yes:
>> This shop does not collect taxes at all. This usually happens at
>> airports in "duty-free stores".
>>
>> * refund:
>> For shops outside an airport. Foreign travelers shopping in a shop with
>> duty_free=refund can get an additional receipt which can be -- e.g.
>> later at the airport -- exchanged so that the traveler gets the taxes back.
>>
>> * no:
>> All customers of a shop with duty_free=no have to pay normal taxes.
>>
>> Feel free to comment :)
>>
>> Hauke
>>
>>
>> ___
>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] was: on poi (was: building=disused)

[marc marc]

On 14/01/2020 19:02, Markus wrote:
> was:shop=supermarket

Le 16.01.20 à 12:34, Marc M. a écrit :
> I'm also using was: because I don't care and often don't known
> if a poi is destroyed, dismantled, demolished, moved, the only
> thing I can see is that it's gone.

Le 16.01.20 à 12:53, Dave F via Tagging a écrit :
> Well. Done. You.

On 16/01/2020 12:01, marc marc wrote:> you want me to believe that every
time an object has gone,
Le 16.01.20 à 14:26, Dave F via Tagging a écrit :

> It's not gone. We're talking about buildings 

I have put back above the line to which I replied
and which  makes your answer wrong.
in case of a was:SHOP=*, the previous shop (what's inside
the building) has gone. and if you are consistent with yourself (you say
that osm is not a database for memorizing history) when I survey it,
the only thing I see is that the previous store was not there anymore.
it's why I and some others use was:shop=oldvalue + shop=newvalue
it is usefull to warn the next mapper about a recent change.

the current discussion with disused shows that there are 2 meanings :
still exists but not used <> doesn't exist anymore. was: has the merit
to be clear that what is described doesn't exist anymore, no matter how
it happened.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] building=disused

[marc marc]

Le 16.01.20 à 12:53, Dave F via Tagging a écrit :
> On 16/01/2020 11:34, marc marc wrote:
>> I'm also using was: because I don't care 
> 
> Well. Done. You.

you want me to believe that every time an object has gone,
you make an enquiry to find out how it disappeared ?
I did this at first, before realizing that there is no known case of use
that differentiates between different life cycle tags for a poi that has
gone.
The only thing that is useful is to avoid that the next contributor adds
again the previous tags with an older source than mine.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] building=disused

[marc marc]

I'm also using was: because I don't care and often don't known if a poi
is destroyed, dismantled, demolished, moved, the only thing I can see is
that it's gone.
f.e. a room whose store type has changed doesn't fit my description of
disused:

Le 16.01.20 à 12:16, Dave F via Tagging a écrit :
> You're using was: to represent the same meaning as disused:, so why not
> use the far more popular latter one?
> 
> On 14/01/2020 19:02, Markus wrote:
>> was:shop=supermarket
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

[marc marc]

Le 16.01.20 à 02:52, Joseph Eisenberg a écrit :
> The simple "seasonal=yes/no" is at least clear, though with natural
> features "intermittent=yes/no" is more common and has a similar
> meaning.

I see a big difference between the two:
an intermittent water point provides water today but not tomorrow but
again the day after tomorrow depending mostly on the precipitation of
the previous days.
A seasonal water supply point provides water every day in the summer,
for example, and no day during the frost period.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

[marc marc]

Le 15.01.20 à 16:15, Jmapb via Tagging a écrit :
> On 1/15/2020 12:55 AM, European Water Project wrote:
>> Would it be appropriate to use the tag "seasonal" for a water fountain
>> (whether tagged as "amenity=drinking_water" or "amenity = fountain and
>> drinking_water = yes" )?
> 
> Don't forget about man_made=drinking_fountain!

omg, what's the diff with amenity=drinking_water ?
the direction of water flow upwards?
348 out of 371 objects also have an amenity tag, which
shows the problem.

it would indeed be a good idea not to forget it and to ask the user if
it is a fountain in the osm sense (a bit artistic) or a water jet. and
add the most current tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

[marc marc]

Le 15.01.20 à 06:55, European Water Project a écrit :
> Would it be appropriate to use the tag "seasonal" for a water fountain

yes I think so.
I'm going to check/survey the nearby fountains: some are closed
in winter but don't have a precise opening/closing date.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] distance_from_road tag

[marc marc]

Of course this tag is a bad idea, which duplicates existing information
in osm and is therefore a source of conflict when one of the 2 data is
capitalized and not the other one.

if not, what next ?
distance_from_bus_stop ?
distance_from_tram_stop train station pub supermarket postoffice town
hall, capital, lake, ocean, forest, school and nearby addr (see
http://taginfo.openstreetmap.ch/keys/location:description:de#values )
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deleting template parameters copied to data items

[marc marc]

Le 15.01.20 à 12:49, Mateusz Konieczny a écrit :
> Anyone with opinion on that topic is welcomed to comment in this
> discussion on the OSM Wiki.

I'm very unhappy with that.
some tools use wiki and not data items (for ex taginfo)
doing that destroy usefull information.
in fact I'm unhappy with the write acces to data items that has been
done too early, all major tools must first be migrated to the dataitems.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] building=disused

[marc marc]

Le 15.01.20 à 05:15, Warin a écrit :
> On 15/1/20 6:32 am, marc marc wrote:
>> Le 14.01.20 à 19:34, Markus a écrit :
>>> If i understand it correctly, building=* values describe how the
>>> building looks, not how it is used. For example, a church that is now
>>> used as a pub still remains a building=church.
>> I fully agree with that.
>> note that building:use may record the current use.
>> therefore building:use=vacant or =none or =no fit the request.
> 
> And I would disagree. 
> 
> A building that is 'in use' is maintained. 
> 
> A building that is 'disused' is not maintained, the paint work will weather, 
> glass become dirty .. roof leak, locks freeze. Generally they look 
> disheveled.  


The village church is not painted and i wonder when someone cleans the
windows of the church here.
Anyway I am unable to tell the difference in appearance between a church
whose windows have been cleaned and a church whose windows have not been
cleaned.
I'm not talking about a building whose roof is damaged, that's no longer
disused, the work to use it is much more consequent.
in the industrial zone, there's been a disused building for as long as
i've known it. yet the appearance is still that of an industrial
building. if i ask a passerby what that building looks like, that's
probably what he'll tell me. The difference with the next building
is there's a "for rent" sign.
what other appearance value do you want to create?
building=disused_industrial: an industrial building where windows
have not been maintained recently or with a "to rent" sign on it ?

> If you tag 'disused=yes' ... how is that rendered?

it depends on the wish of the map style, which is not the right place
to discuss.
one renderer may choose to ignore it, another may choose to use a
lighter color, another may choose to display it in red to highlight
areas to be reassigned.
all this is possible with building:use=vacant/no, disused:building=*
and disused=yes.
but to me, disused:building=* is a bad/yrong idea, there's still
a building present, so we should keep a building=*

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

Re: [Tagging] building=disused

[marc marc]

Le 14.01.20 à 19:34, Markus a écrit :
> If i understand it correctly, building=* values describe how the
> building looks, not how it is used. For example, a church that is now
> used as a pub still remains a building=church.

I fully agree with that.
note that building:use may record the current use.
therefore building:use=vacant or =none or =no fit the request.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to revive a tag proposal?

[marc marc]

Le 14.01.20 à 18:33, António Madeira via Tagging a écrit :
> https://wiki.openstreetmap.org/wiki/Proposed_features/olive_oil_mill
> What can I do to revive this proposal and implement this tag?

for small changes :
check taginfo if another tag/value exist with the same meaning.
check if the most comment used tag/value is a good idea or not.
take over the proposal (change the name field like : original by A,
take over by B) and choose whether you want to keep the rest intact
or modify in favour of the most common existing situation.
run the RFC like any other proposal.

for big changes :
write a new proposal, keeping all that can be done to avoid
fragmentation (some may be using the previous proposal even
though it was unsuccessful).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Free Water for cafés, bars, restaurant

[marc marc]

> free_water:container = 

bring_your_own is very explicit.
but "provided" or "establishment" is ambiguous.
from my experience, drinking a free glass of water in a cafe is not at
all the same as receiving a container filled with water (I have never
encountered this case).
so the choice should be between values like your_own_takeaway_container
<> on_site
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Free Water for cafés, bars, restaurant

[marc marc]

Le 14.01.20 à 10:00, Martin Koppenhoefer a écrit :
> if you have to buy something in order to get "free" water, 
> it isn't free, is it? It's included.

you're right, I often make that remark in everyday life.
but in osm terminology, how would you inform the private and free
swimming pool for hotel guests ? access=customers + fee=no
or fee=included ?
nearly nobody use https://taginfo.openstreetmap.org/tags/fee=included
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] recreational vs functional routes

[marc marc]

Le 11.01.20 à 21:05, Florimond Berthoux a écrit :
> What do you think ?

avoid the word "type" in a key as it as no additional meaning.
type can be everything (type of operator, difficulty, use, length, ...)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rare route values route=inline_skates and route=running

[marc marc]

Le 11.01.20 à 06:21, Joseph Eisenberg a écrit :
> The tag  route=inline_skates
> Are there actually signed, verifiable inline skate routes?

yes

> Should a rare tag like this be in Map Features?

listing all the rare cases on maps feature is like turning it into
a wiki search engine or a taginfo without the typo.

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

Re: [Tagging] addresses on buildings

[marc marc]

Le 06.01.20 à 08:47, Florian Lohoff a écrit :
> If you have HUGE Buildings i use a node with an address.

it's amazing the difference in usage.
I find that addr nodes are very problematic for hudge buildings like
shopping malls or train stations. the localisation of the node forces
the routing to go to a specific location when you may be closer to
another entrance.
By putting the address on the building, you can not only allow quality
reverse geocoding for the whole building, but also allow advanced
routing to select the closest entry instead of going to the preferred
entry of the contributor who entered the address.

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

Re: [Tagging] surface=block_paved, or surface=paved + paving=block

[marc marc]

why it isn't a paving_stones ? the max height ?
I ask myself how and how many mappers 'll see a diff.

Le 08.01.20 à 22:36, Mateusz Konieczny a écrit :
> Is following picture
> https://commons.wikimedia.org/wiki/File:Paving_being_laid_arp.jpg
> depicting construction of surface=paving_stones?
> 
> Or is it incorrect to tag in this way and
> surface=block_paved, or surface=paved + paving=block
> should be considered as preferable?
> 
> Posted to look for more feedback in
> https://wiki.openstreetmap.org/wiki/Talk:Tag:surface%3Dpaving_stones
> discussion.
> 
> 
> ___
> 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] Cycle boxes for two-stage left turns

[marc marc]

Le 08.01.20 à 05:10, Marc Gemis a écrit :
> On Tue, Jan 7, 2020 at 10:30 PM marc marc  wrote:
>>
>> Le 06.01.20 à 04:19, Jarek Piórkowski a écrit :
>>> Comments most welcome!
>>
>> keep it simple !
>> advanced stop box only use a cycleway=asl without relation
>> https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dasl
>> a single node is not enought ?
> 
> The problem I see with this approach is that the node has to be placed
> on the other street than the one the cyclist is using.

I don't think so.
we must do the same as for a traffic sign stop :
add the node to the affected way with cycleway=tsb or any other value
with the same meaning.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=tourist_bus_parking

[marc marc]

Le 06.01.20 à 03:24, John Willis via Tagging a écrit :
> parking=tourism
> parking=disabled
> parking=loading_dock
> parking=taxi
> parking=waiting_lot

that conflit with the current meaning :
https://wiki.openstreetmap.org/wiki/Key:parking
parking=surface/underground/roof top would have looked better in the
location tag, but changing that is... too late, it's past Christmas :)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] recreational vs functional routes

[marc marc]

Le 07.01.20 à 20:21, joost schouppe a écrit :
> function=recreational/practical
usage=tourism/transport ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Cycle boxes for two-stage left turns

[marc marc]

Le 06.01.20 à 04:19, Jarek Piórkowski a écrit :
> Comments most welcome!

keep it simple !
advanced stop box only use a cycleway=asl without relation
https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dasl
a single node is not enought ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] relation types: circuit proposal and an alternative

[marc marc]

Le 07.01.20 à 20:58, Richard Welty a écrit :
> a profound lack of interest
> https://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Circuit

maybe it's due to the funny url for a propal
moving it at the right place may help
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] ISO3166-1 key documentation [was:Tagging for emojis names]

[marc marc]

Le 07.01.20 à 13:40, Jeroen Hoek a écrit :
> using the exsiting ISO3166-1:alpha2

all those ISO3166-1* key doesn't have a wiki page.
if the key is fine (I find it ugly as a top level key),
it could be a good idea to write a small sheet about them.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] depreciate recycling:metal in favor of recycling:scrap_metal

[marc marc]

Le 06.01.20 à 04:48, Paul Johnson a écrit :
> Domestic refuse metals like metal packaging from consumer products
> (think like, food and beverage cans), something that you can typically
> drop off at your average grocery store parking lot recycling center.  As
> opposed to scrap metal, which is pretty much everything from car hulks
> to household appliances to copper wiring and plumbing, etc...

how is this usage currently tagged ?
if it's with recycling:metal and if it's common, then we have to change
the wiki documentation to describe the actual usage (currently the wiki
informs that recycling:metal is about scrap metal).
but given the ambiguity of recycling:metal, I think it's better to
depreciate it in favor of a few precise values (scrap_metal, domestic
packaging, etc.).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[marc marc]

Le 06.01.20 à 01:28, Tomek a écrit :
> W dniu 20-01-06 o 00:24, marc marc pisze:
>> are you planning a mechanical edit ?
> NE, mi volas redakti ĉiun punkton aparte.

editing one by one, doesn't solve the the mechanical issue,
mechanical isn't about the size of the changeset,
it's about the "select objects by a query (for ex all sea in this area)
without a review/local knowledge.

> W dniu 20-01-06 o 00:24, marc marc pisze:
>> A more pragmatic solution would be to propose that each of these objects
>> have a name either in the most common language of that place, or in the
>> languages of that place or in a neutral language for example an
>> artificial language such as Esperanto.
> La problemo estas, ke ne eblas difini lingvon de ekzemple Balta Maro

really ? reading wikipedia for 2 min, I have a less chaotic vision
https://en.wikipedia.org/wiki/en:Baltic%20Sea?uselang=fr#Etymology
the current name is used extensively, including by a neighboring Baltic
country.
the article gives 2 other names used by 2 other neighboring countries.
the name tag of a multilingual zone must not contain 9 versions.

previous revert does not state on your arguments, it was done because
you are doing mass editions without following the rules that have been
written to avoid edit wars when 2 people have a different opinion.
it's sad to see that you've started again a few days ago.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[marc marc]

Le 05.01.20 à 23:25, Tomek a écrit :
> I plan to remove the "name" and "wikipedia" tags from places 
> that are not associated with a specific nation or language:
> Please support (vote) my proposal or write a reason why not.

are you planning a mechanical edit ?
if yes, you misunderstood
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
there's no vote for a mechanical edition.
but you MUST consider the oppositions.
I'm not a native English speaker, I understand the problem you are
exposing (even if talking about imperialism gives the impression of a
speech from the past millennium) and I even agree that there is a
problem. but I OPPOSE your mass edition as proposed.
Removing the name tag implies that each style/app that uses it will have
to be modified to find out what is the most appropriate name for the
place. And until then, all these name will disappear , which is not
desirable.

A more pragmatic solution would be to propose that each of these objects
have a name either in the most common language of that place, or in the
languages of that place or in a neutral language for example an
artificial language such as Esperanto.

to stay on the subject of tags, there is a proposal to define the
language of a place, this is another fix to explore.

for the wikipedia tag, it's the same problem.
Saying that people just have to use the tag and the wikidata api
to display a wikipedia page is a serious regression compared
to the current situation.
For places where you find a local language, it is quite possible
to change the language of the wikipedia tag.
for others, it is possible to point to a wikipedia page in a neutral
language, at least if it exists and is not a draft.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] depreciate recycling:metal in favor of recycling:scrap_metal

[marc marc]

Hello,

https://josm.openstreetmap.de/ticket/18152
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Drecycling
the wiki describe recycling:metal as "ll sorts of metal – possible
duplicate of more frequently used recycling:scrap_metal; see below."
the wiki doesn't describe recycling:scrap_metal

does this seem coherent as depreciation?
if yes, the new value should be documented :)
my low use of recycling:metal was indeed scrap metal.

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

Re: [Tagging] Public WLAN boxes

[marc marc]

Le 29.12.19 à 21:50, bkil a écrit :
> fee=no @ register with an Italian phone number

it seems to indicate that it's fee=yes if you don't register,
which doesn't seem to fit with what you're saying.
I prefer :
internet_access:fee=customers (you need to be a customer of it... some
use access for that)
internet_access:fee:amount=0 (the wiki suggest this key but
internet_access:charge is imho better)
internet_access:description=*
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Business names in capital letters

[marc marc]

Le 29.12.19 à 22:23, bkil a écrit :
> What do you think about these?

if the value is an abbreviation, then it's a short_name (but brand
doesn't have a short_brand key, in this case it's normal to put the
abbreviation in uppercase in brand=*)

if the value is not an abbreviation, I will use the usual (first letter
in upper case, the others in lower case)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tag for "tax free shopping"

[marc marc]

Hello,

boith tags look fine, except the unneeded use of a namespace
duty_free= (already exist 6 time)
tax_refund=

Regards,
Marc

Le 23.12.19 à 21:25, Hauke Stieler a écrit :
> Hi all,
> 
> so I think of creating/establishing two new tags:
> 
> shop:duty_free=
> -> Shops in airports where nobody has to pay taxes at all (those usual
> duty-free shops)
> 
> shop:tax_refund=
> -> Shops in cities where you pay taxes like in every other shop but(!)
> you can get a receipt to get a tax refund later at the airport before
> leaving the country. Usually citizens of that country/region won't be
> able to get a refund.
> 
> Should I really setup a proposal for them? Never wrote a proposal before
> and it seems a bit much for two simple tags. What is the usual workflow
> for this?
> 
> Regards
> Hauke
> 
> On 20.12.19 14:59, Hauke Stieler wrote:
>> Hi,
>>
>> I recently found several stores (pharmacy, clothing store, jewelery and
>> others) which offer "tax free shopping". For those of you who don't know
>> it, this works as follows:
>>
>> You buy something and next to your normal receipt, you'll also get an
>> additional receipt with some tax information on it. When you travel back
>> home and come along the airport, you can hand this tax-receipt in and
>> get the taxes back.
>>
>> Not all shops are offering this service and I couldn't find any suitable
>> tag. Does such tag exist or is this something new?
>>
>> I think of something like "tax_refund=" or "tax_free=" (for shops at the
>> airport where you don't pay any taxes).
>>
>> Greetings
>> Hauke (aka hauke-stieler)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roundtrip and closed loop in relations

[marc marc]

3 240 (10%) objects with rountrip=3 also have public_transport:version=*
ex https://www.ratp.fr/plans-lignes/noctilien/n01
https://www.openstreetmap.org/relation/1083331

Le 22.12.19 à 11:57, Peter Elderson a écrit :
> For PT, roundtrip is not an attribute of the route
> 
>> Op 21 dec. 2019 om 15:31 heeft marc marc het volgende geschreven:
>>
>> I always thought that routrip=yes was an alternative when there is no
>> start and end point to enter in from=* to=* key.
>> Otherwise circular routes with a known start/end point can enter
>> as from=A via=B to=A.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roundtrip and closed loop in relations

[marc marc]

I always thought that routrip=yes was an alternative when there is no
start and end point to enter in from=* to=* key.
Otherwise circular routes with a known start/end point can enter
as from=A via=B to=A.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Public WLAN boxes

[marc marc]

Le 20.12.19 à 15:47, Cascafico Giovanni a écrit :
> 
> 
> Il mer 18 dic 2019, 16:48 Tom Pfeifer ha scritto:
> 
> 
> The 'box' would contain a full access point and not just the
> antenna, thus I'd prefer not to tag the
> antenna alone.
> 
> 
> So how to tag the whole hardware? 
> Shall I refer to Key:communication:radio:repeater?

2/3 objets exist :
the antenna itself
the box amenity=wlan
you may add support=* if you also want.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Vegan "cheese" shops

[marc marc]

Le 18.12.19 à 17:24, Philip Barnes a écrit :
> On Wednesday, 18 December 2019, marc marc wrote:
>> Le 18.12.19 à 16:58, Robert Skedgell a écrit :
>>> I think creating shop=vegan_cheese might be excessively specialised.
>>> https://www.openstreetmap.org/node/6776593885
>>
>> ho yes, please don't create a new shop=* only to describe that
>> the shop had a limited number of products.
>> you may add vending=biscuits;vegan_cheese
>>
> 
> Shouldn't vegan be in a diet tag?

indeed, but the product isn't a cheese, so fake_cheese ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Vegan "cheese" shops

[marc marc]

Le 18.12.19 à 16:58, Robert Skedgell a écrit :
> I think creating shop=vegan_cheese might be excessively specialised.
> https://www.openstreetmap.org/node/6776593885

ho yes, please don't create a new shop=* only to describe that
the shop had a limited number of products.
you may add vending=biscuits;vegan_cheese
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Barrier=berm

[marc marc]

On Thu, 28 Nov 2019 at 17:58, Jan Michel wrote:
> the purpose of the berm - e.g. berm = noise_barrier

usage=* may fit the need
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to correctly name a forest

[marc marc]

Le 27.11.19 à 22:35, s8evq a écrit :
> 1) Add a node approximately in the middle of the forest with the name tag 
> together with place=locality
> 3) Draw a new way around the outline of the forest and put the name tag on 
> that. The problem with this approach is that you need an additional main tag 
> together with the name. Sometimes leisure=nature_reserve could work (example 
> https://www.openstreetmap.org/way/681749435), but of course not always. What 
> other main tag could be added here?
> Any other or better approaches?

mix 1 and 3 : place=locality+name on the outer of the MP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Foot or foot.cycle crossing

[marc marc]

Le 27.11.19 à 17:42, Martin Koppenhoefer a écrit :
>> On 27. Nov 2019, at 17:36, marc marc  wrote:
>>
>> I don't see a physical séparator between the road and the sidewalk
>> so it's controversial to separate these different lanes into several ways
> 
> afaik the highway represents a carriageway, sidewalks are not considered part 
> of the carriageway

so no highway=* at all for sidewalks :)

>  in the UN Vienna agreement on road traffic.

let's have 2 objets in the UN Vienna database.
but osm isn't a UN Vienna database, isn't it ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Foot or foot.cycle crossing

[marc marc]

Le 27.11.19 à 16:11, Volker Schmidt a écrit :
> I do have a topological problem with the mapping of a junction of two
> roads one of which has parallel cycle lanesa and sidewalks
> Both are correctly mapped: the sidewalk as a separate highwy=footway 

I don't see a physical séparator between the road and the sidewalk
so it's controversial to separate these different lanes into several ways

> (1)
> way with:
> crossing=uncontrolled
> footway=crossing
> highway=footway
> plus node with:
> crossing=uncontrolled
> highway=crossing

look fine

> (2)
> way with:
> bicycle=designated
> foot=designated
> highway=path
> path=crossing
> segregated=yes

mixing cycleway tagged as an attribute (before/after the crossing)
and as a seprated path (at the crossing) is imho a bad idea.

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

Re: [Tagging] Long term detour routes ?(construction, disaster)

[marc marc]

Le 24.11.19 à 21:51, Kevin Kenny a écrit :
> the damaged roads are still signed with the route numbers

ref on way + relation for the real (= in use) route
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Long term detour routes ?(construction, disaster)

[marc marc]

Le 24.11.19 à 04:32, John Willis via Tagging a écrit :
> Levees have construction projects that can be years in length (building
> a new sluice gate, enlarging the levee), and the route is detoured
> around this construction. 

if the itinerary is modified for years, I would modify the main
relation, it is not an alternative route
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Several different boxes on the same pole

[marc marc]

Le 21.11.19 à 22:51, François Lacombe a écrit :
> Those two boxes will be hard to describe on the same node, although they
> can be located on the same pole.
> Should we recommend to put as many nodes as required around the pole or
> choose another option?

the easiest way to use the data is to put several nodes in the same
place. the presence of several support=pole should be sufficient if
someone uses the information "all on the same pole".
otherwise there is a relation or the use of _1 _2 supported by almost nobody
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Real time in public transport

[marc marc]

Le 19.11.19 à 13:22, A A a écrit :
> What do you think about the possibility of standardizing the use of 
> a url in "departures_board" or "passenger_information_display" tags to 
> be able to report arrival times in real time at a stop or train / subway 
> / bus station?

yes. departures_board:url seems a good candidate.

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

Re: [Tagging] Proposed features, toll (3/5)

[marc marc]

Le 11.11.19 à 23:13, Herbert Allmeier a écrit :
> Country tags: There is no worldwide toll system.

the same apply for parking : no the same-for-all-parking exist
but we still avoid using a country code to said that all parking in this 
country use somethink specific to this country.
the same apply with opening hours : we don't add country code to spécify 
that's it's this country timecode

>   NOTE: All comments attached to this mail WILL NOT BE PROCESSED!
> 
> so nice ! all not-processed comments may result in a vote=no or worse in 
> difficulties of use in the future because a detected problem has not 
> been solved
> 
> If a person  
> does not want to be involved in the discussion there is nothing I can do

if somebody reply, you can read the reply :)

> what would be a better place if not the talk page
> that is directly linked from the voting page?

you may link tagging archive if you want.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] emergency=ambulance_station vs amenity=fire_station

[marc marc]

Le 11.11.19 à 15:44, Joseph Eisenberg a écrit :
> decide which tags under `emergency=` should be treated as polygons
> when mapped as closed ways

is this information not already present on the wiki pages? for example
https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dambulance_station
onArea=yes

Of course, osm-carto need to convert/parse those infos
and maybe some values doesn't have it yet.

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

Re: [Tagging] Traffic Signs "pushing bicycle not allowed here"

[marc marc]

Le 08.11.19 à 16:16, Mateusz Konieczny a écrit :
> 7 Nov 2019, 14:39 by marc_marc_...@hotmail.com:
>> Le 07.11.19 à 14:01, Andy Townsend a écrit :
>>> you won't see a unique sign that identifies "you can't cycle here"

>> an good pratice rule is "don't map the legislation", isn't it ??
>> no sign ? thus no tag on the way

> Not always. Typical driveway in Poland is behind closed gate,
> without sign. access=private is complete correct there.

I prefer to add a gate in stead of an access restriction on the way.
sometime the end of the way go out of sky and is allowed from the other end
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic Signs "pushing bicycle not allowed here"

[marc marc]

Le 07.11.19 à 14:01, Andy Townsend a écrit :
> you won't see a unique sign that identifies "you can't cycle here"

an good pratice rule is "don't map the legislation", isn't it ??
no sign ? thus no tag on the way
at most a default value in the wiki or on the boundary.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[marc marc]

Hello,

Le 06.11.19 à 19:55, Mark Wagner a écrit :
> There are places like federal Wilderness Areas in the United States
> where possession of a bicycle is forbidden

can you share the a picture of this traffic sign ?

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

Re: [Tagging] amenity=hospital on things that are not hospitals - is it a good idea?

[marc marc]

Le 28.10.19 à 09:44, Mateusz Konieczny a écrit :
> "sign having a hospital icon and no name can simply be tagged 
> type=destination_sign + amenity=hospital"
> https://wiki.openstreetmap.org/wiki/Relation:destination_sign

Yes it's horrible

the next line said destination:symbol=hospital
it's better.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging extremely large flood control features.

[marc marc]

Le 25.10.19 à 20:29, John Willis via Tagging a écrit :
> 
>> On Oct 25, 2019, at 10:53 AM, Joseph Eisenberg  
>> wrote:
>>
>> The value should have something that suggests that it will be flooded.
>> I would think of "flood_mitigation" as something like a levee or dyke
>> which prevents flooding, rather than an area that is supposem to be
>> flooded.
>>
>> So... maybe man_made=flood_basin and natural=flood_basin?
> 
> Man_made=flood_mitigation_basin sounds good.

that look like 2 infos into one key :s

man_made=basin usage=flood_mitigation ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Access Aisle

[marc marc]

Hello,

Le 24.10.19 à 21:12, Clifford Snow a écrit :
> [1] https://wiki.openstreetmap.org/wiki/Proposed_features/access_aisle

highway=footway is sometime (counry-specific) restricted to way
with a traffic sign like the current one in its wiki page
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dfootway
I never see sutch sign for path in a parking.
maybe it's better to allow footway/path=* depending of
the current local pratice.

in the propal section, you said "access_aisle=handicap"
but them "add access_aisle=handicap_van"
handicap_van is not an handicap. it's the véhicule the user leave/reach.

in the tagging section, you said
"footway=disabled_access_aisle" : what's the added value to glue and 
duplicate wheelchair into another key=value ? wheelchair=yes already
exist to describe that this way is usable for a wheelchair user.
you also said  "If the disabled parking space is for vans add 
disabled_access_aisle=van"
to witch object ? to the amenity=parking_space i hope.
if so, I'm the current pratice seems better wheelchair=yes 
=designated

So all the proposal can be reducte to footway/path=access_aisle no ?

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

Re: [Tagging] Deprecating mini_roundabout

[marc marc]

Le 23.10.19 à 11:35, Florian Lohoff a écrit :
> You need to eliminate the node and replace it with a circular road

a junction=roundabout is also allowed as a node
https://taginfo.openstreetmap.org/tags/junction=roundabout
so it's a bad rational to deprecate mini_roundabout
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - (phone)

[marc marc]

Le 20.10.19 à 20:01, Valor Naram via Tagging a écrit :
> https://wiki.openstreetmap.org/wiki/Discussions/tagging/contact:phone_or_phone
is it a good idea and valid to open a vote with a url different from the 
conventions made for proposals? it makes it much less readable for the 
community
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Phone)

[marc marc]

Le 07.10.19 à 23:07, Martin Koppenhoefer a écrit :
> let’s bury the contact: - prefix

in this case, be logical and also propose to bury the prefix addr:

on the contrary, I believe that having a namespace to group the keys 
concerning the addr and another namespace to group the keys concerning 
the means of contact is a practical way to use the data (if you want to 
display a tab with all the means of contact, you just have to look for 
contact: without having to hard code them and having to code again the 
existence of a new social network for example)

the number of characters to write is a bad argument : focus on quality 
and not a:hn because it would be shorter to write than addr:housenumber
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Campsite properties

[marc marc]

Le 18.09.19 à 01:02, Paul Allen a écrit :
> Those machines are generally available for use only by people
> staying on the site (they could accept anyone, but usually do not).  How 
> are you going
> to tag that?  We don't have access=campers

access=private private=campers
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Reusable packaging

[marc marc]

Le 12.09.19 à 13:52, Frederik Ramm a écrit :
> A supermarket chain can introduce paper bags today, discontinue them 
> next week, and re-introduce plastic bags next month.

in theory yes.
in practice logistics chains probably change less quickly
than the urbanization of agricultural land.
if we think we can maintain the landuses (I am not sure when I see the 
catastrophic state of them in some countries with many contributors), 
then we can probably keep up to date a logistical change by decade.

> Do we even have a remote hope of achieving a
> level of completeness and timeliness that makes this usable?

no more or no less than for landuses.
in places where there are contributors interested in the subject, 
applications/sites using osm are the best ones.
where no osm contributors but contributors to proprietary databases, 
those are the best.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Reusable packaging

[marc marc]

well in this case, this shop isn't a bulk_purchase=yes shop
bulk_purchase=* in osm mean that you can BUY item in bulk
not that the shop has a stock of product that he packs for you on site.
bulk_purchase informs how the customer can have the product and not in 
what form the stock in the shop is kept

PS: I think your butcher is outdated, I haven't seen any refusals
for at least 2 years :) including in Carrefour-like shop

Le 12.09.19 à 12:54, Antoine Jaury via Tagging a écrit :
> And sorry Marc but I don't have an article explaining the use of one-use 
> only bag proposed by bulk purchase shops.
> 
> In my case, I buy only bulk purchase products and it often happen in 
> supermarket for example that you can only use the supermarket's paper 
> bags with a plastic window on the bag to see what is inside. I tried 
> once to use in an "Carrefour shop" a paper bag I reused from another 
> shop and one of the sell men explained to me that I couldn't do that 
> because they need to see what is inside the bag without opening it and 
> for hygienic reasons we can't reuse a bag multiple times.
> 
> As explained also in my previous message: butchers, backery, pastry 
> shops ... are the perfect example of shops with bulk products that will 
> not automatically accept reusable packaging. It's difficult for instance 
> to find a butcher that will accept that you use your glass jar to buy 
> some meat. Most of them will say that they have to use one-use only bags 
> for hygienic reasons.
> 
> 
> On 12/09/2019 12:29, marc marc wrote:
>> Hello,
>>
>> Le 12.09.19 à 12:20, Antoine Jaury via Tagging a écrit :
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/reusable_packaging
>>> Definition: Describes a shop accepting reusable containers from their
>>> customers and/or proposing some
>> it'sn't the same as 
>> https://wiki.openstreetmap.org/wiki/Key:bulk_purchase ?
>> you said "Some shops selling bulk products will only accept that their
>> customers use the one-use only bags proposed by the shop. "
>> bulk product in one-use packaging provided by the store ? I have never
>> heard such a contradiction. do you have a link to an article on this
>> subject?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Reusable packaging

[marc marc]

Hello,

Le 12.09.19 à 12:20, Antoine Jaury via Tagging a écrit :
> https://wiki.openstreetmap.org/wiki/Proposed_features/reusable_packaging
> Definition: Describes a shop accepting reusable containers from their 
> customers and/or proposing some

it'sn't the same as https://wiki.openstreetmap.org/wiki/Key:bulk_purchase ?
you said "Some shops selling bulk products will only accept that their 
customers use the one-use only bags proposed by the shop. "
bulk product in one-use packaging provided by the store ? I have never 
heard such a contradiction. do you have a link to an article on this 
subject?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "part:wikidata=*" tag proposal for multiple elements connected to the same wikidata id

[marc marc]

Le 09.09.19 à 16:18, Mateusz Konieczny a écrit :
> 
> 
> 
> 9 Sep 2019, 15:14 by pella.s...@gmail.com:
> 
> Imho:    the real problem, why we have multiple objects for
> "name:*"   tags? ( admin_centre, label, relation, ... )
> 
> Label is an  attempt to manually
> specify optimal place for placement of a label.

the label doesn't need any tag
exept that some of them duplicate a country with a node place=country
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - RFC - Utility markers

[marc marc]

Le 06.09.19 à 12:17, Martin Koppenhoefer a écrit :
> placement(?)=soil / street

location seems better and already exist
https://wiki.openstreetmap.org/wiki/Key%3Alocation
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] craft=sculpter <> craft=sculptor

[marc marc]

Hello,

does both have the same meaning ?
I thought that sculter was a typo in french (the word is "sculteur"
in french) but usage in french-speaking countries is very low,
so that's not the explanation.

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

Re: [Tagging] New tag office=consulting was added to Map Features

[marc marc]

Le 28.08.19 à 11:19, Joseph Eisenberg a écrit :
> New description is 'An office for a consulting firm, 
> providing expert professional advice to other companies."

at least a tag to specify the activity should be provided,
because with the current description, an accounting, IT security, 
agricultural consulting, marketing audit can all have this tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landcover dune or land form dune

[marc marc]

Le 26.08.19 à 12:57, Warin a écrit :
> Is there a requirement to go in to all of these wiki pages and explain 
> why the demotion of one over the other simply due to frequency of use 
> without consideration of other factors?

I ask myself "what would we do if the other tag didn't exist ?"
would we create the more currently common one or something better ?
if the answer is "something better", then I wouldn't put demotion
on the "better" tag page but simply the information "another tag
is more common tag" + the argument why this alternative exist
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Document personal tags in Proposed_features/ space, User: space, or Tag:/Key: space?

[marc marc]

Le 26.08.19 à 00:18, Joseph Eisenberg a écrit :
> What should we do with a page like Tag:landcover=dunes? I already
> tried adding a mention that natural=dune was more common and mentioned
> on the Talk page that "dune" is a landform, not a landcover

the first sentence on the wiki is enought to fully describe
the mess in your argument.
"the dune landform (natural=dune) and for areas of sand (natural=sand)"
so a landform and a landcover in the same key. exactly the same problem 
you're criticizing. so no, landcover is probably no worse than landuse.
natural=* description try to explain that the common "meaning" for is 
value is "natural physical land features, including ones that have
been modified by humans"
but that also "need" to be used to "full artificial" (ex a full 
artificial water pond).
don't be surprised that some people are not satisfied with this kind
of key whose category changes according to the value.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] phone vs contact:phone WAS Re: Multiple tags for one purpose

[marc marc]

Le 25.08.19 à 17:42, Colin Smale a écrit :
> Your model (using only phone=*) only allows an object to have a single 
> phone number.

not true.
phone=number1;number2
ex https://www.openstreetmap.org/node/26861282
18219 discint value for a total of 19694 count

> one for general enquiries, one for emergencies, one for staff,...

you may use a namespace prefix (but some app 'll not use it)
or create one objet per unit (maybe a reception_desk for the
general enquiries, or one for the Hyundai franchise departement)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] phone vs contact:phone

[marc marc]

Le 25.08.19 à 16:55, Martin Koppenhoefer a écrit :
> What about deprecating the contact: prefix, at least for phone?

not "AT LEAST FOR" that's the main issue !

having some contact with contact: prefix and some other without
is a very bad idea.
we need to switch all contact to key with contact: prefix
(pro : a datauser is able to group them without havng to keep
a hardcoded list of all key (phone, fax, email, web, social network ) 
and update to list everytime one user add a new contact)
OR
we need to forget this idea of grouping all contacts
(ironic pro : we tag for the database, not to have easy to use data)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Multiple tags for one purpose

[marc marc]

Le 24.08.19 à 18:04, Valor Naram a écrit :
> why we have two tags for one purpose sometimes?

many (almost all bad) reasons can explain it :

- one key exist, a new schema is born with a new tag for the same 
feature/meaning, but the new schema never got a proposal or the proposal 
never go into voting or the accepted proposal doesn't said enought "this 
tag is depreced" (ex : phone <> contact:phone) or the new tag have some 
issue and therefore some mapper want a new schema that solve everything 
before dropping the first one (source:maxspeed <> maxspeed:type)

- some key have high usage and a part of the community is unwilling to 
apply some lifecycle to tag, hoping that one day, "the invisible hand of 
the community" (parody of the concept of the invisible hand in 
economics) will solve the problem while we bury our heads in the sand
to deny the problem it creates (for ex building=cooling_tower <> 
tower:type=cooling)

- 2 key exist, one use by one editor, other rejetected by this editor 
but used by all-expet-one (ex : crossing=marked)

- 2 key exist but the exact meaning vary according to who used it.
at the end, the only usable meaning is the same for both key (ex : 
landuse=forest <> natural=wood)

- only one tag exist at the begining but the but the key is in 
contradiction with the meaning/logic of the key and therefore some
have created a more structured alternative. however this alternative
is rejected by the default rendering because the other key has
a more important use. it is the problem of the egg and the hen.
(ex: landuse=grass with have a clear meaning which is not a landuse)

- all those involved in this ml and/or in a voting agree that a key 
should be depreciated, but someone thinks it would take hundreds of 
voters when there are not hundreds of participants. so motivated people 
go their way and the problem remains (see the discussion this summer... 
I don't remember the tag concerned)

- some depreciated tags can't be converted automaticly because the tag 
have 2 meanings (ex power=sub_station). not enough mapper review those.

- some proposal "hides" a depreciated tag into several other good stuff.
at the end the proposal got rejected or some disagree to use "the vote".
imho a "proposal to depreciate a tag" need to be as small as possible

therefore the default osm.org editor think it must take the lead to 
decide what to depreciated and do a distributed automated edit. 
sometimes it corresponds to the opinion of the community, sometimes not, 
and in this case the community has lost control and the automated edit
is poorly documented and sometime wrong. it sometimes leads to edit wars 
or an unpleasant discussions, it further cools down people who want to 
make another depreciation of a tag, or it motivates them to do so via a 
ticket for an editor since if the dev agrees, it will happen even if the 
community is against.

possible solutions based on my limited experience :
- talk to choice the better tag between 2 need to be done at the global 
level, arguments must be listened but ignore noice like "the wrong tag 
is too important to change"
- making mecanical edit to migrate a depreciated/bad tag to its new 
value works well at the local (coutry) level, the discussion take place 
with the local community, without being polluted by "opponents in 
principle". several of us do that kind of thing.
- probably we should make a "network" to share the proposals, this would 
have a global impact perhaps enought to progress on some tags while 
"opponents in principle" continue to have no solution to the problems 
exposed.
- it is only when several local communities have agreed on the same 
choice and the countries in question have accepted a mass edition that 
it is possible to risk such a demand at the global level.
I only did 3 at the global level, 2 to fix a bug in an editor,
a third to migrate a marginal key.
in 2 of the 3 cases, I had requests for explanations after the fact 
despite it was discussed wherever I thought it was necessary. I learned 
that next time, we will have to discuss even more and be even more 
square about where the discussion is taking place and about the 
documentation (one was not sufficiently documented when it begging).

I am well aware of the unpleasant tone of my message, but I have not 
found a way to describe facts objectively while pointing out the 
problems that have persisted for years.

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

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[marc marc]

Le 21.08.19 à 09:58, Markus a écrit :
> Otherwise, we need a new relation (maybe type=stop_position?) to
> connect the stop position to the waiting area

imho that's why stop_area relation exist
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[marc marc]

Le 19.08.19 à 15:28, Joseph Eisenberg a écrit :
>>> The tag livestock=*
>>> used 132 times
>>
>> 16% of landuse=farmyard have a animal=* tag.
> 
> I think you misread taginfo.

you're right.

> If we remove the animal=yes tags

in stead of a replay, can you explain
why those valid datas need to be removed ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[marc marc]

Le 19.08.19 à 13:34, Paul Allen a écrit :
> On Mon, 19 Aug 2019 at 12:16, Warin wrote:
>I like property tags that can be used anywhere appropriate.
> 
> The authors of at least one editor disagree with you there.   
> Unless all of the possible
> values are applicable to all objects for which that property is 
> appropriate, they won't implement a preset for it.

to use Warin's example, this would mean that the tag height is bad, 
because not all height values (including those of hudge building) are 
applicable to street cabinets.
The iD team's choice not to filter the context makes the height list not 
very useful for street cabinet. do we have to change the tag height into 
streetcabinet:height ? and then we also change the tag name to have 
building:name ? or simply to find that this choice of editor is not optimal?
josm's team has (it seems to me) made the choice to take into account 
the context
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[marc marc]

Le 19.08.19 à 12:17, Joseph Eisenberg a écrit :
> The tag animal=* has been 2137 times
> animal=yes (unhelpful!)

I wonder why it's useless.
if the contributor does not know if they are cows or calves,
this allows him to enter "there are farm animals there" and any 
application can easily target for improvement (e.g. StreetComplete).
what would be useless is to force the contributor to be an expert in 
biology to inform "there are animals there".
it would be just as useless as trying to remove all the key=yes
that are the very basis of the incremental contribution,
one of power of osm

> The tag livestock=*
> used 132 times

16% of landuse=farmyard have a anima=* tag.
I didn't understand what argument to hope that the
current most used tag would change in favor of a marginal tag.

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

Re: [Tagging] Route sorting

[marc marc]

Le 15.08.19 à 19:40, Martin Koppenhoefer a écrit :
> why would you not do it for roundabouts?

when we split a building in several parts, we keep one building=*
and use several building:part

for roundabouts, the tag is the same. for the whole roundabouts and for 
part of it.
So spliting one roundabout into many produce many junction=roundabouts, 
despite it's only one roundabouts.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] reservation<>booking (was: New property Key:walk-in for amenities like clinics, barbers, hair salons that offer walk-in appointments/service?)

[marc marc]

Le 15.08.19 à 16:28, Martin Koppenhoefer a écrit :
>> On 15. Aug 2019, at 15:54, marc marc  wrote:
>>
>> - keep booking=* for the few booking.com urls that currently exist
> 
> IMHO we should not reserve tags named with a common word like „booking“ for a 
> commercial service. Their key could be “booking.com” 
so somes firms have a too common name and need a key with a tld
and somes no ? good luck !
it makes me think of the saga facebook <> contact:facebook=*
at the end 2 keys instead of a migration that improves

so personally, I don't touch booking=*booking.com*
until a successful propal on the subject
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New property Key:walk-in for amenities like clinics, barbers, hair salons that offer walk-in appointments/service?

[marc marc]

Le 15.08.19 à 15:26, Dave F via Tagging a écrit :
> How about using booking?
> https://wiki.openstreetmap.org/wiki/Key%3Abooking

we talk a few days ago to :
- move value used as in reservation=* into this tag to avoid
duplicate tag with the same meaning
- keep booking=* for the few booking.com urls that currently exist
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Past discussions Was:Re: Classifying roads from Trunk to Tertiary and Unclassified

[marc marc]

Le 14.08.19 à 02:00, Warin a écrit :
> On 14/08/19 00:20, Martin Koppenhoefer wrote:
>>> On 13. Aug 2019, at 16:02, Paul Allen  wrote:
>>>
>>> Which diverged into this thread.  We've come full circle.
>> you have to repeat and explain the outcome of older discussions  
>> to bring those on board who have joined later ;-)

if you need to repeat, sometimes it's also because the useful is drowned 
in the flow and known only to the 5 people who swim in it

> Should be an FAQ?
> Or easier to find links to past discussions (both those with an outcome 
> and those still in contention). A few of these are not frequent.

given the length of the discussion and its scattering, adding a link
to the first message of every thread is not very useful.
on the other hand, it was proposed that the long-term discussions should 
have a summary, also posted on tagging that could be pointed to the wiki 
or other place requiring it.
for my part I am unable to make such a summary for this subject,
I have long since lost sight of the purpose of this thread except to say 
"something is wrong"

as mentioned recently, some discussions are indigestible,
not only because of the number of messages but also because
of the lack of quote and clear/targeted comments.
and just because all but 5 participants gave up does not mean that the 
subject has progressed.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fruit stands and shops selling fresh fruits?

[marc marc]

Le 10.08.19 à 07:24, Warin a écrit :
> the key produce=* could be used to detail what was sold

a shop produce nothing. better to use vending=*

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

Re: [Tagging] Use of tag "import=yes" on objects, not changesets?

[marc marc]

resend with 2 corrected errors (in caps)

Le 09.08.19 à 15:46, marc marc a écrit :
> Le 09.08.19 à 15:32, Joseph Eisenberg a écrit :
>> I'm trying to figure out what this means
> 
> it mean the contributeur doesn't understand changeset TAG
> or understand it but find it more convenient to use tags on
> objects and stamps if it's not reliable
> 
>> doesn't have a wiki page.
> 
> add a redirect to the import guideline ?
> 
>> calculate how many roads we already mapped
> 
> Pascal Neis tools allow this kind of stat
> diff scan also.
> load all changeset of those user also
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging