Re: [Tagging] Do we map pedestrian crossings twice?

[Marc M.]

Hello,

Le 10.06.20 à 04:03, Jack Armstrong a écrit :
> Users have been adding pedestrian crossing tags on ways

I don't see 2 crossing.
I only see 1 crossing https://www.openstreetmap.org/node/7598863281
between a footway https://www.openstreetmap.org/way/813492687
and a tertiary road https://www.openstreetmap.org/way/558176641

Regards,
Marc

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

Re: [Tagging] Do we need more different tagging for telephone covers?

[Marc M.]

Hello,

Le 04.06.20 à 13:33, Lukas via Tagging a écrit :
> the question is whether key covered=* is suitable for this. 
> Or should we stay with a stricter covered=yes/no
> and maybe add something like covered_by=phone_hood or something?

key=yes/no with some more specific value is the common logic.
so covered=yes covered_by== is imho unwanted.
covered/yes/no/more precise values do the job.
for exemple we have building=yes and you can refine with =house
or entrance=yes and you can refine with =main/starcase/..

Regards,
Marc

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

[Tagging] any valid usage of admin_level=1 ?

[Marc M.]

Hello,

following a small thread on irc, I have review 20 usage of admin_level=1
all are mistakes, often by new mapper
for ex https://www.openstreetmap.org/way/779838275
is there a case of real use of admin_level=1?
wiki only said that UE isn't a admin_level=1
but don't list any valid usage of it
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#Super-national_administrations
https://overpass-turbo.eu/s/Umf

are these all errors or is there an undocumented usecase ?

Regards,
Marc

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

Re: [Tagging] [Tagging-fr] [Talk-ml] [Talk-sn] With leisure=common deprecated, Senegal & Mali need a replacement

[Marc M.]

there's an *observation* that this tag has different meanings,
from a few blades of grass between 2 streets to a paved surface
for the big annual village party.
Do you dispute that *statement* ?
or do you want to deny it and repeat that only your meaning should
be taken into account ?
If you use it in your neighborhood, your own application may decide that
your meaning is the only common sense, but on a global level, this can't
succeed.

You seem to be talking about depreciation as if there was a voting
procedure, whereas in this case it's more like "these multiple meanings
make the tag unusable worldwide, fortunately there are less ambiguous
alternatives".

Le 25.05.20 à 00:19, Rafael Avila Coya a écrit :
> Unless you demonstrate me that I am wrong, the tag leisure=common was
> deprecated without any agreement with the community. So it's clearly not
> a deprecated tag. Another thing is what you actually think about the tag
> itself.
> 
> Cheers,
> 
> Rafael.
> 
> O 23/05/20 ás 20:49, Marc M. escribiu:
>> Agree on what?
>> That leisure=common needs a replacement ? Yes.
>> that replacement must be different from what needs to be replaced ?
>> it seems logical to me but some people think that replacing a
>> depreciated tag by itself will solve the problems that led to its
>> depreciation.
>>
>>
>> Le 22.05.20 à 15:46, Jean-Marc Liotier a écrit :
>>> So, we are actually all in agreement, aren't we ?
>>>
>>> Nous sommes donc tous d'accord, non ?
>>>
>>>
>>> On 5/3/20 6:00 PM, severin.menard wrote:
>>>> Oui désolé, en effet je me suis trompé sur la clé !
>>>>
>>>> Yes sorry, my mistake regarding the right key!
>>>>
>>>>
>>>>
>>>> ‐‐‐ Original Message ‐‐‐
>>>> Le dimanche 3 mai 2020 17:54, Pierre Béland via Talk-ml
>>>>  a écrit :
>>>>
>>>>> Fr
>>>>>
>>>>> Oups un instant Jean-Marc. Erreur sans doute de la part de Séverin,
>>>>> je disais bien
>>>>>   leisure=common
>>>>>
>>>>> En
>>>>>
>>>>> Oops a moment Jean-Marc. Probably a mistake on Séverin's part, I did
>>>>> say...
>>>>>   leisure=common
>>>>> */ /*
>>>>>
>>>>>
>>>>> Le dimanche 3 mai 2020 11 h 13 min 40 s UTC−4, Jean-Marc Liotier
>>>>>  a écrit :
>>>>>
>>>>>
>>>>> So, this discussion gravitates towards using landuse=common for those
>>>>> African urban freely accessible multipurpose open spaces, which I
>>>>> fully support.
>>>>>
>>>>> Implementing this change requires the following actions:
>>>>>
>>>>> - Editing the leisure=common wiki page, in French and in English
>>>>> (I'll do that)
>>>>>
>>>>> - Reinstating the rendering of leisure=common in downstream
>>>>> cartographic styles, would be even better if the color matched the
>>>>> surface=* so that sandy surfaces don't appear green.
>>>>>
>>>>> - Reinstating the rendering of leisure=common in JOSM's default style
>>>>> (it recently changed to grey to mark deprecation). (I'll open a JOSM
>>>>> ticket
>>>>>
>>>>> - Altering QA rules (JOSM Validator and Osmose) so that the
>>>>> leisure=common deprecation only applies to the United Kingdom of
>>>>> Great Britain, where commons have a legal definition and
>>>>> designation=common must be used for them. (I'll open a JOSM ticket
>>>>> but if someone has prior experience interacting with the Osmose
>>>>> people, that would be nice)
>>>>>
>>> ___
>>> Tagging-fr mailing list
>>> tagging...@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging-fr
>>>
>>
>> ___
>> 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] [Tagging-fr] [Talk-ml] [Talk-sn] With leisure=common deprecated, Senegal & Mali need a replacement

[Marc M.]

Agree on what?
That leisure=common needs a replacement ? Yes.
that replacement must be different from what needs to be replaced ?
it seems logical to me but some people think that replacing a
depreciated tag by itself will solve the problems that led to its
depreciation.


Le 22.05.20 à 15:46, Jean-Marc Liotier a écrit :
> So, we are actually all in agreement, aren't we ?
> 
> Nous sommes donc tous d'accord, non ?
> 
> 
> On 5/3/20 6:00 PM, severin.menard wrote:
>> Oui désolé, en effet je me suis trompé sur la clé !
>>
>> Yes sorry, my mistake regarding the right key!
>>
>>
>>
>> ‐‐‐ Original Message ‐‐‐
>> Le dimanche 3 mai 2020 17:54, Pierre Béland via Talk-ml
>>  a écrit :
>>
>>> Fr
>>>
>>> Oups un instant Jean-Marc. Erreur sans doute de la part de Séverin,
>>> je disais bien
>>>  leisure=common
>>>
>>> En
>>>
>>> Oops a moment Jean-Marc. Probably a mistake on Séverin's part, I did
>>> say...
>>>  leisure=common
>>> */ /*
>>>
>>>
>>> Le dimanche 3 mai 2020 11 h 13 min 40 s UTC−4, Jean-Marc Liotier
>>>  a écrit :
>>>
>>>
>>> So, this discussion gravitates towards using landuse=common for those
>>> African urban freely accessible multipurpose open spaces, which I
>>> fully support.
>>>
>>> Implementing this change requires the following actions:
>>>
>>> - Editing the leisure=common wiki page, in French and in English
>>> (I'll do that)
>>>
>>> - Reinstating the rendering of leisure=common in downstream
>>> cartographic styles, would be even better if the color matched the
>>> surface=* so that sandy surfaces don't appear green.
>>>
>>> - Reinstating the rendering of leisure=common in JOSM's default style
>>> (it recently changed to grey to mark deprecation). (I'll open a JOSM
>>> ticket
>>>
>>> - Altering QA rules (JOSM Validator and Osmose) so that the
>>> leisure=common deprecation only applies to the United Kingdom of
>>> Great Britain, where commons have a legal definition and
>>> designation=common must be used for them. (I'll open a JOSM ticket
>>> but if someone has prior experience interacting with the Osmose
>>> people, that would be nice)
>>>
>>
> 
> ___
> Tagging-fr mailing list
> tagging...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging-fr
> 


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

Re: [Tagging] Quality and the Openstreetmap value chain

[Marc M.]

Hello,

Le 13.05.20 à 00:18, Graeme Fitzpatrick a écrit :
> I'd really like somebody to come up with simple definitions of

let's try :)

> mappers,

someone who adds data into osm

> data consumers / customers,

someone who get data from osm

> I map, & I then also "use" OSMand for navigation purposes, so what am I?

a mappers and a user of OSMand (by using OSMAnd, you don't use the data
directly, if a tag changes, it is osmand that has to change and not you
as an osmand user).

Regards,
Marc

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

[Marc M.]

Le 11.05.20 à 14:42, Paul Allen a écrit :
> On Mon, 11 May 2020 at 10:58, s8evq wrote:
> What's you counter argument to the people suggesting that contact:*
> makes it easier for data consumers to gather all contact info in one
> go, instead of hard coding all the possible keys. What if next year
> a new way of contacting comes up?
> 
> For mappers, no purpose.  They use the editor preset

your answer is precisely the *problem* in the question
every new contact need a new preset in stead of query taginfo
and show top X contact:*
same problem for the user of the data. if somebody wants to display
all the details of a shop, he has to make a hardcoded list of phone
website... instead of being able to display all the contacts:* that
the osm contributor has filled in.

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

[Marc M.]

Le 11.05.20 à 11:29, Shawn K. Quinn a écrit :
> In fact, I'm not sure how useful it is for us to tag phone numbers on
> phoneboxes at all. Does anyone actually use this data for something useful?

it look like a ref, and a ref is useful to link 2 databases,
including if we put it in the ref key :)

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

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Marc M.]

Hello,

Le 10.05.20 à 01:24, Martin Koppenhoefer a écrit :
> imagine you are ordering a taxi for yourself and 2 colleagues to the
> airport and instead of a taxi (cab) they send you 3 taxi moto. Would
> that be equally ok, wouldn’t it matter, taxi is taxi?

Imagine ordering a taxi and arriving in a 4-seater car when you have
a family of 8, it's the same problem, isn't it?
When I order a taxi, they ask me the number of people.
the guy won't come with a fiat 500 if I say 8

I don't imagine we're going to create several objects to describe
that a taxi waiting area has motorcycles, "normal" cars, vehicles
with a lot of passenger seats and vehicles with a heavy
luggage capacity.
on the ground : one traffic sign for for all variants.

Regards,
Marc

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

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Marc M.]

Le 08.05.20 à 19:06, Phake Nick a écrit :
> Your argument was like saying we should use a amenity=stop tag for all
> bus stop, taxi stop, helicopter stop, and cruise ship stop because they
> are just "services

public_transport=* was invented for a service and relegate
the mode of transport to a sub-tag.
this is probably not the best example given the difficulty
around PT schemas but it was approved

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

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Marc M.]

apart from the joke with the foot_taxi, I used all the others, what to
reply to someone who tells me it's not common and therefore gives the
impression that only this usecase is important and therefore requires a
top-level tag just for that ?

that's why it gives the impression that you're saying "you didn't
understand", without your answer explaining my argument : I'm talking
about "the same *service*" and you reply with the number of *wheels*

Le 08.05.20 à 18:17, Joseph Eisenberg a écrit :
> For the record, I responded to Marc Marc’s comment on this list, 
> and there was not a response back:
> 
> “ On 2/20/20, marc marc wrote:
>> 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.
> 
> Not all of these actually are in real-world use.
> 
> The only 4 options in common use today are:
> 
> 1) motorcar, 4 wheels, enclosed (amenity=taxi)
> 2) motorcycle, 2 wheels, open (amenity=motorcycle_taxi)
> 3) pedicabs / 3-wheel tricycles (amenity=pedicab?) - non-motorized
> 4) autorickshaws, 3 wheels, enclosed (could be amenity=taxi or perhaps
> amenity=autorickshaw - but these are not common where I live, though I
> know they are common in Thailand, India and some other countries).
> 
> There used to be human-pulled rickshaws, but these no longer exist.
> They were take over by pedicabs / aka bicycle rickshaws, since those
> are much more efficient.
> 
> I will consider proposing the other 2 tags later, but motorcyle taxis
> are by far the most common. I would bet there are more "ojek" stands
> in Indonesia than taxi
>  stands in all of Europe.”
> 
> https://lists.openstreetmap.org/pipermail/tagging/2020-February/051233.html
> 
> — Joseph Eisenberg
> 
> On Fri, May 8, 2020 at 8:47 AM Marc M.  <mailto:marc_marc_...@hotmail.com>> wrote:
> 
> Hello,
> 
> > If these arguments were given beforehand
> 
> except memory problem, I exposed this opinion here during the RFC
> (=consider that taxi is a service independent of the propulsion
> of the engine which is a sub-tag), and I have the impression that
> the answer was "you didn't understand".
> 
> I would have liked to understand why I was wrong, but I have the
> impression that this was not the goal of this rfc which is a mistake for
> the quality (and it is not the first proposal that fails for lack of
> quality either in the tag, either in the explanation of why this tag)
> 
> Regards,
> Marc
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto: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] Tag:amenity=motorcycle_taxi not approved

[Marc M.]

Hello,

> If these arguments were given beforehand

except memory problem, I exposed this opinion here during the RFC
(=consider that taxi is a service independent of the propulsion
of the engine which is a sub-tag), and I have the impression that
the answer was "you didn't understand".

I would have liked to understand why I was wrong, but I have the
impression that this was not the goal of this rfc which is a mistake for
the quality (and it is not the first proposal that fails for lack of
quality either in the tag, either in the explanation of why this tag)

Regards,
Marc

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

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

[Marc M.]

Le 07.05.20 à 20:49, Joseph Eisenberg a écrit :
> Opposing voters preferred using amenity=taxi + motorcycle=yes

> So, what's the next step? 

propose that :) (maybe with motorcycle=only variant if needed)
it allow to have "zone when you request to be transported by individual
transport" with several transport mode depending the local usage.

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

Re: [Tagging] Doorzone bicycle lanes

[Marc M.]

Le 05.05.20 à 04:56, Andrew Harvey a écrit :
> cycleway:both:hazard becomes an issue when there are multiple hazards
> that apply, so "doorzone" should be part of the key not the value.

; is a common separator
=value1;value2;value3
for ex
https://taginfo.openstreetmap.org/tags/hazard=animal_crossing%3Baccident_area

Regards,
Marc

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

[Marc M.]

Le 05.05.20 à 00:05, Martin Koppenhoefer a écrit :
>> On 4. May 2020, at 23:59, Marc M.  wrote:
>> for all poi (shop, office, craft, bar, restaurant), does phone
>> and contact:phone have the same meaning or you have another undocumented
>> meaning that explain it's not the same ?
> for me a phone booth is a poi. 

ok, rewording :
for all shop, office, craft, bar, restaurant,
does phone and contact:phone have the same meaning ?

> Are you proposing different tags for phone numbers, depending on the kind of 
> object they get tagged to?

I haven't proposed anything yet, I asked a question about
the meaning of the phone tag according to the context.
feel free to reply to the question :)

Regards, Marc

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

[Marc M.]

Le 04.05.20 à 23:19, Paul Allen a écrit :
> On Mon, 4 May 2020 at 21:59, Marc M. wrote:
> 
> - avoid having 2 tags for the same thing.
> it's bad for both contributors and data-uses.
> 
> Except we don't all agree that they are for the same thing, 
> not even phone and contact:phone

read the page about forests (or the current discussion on
leisure=common): it doesn't matter *anymore* if some contributors make
a difference between the 2, in the end it's impossible to separate the
different meanings.
The only solution is to create other tags to better describe
this difference.

> I've added URLs for historic buildings
> that give more information about the building.

as for the plate, imho I would use website, but maybe url=*
you said you added an url :)

but if it's a valid argument, let's split the issue in 2 :
for all poi (shop, office, craft, bar, restaurant), does phone
and contact:phone have the same meaning or you have another undocumented
meaning that explain it's not the same ?
and email<>contact:email ?

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

[Marc M.]

Hello,

Le 04.05.20 à 14:48, Paul Allen a écrit :
> I haven't seen them.

the two reasons are:

- avoid having 2 tags for the same thing.
it's bad for both contributors and data-uses.

- using namespace for contact: (like we do with addr:) it's useful for
the use of the data (you can group them without having to hard-code
all the possible variants that may exist in the world).
it's obviously also useful for an editor (it could display a preset
listing all the contact keys:* without having to hard-code them in
the preset).

Regards,
Marc

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

[Marc M.]

Le 04.05.20 à 13:48, Alexey Zakharenkov a écrit :
> noone should convert 'website' tag for this memorial
> https://www.openstreetmap.org/node/1416386078 into 'contact:website'

indeed, it's not contact:website and but also not a website
it's just a picture and 2 lines of text as there are probably
a lot of them. it's not THE website of this object.
so the problem with this object is that it shouldn't have
a website tag at all :) image=* ?

vehicle=boat is also wrong. vehicle is an acces tag.
maybe memorial=sculpture or memorial=boat.

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

Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme

[Marc M.]

Hello,

Le 04.05.20 à 12:53, Valor Naram via Tagging a écrit :
> replace all occurrence of the non-prefixed versions of the contact keys

although I totally agree with the idea, I can't imagine a global mass
agreement to make it happen.
as in the previous version, you're going to have opinions against it:
- because too much use (saying that a problem that's too big doesn't
need to be solved is pretty absurd).
- because some will feel that A and contact:A are not the same thing

Regards,
Marc

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

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Marc M.]

Le 03.05.20 à 20:54, Jean-Marc Liotier a écrit :
> is it also used in other parts of the world ?

the thread already all missuses all around the world.
2 in France :
legal status https://www.openstreetmap.org/way/435015884
small area of grass between highway
https://www.openstreetmap.org/way/232310269

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

Re: [Tagging] With leisure=common deprecated, Senegal & Mali need a replacement

[Marc M.]

Hello,

Le 03.05.20 à 18:13, Joseph Eisenberg a écrit :
> it is true that this tag (leisure=common)is ambiguous because it is
> being used for totally different purposes in different countries.

I think this argument is crucial.
if more than one meaning exists for a tag, having a precise meaning for
a country is useless, osm is a global base, it's a bad idea to hope a
render style "tag A rendered as meaning1 in Africa, as meaning2 in
Europe, as meaning3 in Asia".
for quality, it is important to abandon multi-meaning tags and use
new tags instead, one for each existing sense.

as the subject said "leisure=common <...> need a replacement"
several replacements.

Regards,
Marc

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

Re: [Tagging] Feature Proposal - RFC - Deprecate healthcare=pharmacy

[Marc M.]

Hello,

Le 28.04.20 à 19:14, Joseph Eisenberg a écrit :
> The original key amenity=* is a reasonable choice. This has been
> confirmed with extensive usage of amenity=pharmacy by mappers and
> database users:

egg & chiken issue :

a proposal to depreciate a heavily used tag is rejected because some
people think that heavily used tags should be immutable, as long as they
are heavily used. so proposals do it in 2 steps: the new tag is proposed
as a complement during a transition period.

Contributors who want to see their addition on the default rendering
should continue to add the old tag. if they don't, someone else will. so
the old tag will never decrease.

Default style guardians have a "no aliases" dogma, making it impossible
to change tags.

If the "default style" was a tag, a RFC "depreciated no alias dogma"
should be nice !

Regards,
Marc

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

[Tagging] contact:google_plus status discardable ?

[Marc M.]

Hello,

the service was shutdown on 2 avril 2019
can we set the status as discardable ?

Regards,
Marc

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

Re: [Tagging] city limit sign end

[Marc M.]

Hello,

Le 12.04.20 à 13:49, Alexey Zakharenkov a écrit :
> direction=backward is invalid value in this context.

we do the same for stop, give_away, ...
and those ways may also be splitted
if both ways are in the same direction, the direction is just
as understandable as on a node in the middle of a way.
however I don't know if the editors pay attention to this when
reversing the direction of one of the 2 paths

Regards,
Marc

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

Re: [Tagging] city limit sign end

[Marc M.]

Hello,

Le 12.04.20 à 12:54, Volker Schmidt a écrit :
> Do we have a tagging convention for "city limit end"

if you place the node on the way the end of the city in one direction is
logically its beginning in the other direction. so I don't make a
difference between begin and end, it's the limit between inside/outside.

Regards,
Marc

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

Re: [Tagging] building=public vs. building=civic

[Marc M.]

Le 07.04.20 à 12:19, Simon Poole a écrit :
>  is here any actual differentiation between the two values

both are often badly used to describe the current function
of the building and not what it look like.
the description of building=civic said "A building hosting any civic
amenity", so it's nothing related to what the building look like.
imho data user can't do anything with that
and as a contributor, I don't use any of them

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

Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap

[Marc M.]

Le 06.04.20 à 18:23, Frederik Ramm a écrit :
> Only way I would see this working is a "gamification" thing

QA tools can also warn "this poi hasn't been changed in a long time,
maybe you wish to review/resurvey it"
Some ppl like to have an "up-to-date area", and not rely
on luck to systematically detect obsolete things

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Marc M.]

Le 06.04.20 à 18:13, Florimond Berthoux a écrit :
> If a path can only be used by mtb I think access=no mtb=designated can
> be used (I understand that goes against path multi usage definition, 
> but why access tags exist if we cannot use it ?)

I never see sutch sign. but if it exist, why not.
but imho it only exist in leisure=track sport=mtb area
so why tag it as a path ?

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

Re: [Tagging] Feature Proposal - RFC - Urgent Care

[Marc M.]

the wording is one issue but I was more interested in meaning.
is it the same meaning ? if not please explain the difference

telling me "tag as you wis" is not an interesting answer for the quality


Le 06.04.20 à 13:11, Ty S a écrit :
> Honestly, reservation is definitely the wrong wording here, and so is
> emergency (see talk page of proposal) however, tag as you wish.
> ----
> *From:* Marc M. 
> *Sent:* Monday, April 6, 2020 2:27 AM
> *To:* tagging@openstreetmap.org 
> *Subject:* Re: [Tagging] Feature Proposal - RFC - Urgent Care
>  
> Le 05.04.20 à 17:06, Ty Stockman a écrit :
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Urgent_care
>> The urgent care tag is used at, for example, clinics, that offer walk-in
>> service
> 
> isn't "walk-in" already included in reservation=no ?
> and/or with emergency=yes ?
> 
> ___
> 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] Rarely verified and third-party data staleness in OpenStreetMap

[Marc M.]

Le 06.04.20 à 15:09, Paul Allen a écrit :
> in your own app

so every app 'll have it's own lascheck database ?
so when I do my annual check-up of all the POIs in my comfort zone,
It 'll need going into the different related quality monitoring
applications them to mark that it's up to date so that several of us,
on several applications, can use the work I've done ?

on paper, the argument "do this in your own db" is easy,
it allows not to have to think about the problems of outdated poi
badly detectable in osm

on a community level, it's the worst solution, much worse than adding
an updated date on the small part of the 4 million shops=* that have
been checked this year and that have not changed since f.e. last year,
especially since there is often other information to be added during
the annual audit, and in this case, metadata already got updated (even
if too few tools are able to extract the date of last source=survey
changeset for a poi, but this is another subject)

> say drinking_water:ewp_id

or use https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID
or a wikidata, that's avoid the need for several external database
to add their own id to the same object
and if you still need a ref in osm, please don't use
drinking_water:ewp_id but a key like ref:*

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

Re: [Tagging] Rarely verified and third-party data staleness in OpenStreetMap

[Marc M.]

Hello,

Le 06.04.20 à 09:31, European Water Project a écrit :
> I have been thinking about ways we can efficiently verify data

here's my workflow :
- once a year, I query all poi (bar, restaurant, shop) within my comfort
zone, and check all tag again.
if nothing change, I update the tag survey:date=-MM on it

of course the main problem occurs when everything is not checked (does
the wifi work?) or verifiable (does the fire hydrant work?).
for this last point, during the proposal on fire hydrants, we had agreed
to use operational_status:date, for this king of technical object, it's
fine.
for a test of the restaurant wifi, it's not ideal, maybe not even desirable
for opening jours, I don't know what to use.
seeing the restaurant (source=survey) doesn't say clearly what was seen,
was it just the fact that the restaurant was open? also the name ?
or all the tags like I do ?
of course one solution is to put lots of tag1:date tag2:date
I hate this because the next contributor will modify tag1 without
necessarily modifying tag1:date (it's the same problem with the source
tag on objects that informs the source used by the one who added the
object and not the source of the current object, with sometimes big
difference such as a change of poi type)

Regards,
Marc

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

Re: [Tagging] Feature Proposal - RFC - Urgent Care

[Marc M.]

Le 05.04.20 à 17:06, Ty Stockman a écrit :
> https://wiki.openstreetmap.org/wiki/Proposed_features/Urgent_care
> The urgent care tag is used at, for example, clinics, that offer walk-in
> service

isn't "walk-in" already included in reservation=no ?
and/or with emergency=yes ?

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Marc M.]

building=* is also not mandatory,
that doesn't prevent a lot of ppl to use building=yes :)

any better idea to solve Kevin's question?

Le 05.04.20 à 00:13, Volker Schmidt a écrit :
> mtb:scale is not mandatory.
> If you are not familiar with the MTB scale don't put it. Put what you
> see: surface; smoothness; width; visibility ; ...
> 
> 
> On Sat, 4 Apr 2020 at 23:57, Marc M. wrote:
> 
> Le 04.04.20 à 15:47, Kevin Kenny a écrit :
> > how does a mapper who isn't expert enough to grade accurately
> > the difficulty of a MTB trail, but can
> > clearly see, 'a road bike wouldn't work here'
> 
> it's very subjective
> an example of a situation that was not well described with
> surface/inclined/... tags ?
> 
> you may use =yes as default value when you don't use a more precise
> value -> mtb:scale=yes ?
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto: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] Can highway=cycleway be limited to MTB?

[Marc M.]

Le 04.04.20 à 15:47, Kevin Kenny a écrit :
> how does a mapper who isn't expert enough to grade accurately
> the difficulty of a MTB trail, but can
> clearly see, 'a road bike wouldn't work here'

it's very subjective
an example of a situation that was not well described with
surface/inclined/... tags ?

you may use =yes as default value when you don't use a more precise
value -> mtb:scale=yes ?

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Marc M.]

Le 04.04.20 à 11:26, Florimond Berthoux a écrit :
> 
> Le sam. 4 avr. 2020 à 10:18, Snusmumriken a écrit :
> 
> On Fri, 2020-04-03 at 20:53 +0200, Florimond Berthoux wrote:
> > For this one https://www.youtube.com/watch?v=B7wbi4wGbsg (Andrew's
> > example)
> > We're on the edge of tags definition : this a path limited cyclist,
> > where a mountain bike almost mandatory to ride there. Some features
> > help the cyclist.
> 
> bicycle=yes is an access tag

+1
without a traffic sign related to access (I can't read the pannel),
I only use
higway=path
mtb:scale=2
incline=yes
mtb=designated <- if the pannel is related to mtb

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Marc M.]

On Sat, 4 Apr 2020 at 00:01, Joseph Eisenberg wrote:
> highway=cycleway + mtb=designated has been used 558
> times: http://overpass-turbo.eu/s/Sjl

your query target highway=cycleway + mtb=yes
Does exit a sign "cycleway not alloed with a mtb" ?
if not, this tag add no additional value or is an error.

highway=cycleway + mtb=designated is used only 25 times
https://overpass-turbo.eu/s/SjA

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Marc M.]

Le 03.04.20 à 11:54, Andrew Harvey a écrit :
> 
> 
> On Fri, 3 Apr 2020 at 20:42, Marc M. wrote:
> 
> Le 03.04.20 à 11:22, Andrew Harvey a écrit :
> > work out how a dedicated mountain bike track should be 
> > tagged if not highway=cycleway
> 
> what's on the ground for those way ?
> I'm in favor of leisure=track sport=mtb
> 
> https://www.google.com/search?q=mountain+bike+track=lnms=isch=X=1914=981

> It could be that pedestrians can use the track

the first page does not show any sign suggesting that
it is also a pedestrian area
imho "It could be" is not enough to add foot=yes

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Marc M.]

Le 03.04.20 à 11:22, Andrew Harvey a écrit :
> work out how a dedicated mountain bike track should be tagged if not
> highway=cycleway

what's on the ground for those way ?
I'm in favor of leisure=track sport=mtb

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Marc M.]

Le 02.04.20 à 23:07, Volker Schmidt a écrit :
>> The trouble with this is that very few trails are 'designated' for
>> riding a bicycle.  They are legal for bikes, hikers, and horses.
> 
> Please not that this is different in at least three countries in Europe:
> highway=cycleway excludes any other means of transport including foot.
> 
> See also the tables in
> wiki Access Restrictions
> 

and for somes countries, it need a blue traffic sign,
as display https://wiki.openstreetmap.org/wiki/Tag:highway%3Dcycleway
it's a strong implication

I never see this sign for a path used by mtb-user,
so I never use highway=cycleway in that case.

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Marc M.]

Hello,

Le 02.04.20 à 12:13, Yves a écrit :
> I disagree here, a cycle map should not ignore mtb:scale

please keep the principle of least surprise in mind.
highway=cycleway not-for-bicycle is like a "highway=footway + foo=no"
or like "building=yes fullydestroyed=yes"

I can't find the wiki page that says it so well,
but don't use a subtag that radically changes the main tag.
everyone must be allowed to limit themselves to the main tag
and have a limited but correct vision of what it is.
subtag ADD infos to the main tag.

imho highway=cycleway limited to MTB is a bad idea.
it should be a path

Regards,
Marc

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

Re: [Tagging] Add man_made=goods_conveyor to Map Features or vote on the proposal first?

[Marc M.]

Le 11.03.20 à 23:47, Joseph Eisenberg a écrit :
> The tag man_made=goods_conveyor was proposed years ago for industrial
> conveyor belts and systems which move goods like mining ore. It is now
> documented as "in use" and used over 4000 times:
> 
> https://wiki.openstreetmap.org/wiki/Tag%3Aman_made%3Dgoods_conveyor
> 
> "A stationary conveyor system for transporting materials between locations."

you may do both :
- run a RFC/vote because it's the best way to get the maximum amount of
feedback and get the "approved" status
- add to the maps feature right now, if the RFC/vote show a major issue,
it's never too late to revert that.

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

Re: [Tagging] highway=bus_stop is PTv2 compatible (was: Re: Feature Proposal - RFC - Public Transport v3)

[Marc M.]

Le 11.03.20 à 10:53, Mateusz Konieczny via Tagging a écrit :
> I am not entirely sure why it was done this way

because the too many opposing "if a tag has more than X occurrences,
it must be kept for eternity".
then some proposals for improvement have no choice but to first propose
a new one without depreciating the old one and then hope one day to
reopen the debate if the new tag surpasses the old one, which doesn't
happen if only the old one is render, it's the cat that bites its own tail.

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

[Tagging] camp_pitch : an area inside a site : also in a park ?

[Marc M.]

Hello,

When fixing depreciated tag camp_site=camp_pitch,
I've found several of these in huge parks in the United States.
the current and approved definition of tourism=camp_pitch says that
sites are tourism=camp_site or tourism=caravan_site
however these parks often have identical characteristics to these
tourism=*_site : they sometimes have a common reception desk for
different camp_pitch, toilets, a drinking water point, ...

what do you think is the best schema :
- Change the definition of tourism=camp_pitch to include these large
parks as a valid _site.
- add tourism=camp_site on the whole park ? with the default of having 2
main tags on the same object
- other ideas ?

one among others https://overpass-turbo.eu/s/Rsg

Regards,
Marc

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