Re: [Tagging] [RFC] Feature Proposal - works:type and works:process

[Marc_marc via Tagging]

Hello,

Thanks for the time you spend on that.

Le 26.04.24 à 20:37, Daniel Evans a écrit :

https://wiki.openstreetmap.org/wiki/Proposal:Works:type_and_works:process


:type is a meaningless suffix
it could be :type=big<>small, green<>polluting, local<>not local, ...

could you please find a better descriptive key ?

Regards,
Marc



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

Re: [Tagging] Closing the Digital Wallet Payments V2 RFC

[Marc_marc]

Le 04.12.23 à 17:46, Reinhart Previano Koentjoro via Tagging a écrit :

1. Prefer multiple tagging keys to avoid multiple values, which is
    still considered as bad practice in OpenStreetMap.


really ? this is considered bad practice for primary keys.
fortunately, we haven't yet reached the point where we consider that 
opening_hours values must each be the subject of a =yes key.

currently the issue is that's a bad pratice to have value as key
but in the same time, we don't have a schema to store
a negative value (this shop doesn't accept Visa for ex)
and due to this, payement value are store as key :(



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

Re: [Tagging] [RFC] Feature Proposal - lifecycle prefix vandalised:

[Marc_marc]

Le 17.09.23 à 15:59, Anne-Karoline Distel a écrit :

If you come to a bench that is no longer there, "vandalised:" would not
apply. If the seats are damaged to an extend that you cannot sit on it
any longer, then it would.


so vandalised for you mean "intentionally taken out of service but still 
there" ?


life isn't all black and white :
a bench with grafiti is vandalised and yet still usable -> amenity=bench 
is appropriate (and the grafiti is relegated to color or 
operational_status or whatever)

a children's playground with one of the attractions unusable is still
a playground and yet it is vandalised
a phone box with a destroyed window has been damaged or vandalised, yet 
the phone may still be usable (and what's more, if you weren't there, 
there's no way of telling whether or not the window was destroyed 
intentionally or not)

a road sign with a sticker or a small piece of graffiti is still
usable as a sign, despite being vandalised.

that's why using the word vandalised as a lifecycle doesn't seem to me 
to fit the nuance of reality: not everything that is vandalised is out 
of use




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

Re: [Tagging] [RFC] Feature Proposal - lifecycle prefix vandalised:

[Marc_marc]

Le 17.09.23 à 12:50, Anne-Karoline Distel a écrit :
I'm proposing to establish the lifecycle prefix "vandalised:" 
which has been in use for at least 8 years in some form


https://wiki.openstreetmap.org/wiki/Proposal:Vandalised:


I wonder if it makes sense to be so precise about "past" life cycles:
you arrive at a place, the bench is no longer there
Has it been dismantled? destroyed? vandalised ? unintentionally damaged?

If you're not there at the precise moment of the change of state,
the only thing you can see is that the bench is no longer there
or isn't in a working state anymore
2 "past" lifecycles seems sufficient to me (was: for when there's 
nothing left, damaged or equivalent for when there's something 
non-functional)


PS : and what's the meaning of vandalised:last_check ?
someone vandalised your last_check ?
it seems more logical to me to put survey:date
if you want to store this meta data

Regards,
Marrc



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

Re: [Tagging] Postal verses locational addresses

[Marc_marc]

Le 13.09.23 à 19:21, Jez Nicholson a écrit :

OSM addresses are physical, 'locational' addresses


ok


it is the anomalous postal addresses that need to have their own schemeif 
at all.


some mapper in France are using contact:* for that (and also
some contact:addr for a kind of number+street and sometime CP+city)

note that no (including fr) app is known for using that
and due the fact that some mappers also put physical/locational 
addresses into contact:*, you can't know what this info represents 
without having the other addr:* object with the same address

to compare the distance between the 2



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

Re: [Tagging] Streets with gradually increasing widths

[Marc_marc]

Le 15.08.23 à 14:39, Kashish via Tagging a écrit :

pbnoxious suggested using width=* to specify the mean/median width


I don't think it's a good idea as it break previous usage of this key :
width=* is about the minial witch for the whole segment.
if a router want to use it, it should be able to use it
without any mandotory use of width:start :end or whatever
so don't redefine ann in-use tag

so ok to add any subtag to describe how width change inside a segment
but strongly against any change for width=*



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

Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

[Marc_marc]

Le 10.08.23 à 14:22, Brian M. Sperlongano a écrit :


On Thu, Aug 10, 2023, 6:28 AM Marc_marc <mailto:marc_m...@mailo.com>> wrote:


with this argument, you'd have to remove all the shop= office=*
craft=*,


Nonsense.  Everyone knows what a craft=brewery is.  
It's not volatile at  all.


my argument is that shop office craft change more often than areas 
without gsm reception, cfr the example above: the location has gsm 
non-reception characteristics "for life", while the occupant has already 
changed 2x.


perhaps in your country the shops are immutable, here that's not the 
case, and in my eyes that's one of the most volatile pieces of data in 
osm, I check them every year and every year there are changes to be 
made... the areas without reception that I know of have been like that 
for over a decade, there would have been nothing to change in the last 
15 years.




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

Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

[Marc_marc]

Le 07.08.23 à 21:44, Mark Wagner a écrit :
The problem with this proposal is that coverage information 
is really only interesting on the fringes


set let's map on the fringes :)

you could say the same thing about surface=asphalt...
adding this to a motorway in some countries
is not very interesting, it provides information
on the fringes :) outside the main road network.

PS: the dentist's surgery I mentioned in my previous email
is located in a capital city, and the multi-purpose room I'm talking 
about is within sight of a 4G antenna if you leave the building

so it's not the 100 km2 white zone that everyone knows about.
it's spots... and not everyone knew that, at least not me :)

it's also fairly stable information : the dentist's surgery
has been like this for at least 15 years,
the multi-purpose room is probably as old as I am, while the
club's name has already been changed (perhaps club=* should
be deleted, too volatile, and everyone knows it - is that the logic?)



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

Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

[Marc_marc]

Le 10.08.23 à 10:03, Frederik Ramm a écrit :

volatility.


with this argument, you'd have to remove all the shop= office=* craft=*, 
it's much more volatile than the concrete wall surrounding the music 
room I mentioned in the previous email.

let's also remove maxspeed, more volatil than concrete wall

The goal would be better served by a (non-OSM) service that 
automatically collects data from apps that people have installed on 
their phone and that sends measurements to a server while they are 
moving around.


and then ? How do you see the possibility of, for example,
Qwant map informing you that the POI selected is not covered by the GSM 
network while the POI on the floor above is covered?

is it mandatory to add ele to opencellid.org and osm to be able to link
to correct poi to the correct data ? are we also going to delete 
internet_access=* and replace it with openinternetaccess.org ?


Meanwhile, Overture will be welcoming data with open arms,
and we'll be wondering why openstreetmap has become nothing more
than a one-line technical detail in news about geomatics.

I think we're really better off accepting a =no =limited =yes key
for those who see a use for stable situations (obviously it's not
a question of mapping a temporary fact).

Regards,
Marc



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

Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

[Marc_marc]

Le 08.08.23 à 02:13, NickKatchur via Tagging a écrit :
# The reduction of additional tagging models to only strength with 
excellent/good/low/issues/none options.


imho it's already include in =no =limited =yes




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

Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

[Marc_marc]

Hello,

Le 06.08.23 à 21:18, NickKatchur via Tagging a écrit :
https://wiki.openstreetmap.org/wiki/Proposal:Cell_reception 


I'm a bit amused, or rather disappointed, to read comments like
"it's complicated to estimate the number of reception bars because
it depends on the phone". Were these kinds of comments made after 
reading the proposal or simply in reaction to the headline?

the proposal isn't about encoding the number of reception bars.

I don't see what problem there would be in me entering that my dentist's 
surgery has no GSM reception, nothing ever, I don't see what lack

of objectivity there would be in encoding this in osm.

I don't see what problem there would be in saying that another POI has 
major reception problems but that it still works, it doesn't matter if 
you have 2 bars and I have 3, it doesn't change the fact that it's

much less than the average you'd expect in this kind of place.
and so the =no and =limited values seem to me to be much more objective 
than some route classifications


Regards,
Marc



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

Re: [Tagging] [RFC] Feature Proposal - Intentionally omitted name tags

[Marc_marc]

Le 30.07.23 à 20:47, Nick Santos a écrit :
If your question was about a "global data user" and not  
a "global database", I think my point still applies -  
having the database make the decision


database don't make decision. database store the local decision :)
datause may follow this decision or decide another rule (for ex always 
take name:fr first, if missing take name:en, if missing take name:eo,

if missing take name=*, if missing take brand=*)


pick and choose by region.


the current rule is : to choose by region, take name=* !
you're just shifting the problem around :
which regional choice should osmcarto make for golf ?
and where will this choice be stored if not in name=* ?
this_is_not_the_name_tag_but_still=* ?
and you still disaggree about it, what's the next step ?

If all data users wanted to make this choice, we wouldn't
be having this discussion and there wouldn't be any editwars
over golf or the ocean.
the fact that there is an editwar shows that there are uses that
don't want to make this choice, or are simply unable to do so
or choice to use the name as set by concensus in name=*

if you want to route a chinese person to "Station street" in Brussels" 
how is the application going to guess that the local convention are

to have the name in 2 languages "Rue de la gare - Stationstraat" ?
if you tell me to use default_language="fr - nl" then that shows
that we don't need to delete name :) not to add a fake noname=*
if an American wants to add the name of a street sign in Fribourg,
does he need to have any linguistic knowledge to fill in the name:xx ?
or he just need to read the sign and put in into name=" ? easy !

As for disputed names, the hidden goal "delete unwanted name=*"
doesn't solve anything either !
We haven't solved the problem of disputed borders by deleting
anything, we've added a tag to describe the opinion according
to A and the opinion according to B, which is exactly what exists
with name:X
if you want the name "according to the language foo", look
at name:foo
we also have name:xy-foo if a "part of this language community"
have another name:yx, for ex UN variant

create a disputed_by:name of whatever, but it has nothing
to do with a nameless object, so don't distort noname=* nor
delete name to do this, disputed doesn't mean "noname"

Regards,
Marc



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

Re: [Tagging] [RFC] Feature Proposal - Intentionally omitted name tags

[Marc_marc]

Le 30.07.23 à 18:52, Brian M. Sperlongano a écrit :
On Sun, Jul 30, 2023 at 12:08 PM Marc_marc <mailto:marc_m...@mailo.com>> wrote:


did we need to have this thread again and again ?

What do you believe should go into the name tag of the bodies of water 
known in French as océan Atlantique or the body of water known 
as Itämeri in Finnish?


my personal preference is to have a name=* in a neutral language
such as esperanto

currently it's often English that's used for that, and I find that
much worse than making no choice at all, as you suggest
because many datause will have to make a choice

as you can see on https://www.openstreetmap.org/node/305640306/history
adding nome=* doesn't solve the publishing wars

I'll return the question to you: what name should a global datause
for an object without name=* ?
and does your proposal to "add" a noname=multi_langual hide a "deleting 
the names I disapprove of is nomore a vandalism but approved" ?
because I have no isue to add a tag to express that name=* is 
multilingual (exept that the tag already exist and isn't a noname=")

but that doesn't mean "the rule for name=" changed"

Regards,
Marc



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

Re: [Tagging] [RFC] Feature Proposal - Intentionally omitted name tags

[Marc_marc]

Le 16.07.23 à 02:38, Brian M. Sperlongano a écrit :
Comment is requested on a proposal to introduce two tags to indicate the 
reason why a name=* tag has been omitted from a feature:


https://wiki.openstreetmap.org/wiki/Proposal:Omitted_name_tag 


did we need to have this thread again and again ?
1) the fact that a name is disputed doesn't mean that it doesn't have a 
name. if it doesn't have a name, then the name isn't disputed !
2) the fact that a name exist in several local language again isn't a 
subdivision of "this doesn't have a name", default_langage may already

be used for that

about the rationale
1.1. yes it's possible to solve vandalism issue about the Persian Gulf / 
Arabian Gulf naming dispute : just revert the vandalism.
adding a noname=for me it should not have a name=* but for another it 
should have one" doesn't solve the issue, you only have 2 tags for a 
waredit in stead of on
1.2. I see a used case if you see something rongly  tagged with 
noname=yes and delete it but aren't not sure yet how to spell the name=*

I also doesn't see why you call it trolltag

so in fact, you don't only want to add new tag to express why somebody 
think that an object shouldn't have a tag, you also want that ppl

that think that are allowed to remove the name tag
that's a *bad* idea.
how did I render a name in that case ? how 'll it solve the Persian Gulf 
/ Arabian Gulf naming dispute ? currently showing disputed name

is better than don't show anything because someone disagree with
the more common name(s)

Regards,
Marc



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

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

[Marc_marc]

Le 19.06.23 à 23:52, Graeme Fitzpatrick a écrit :



On Tue, 20 Jun 2023 at 02:57, Illia Marchenko 
mailto:illiamarchenk...@gmail.com>> wrote:


As possible solution, *shop=weapon*


Sorry, but speaking as a recreational shooter, & on behalf of all 
others, we find the use of the term "weapons" for our chosen sporting 
tools more than somewhat offensive - recreational shooters don't use 
weapons, the military does!


We would /much/ prefer to see it listed as either shop=gun/s or 
=firearms, rather than =weapons.


with *sells=firearms;knives*. 



As not all gunshops sell all types of gun, that could also then be 
broken down further into the classification of guns that they sell e.g.

guns=rifles;shotguns;pistols

On Tue, 20 Jun 2023 at 03:48, Marc_marc <mailto:marc_m...@mailo.com>> wrote:



 > Maybe also create shop=knives page

Does it make sense to create a primary tag for each type of weapon?


Yes it does, as you also have shops that are primarily intended  
to sell knives


I never said it didn't exist, I'm saying that it's not adapted
to the reality of shops that don't necessarily sell just one type
of object.

so now that we have a documented tag shop=knives,
how to tag a shop that sell knives and arcs ? shop=knives;arcs ?
of course not
when we have found the right term for this shop, the previous case
could have been handled in the same way with details in a secondary tag



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

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

[Marc_marc]

Le 19.06.23 à 18:25, Mateusz Konieczny via Tagging a écrit :

I propose (based on info I gathered to)
- remove claim that shop=guns should be replaced by shop=weapons
(due to information loss, there are also for example shops selling knives)


or improve the advice to avoid the lost : shop=weapons weapons=guns


- remove shop=firearms and shop=gun and shop=guns redirects


I see no added value to remove shop=gun redirect.
is there a difference between shop=gun and shop=guns ?
if not, shop=gun should be redirected to shop=guns


Maybe also create shop=knives page


Does it make sense to create a primary tag for each type of weapon?
I find it very fragmenting, especially as there will inevitably be shops 
selling 2 items with different primary tags, which merits a secondary 
tag and not a shop=guns;knives
Create shop=firearms page, describing shop=gun and shop=guns as 
duplicates of it.


if it's a duplicate, we don't need a dedicated page,
a redirect is enough.
but I'm not en english native.

Regards,
Marc



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

Re: [Tagging] [Voting] Level crossing train horn usage

[Marc_marc]

my mistake, it's ok.

Le 16.06.23 à 18:44, wolfy1339 a écrit :

It was posted for the RFC.

https://lists.openstreetmap.org/pipermail/tagging/2023-March/067118.html

On 2023-06-16 10:01, Marc_marc wrote:

Le 15.06.23 à 16:27, Clay Smalley a écrit :
Voting has started on the proposal to introduce the key 
crossing:whistle=*.

https://wiki.openstreetmap.org/wiki/Proposal:Level_crossing_train_horn_usage


it miss the RFC annoncement on the tagging mailing, so it's invalid 
and need restarted at the RFC staage




___
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] [Voting] Level crossing train horn usage

[Marc_marc]

Le 15.06.23 à 16:27, Clay Smalley a écrit :

Voting has started on the proposal to introduce the key crossing:whistle=*.
https://wiki.openstreetmap.org/wiki/Proposal:Level_crossing_train_horn_usage


it miss the RFC annoncement on the tagging mailing, so it's invalid and 
need restarted at the RFC staage




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

Re: [Tagging] navigational aid relation

[Marc_marc]

Le 14.06.23 à 19:08, Florian Lohoff a écrit :

the centroid of the object



this is not algorithmically solvable.


you state the problem that makes the algorithm bad :)
when you want to go to a surface object, you don't want
to go to the centroid

for surface objects, take :
- all entrance=* objects on the outer with priority given to main 
entrances (and parking if you're in vehicle mode)

- if there are none, take the intersection with all highway=*
- classify these itineraries as any other (fastest, shortest, ...)



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

Re: [Tagging] navigational aid relation

[Marc_marc]

Le 14.06.23 à 09:26, Florian Lohoff a écrit :

source= - Original object we like to reach


not source=* !  we  already have 3 meanings for it :
- how was the data acquired (for ex source=survey)
- the context of a data (for ex source:maxspeed=urban)
- the primary energy (for ex generator:source=solar)

maybe for=* / destination=*

your idea could be used for POIs where the parking lot isn't
in front of the door

but if your house is marked with a path to the door, it's obvious
that this is the path that should be proposed and any 
"not-using-an-existing-highway=*" should have a gig penality to be used only

when the last highway=* is missing

for the example 1 you give seems to me to be more of a problem
1) misuse of the private tag: not only can you walk past the barrier, 
but if you want people to go to the barrier and then continue by car to 
their destination, then it would probably be better to put 
motor_vehicle=destination in the way

2) penalty for no highway=* too low: crossing the forest should
be much more penalizing than using the private road.
3) bad penality for =destination and =private
https://www.openstreetmap.org/directions?engine=graphhopper_car=51.98881%2C8.57457%3B51.98836%2C8.57434#map=16/51.9898/8.5832
very fun... but i didn't see why the routing do that



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

Re: [Tagging] road accident memorials

[Marc_marc]

Le 11.06.23 à 13:29, Anne-Karoline Distel a écrit :

https://www.openstreetmap.org/node/10967549672

subject=Sandy or subject=Sandy the dog or subject=pet?


I consider subject=* to describe a category: if the dog is well enough 
known, I'll use subject=Sandy (and probably create a wikidata for it one 
day)

if it's a dog that's only important to its owner, subject=dog seems
more interesting to me
but I hear that some would like Sandy is a dog which is a mammal
which is an animal etc.
for me it's not very useful information in osm, it's more a 
classification for wikidata



Maybe memorial:animal=dog would be an option.


namespaces are used to avoid conflicts between 2 innfos with
the same key (e.g. the name of a highway=* and the name of the bridge), 
so one of the 2 is prefixed with the namespace (e.g. bridge:name).
here I can't see what conflict there could be, there are no other 
animal=* to put on the object

so adding prefixes makes no sense
likewise animal seems to me to be an information and not a key
whose value provides information, which is why it seems preferable
to me to have =animal



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

Re: [Tagging] road accident memorials

[Marc_marc]

Le 10.06.23 à 16:40, Anne-Karoline Distel a écrit :

I would like to be able to differentiate memorials for road traffic
accidents from other memorials along a road


memorial:conflict=road_accident


On a side note, I'd also like to tag memorials for pets different than
for events and people.


subject=*

Regards,
MArc



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

Re: [Tagging] amenity=bbq without grill/grate ?

[Marc_marc]

Le 10.06.23 à 00:08, Matija Nalis a écrit :

On Thu, 23 Feb 2023 18:50:21 -0500, Kevin Broderick  
wrote:

It makes sense to me if the feature is clearly intended to be a
BBQ/grilling one, but the grill is missing. One such example that comes to
mind is a state park with picnic tables and grill boxes where 1/3 of the
latter are missing the grills.


I think in such vandalized case it would be better tagged as
disused:amenity=bbq or abandoned:amenity=bbq


how do you find out if the grill has been stolen or if it's a dedicated 
place for a bbq without a grill ?


does the user of the data need to know if the grill has been stolen
or if the place has simply never had a grill? in the end,
the only information you need to bring along is your own.

that's the absurdity of lifecycle namespaces : exept was:, all
the others provide information about how the absence of the element 
occurred (razed, demolished, destroyed), whereas when you look
at the present, apart from a destroyed building whose rubble is still 
present, there's no information about how it happened.)




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

Re: [Tagging] Coach parking

[Marc_marc]

Le 09.06.23 à 23:12, Anne-Karoline Distel a écrit :

it might be useful to create a MapRoulette task to get rid of
all the name tags.


if you want to make a mass edit, please don't hide it under
a MapRoulette task but send a notice/request to talk



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

Re: [Tagging] Coach parking

[Marc_marc]

Le 09.06.23 à 14:35, Andy Townsend a écrit :

https://taginfo.openstreetmap.org/tags/name=car#overview

which seems to be commonly used as a name for (presumably coach) parking 
in France


yes car in French mean long distance bus
but i never see a sign with "long distance bus only",
so I suppose it mean bus=yes



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

Re: [Tagging] Coach parking

[Marc_marc]

Le 09.06.23 à 16:24, Greg Troxel a écrit :
It seems coach is for distance and 'bus' is used for within 
a city as part of a rapid transit system.


and what for "coach (long distance) and (local) bus" ?
doesn a traffic sign exist for both ?
if not, the isssue isn't the english wording about the value



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

Re: [Tagging] Coach parking

[Marc_marc]

Le 09.06.23 à 11:52, Greg Troxel a écrit :

I find the women/parents strange, as I have never seen such spaces


some shop have "family" parking_space closer to the entrance or where 
there is a larger pedestrian area so that the first child can wait in 
safety while the parent looks after the second.


If the wiki doesn't have a photo, I'll take one.



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

[Tagging] [RFC] Deprecate maxspeed:seasonal:winter

[Marc_marc]

https://wiki.openstreetmap.org/wiki/Proposal:Deprecate_maxspeed:seasonal:winter

Deprecate maxspeed:seasonal:winter only is nonsense,
it's the whole maxspeed:seasonal:* that need to be grouped in one shoot

but we also have maxspeed:wet maxspeed:snow (and maybe other)
it make sens if we want to keep those easy shortcut or not
or convert all of those into more complex (but in only one key) 
maxpseedconditional




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

Re: [Tagging] [Voting] Deprecate maxspeed:seasonal:winter

[Marc_marc]

Le 07.06.23 à 02:28, Matija Nalis a écrit :

Voting has started on the proposal to deprecate maxspeed:seasonal:winter.

Please vote on the wiki 
pagehttps://wiki.openstreetmap.org/wiki/Proposal:Deprecate_maxspeed:seasonal:winter


RFC start:  2023-05-23
but I don't see any request for comment here at that time
https://lists.openstreetmap.org/pipermail/tagging/2023-May/thread.html

so please restart it at RFC stage, I have changed the page according to 
the issue




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

[Tagging] date not in YYYY-MM.DD format should go into a sufix edtf ?

[Marc_marc]

a contributor change to wiki to tell that "For dates that cannot be 
expressed in -MM-DD format, such as approximate or uncertain dates, 
or times of day, use the end_date:edtf=* key in addition to this key. "


did you agree with that ?
start_date if full of not -MM-DD including Cxx for historical monument

 Message transféré 
https://wiki.openstreetmap.org/w/index.php?title=Key:end_date=next=2426470

Editor's summary: [[Key:end_date:edtf]]
mail: https://wiki.openstreetmap.org/wiki/Special:EmailUser/Minh_Nguyen
wiki: https://wiki.openstreetmap.org/wiki/User:Minh_Nguyen




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

Re: [Tagging] Tagging proposal On Wheels app 2 - Changing places and changing table

[Marc_marc]

Le 16.05.23 à 13:23, ro...@onwheelsapp.com a écrit :
  * changing_table:size 


you mean width lenght ? if so, use width lenght


  or changing_table:user_type   (children, adults)


type has not meaning on its own,
better to use the more common :for suffix -> changing_table:for
for childeren see also 
https://wiki.openstreetmap.org/wiki/Key:changing_table




  * changing_table:hoist


can you describe the meaning ?

  * changing_table:type 
     (manual, electric, fixed)


:type is a meaningless suffix (another user may use it
for any other caract)

did you look for a tag to describe how the height can be changed ?
maybe something like height_operated=manual, electric, no



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

Re: [Tagging] Tagging proposal On Wheels app 1 - toilets wheelchair extra tags

[Marc_marc]

Le 16.05.23 à 13:23, ro...@onwheelsapp.com a écrit :

*_Toilets:wheelchair_*


if you want to add so much information, I think it would make sense to 
create an amenity=toilets object instead of sticking it on the POI, this 
will give information on its position and will also allow to deal with 
the case of 2 toilets not having the same characteristics


toilets:wheelchair_door_width        (for the door width of the 
toilet)


the correct namespace separator is ":", no the "_"
so if you want to glue all info on the poi
toilets:wheelchair:door:width
or an amenity=toilets + wheelchair=yes + door:width=*

toilets:wheelchair_space_side   (for the space next to 
the toilet)


toilets:wheelchair:space_side

toilets:wheelchair_space_front (for the space in front 
of the toilet)


toilets:wheelchair:space_front

shower:wheelchair   (for a 
wheelchair accessible shower, answer with yes/no)


or it's own object with amenity=shower + wheelchair=*

With the On wheels app we measure the narrowest point from the entrance 
to the toilet. We want to give this an OSM tag,
but it is hard to find a good one. There are no indoor tags that 
describe a narrowing of a path. A possibility is to add the > following combination of tags: highway=path, indoor=yes, width=.


that's fine


For the moment our app has no option to add separate
indoor tags like toilet, elevator, doors, … So all the tags are 
connected to the main tag of the building.


this will severely limit you unless you introduce some very twisted rules.
a poi for example has 2 amenity=toilets, which do not have the same 
characteristics in terms of space, door width, etc

How are you going to fill this in on a single object?



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

Re: [Tagging] Tagging proposal On Wheels app 3 - Parking spaces for

[Marc_marc]

Le 15.05.23 à 18:47, ro...@onwheelsapp.com a écrit :

Hi everyone,

So if I understand correct most parking spaces are mapped as polygons?


yes
https://taginfo.openstreetmap.org/tags/amenity=parking_space

I don't see the problem to add a width and length tag to 
a parking_space node,


there is no problem except to be aware that this is the least common 
schema and the one that gives the least information, and that therefore 
any contributor can convert a width=A length=B into a surface object 
having this dimension and which will also give a position of this object 
in relation to the others (does the parking space touch the neighbouring 
parking_space, does it touch a kerb, etc)



because this is more detailed info about the dimensions of a parking space,
that is actually measured by people on site with a measure tape.
the polygon data is not accurate enough to really use for our app.


I don't understand this argument despite the fact that to repeat it :
a node width=A length=B is not more precise than a polygon
with thoses dimensions


Are there other apps that add info about parking places as polygons and
extract dimension info from the polygon data?


most map style, including osm-carto (the main style on osm.org)




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

Re: [Tagging] Perimeter of a pitch

[Marc_marc]

Le 21.05.23 à 23:47, Graeme Fitzpatrick a écrit :

2 - a rectangular leisure=pitch for the actual playing area


but what's the playing area ?

in tennis you serve from outside the line,
So you serve outside the playing area ?
the marking used depends on whether you play singles or doubles,
will you make 2 leisure=pitch ?

in table tennis, the player is never on the table :)
does he play all the time out of the playing area ?
it's a bit contradictory.

for a multi-sport pitch, there are several markings
so several leisure=pitch ? yet if you ask a non osm contributor,
there is only one pitch

for my part, when the space is clearly delimited, the leisure=pitch area 
is this space, up to the barriers for ex




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

Re: [Tagging] Tag government equals emergency defintion

[Marc_marc]

Le 17.05.23 à 09:41, Warin a écrit :

in another email you state

"some centres are not governmental (e.g. in Switzerland, mountain rescue 
is assigned to private companies such as Air Glacier)"


So the tag may also be applicable to non government offices???


no, Air Glacier (among others) isn't a office=government



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

Re: [Tagging] Tag government equals emergency defintion

[Marc_marc]

Le 17.05.23 à 09:20, Warin a écrit :


On 16/5/23 19:08, Marc_marc wrote:
- some centres are not governmental (e.g. in Switzerland, mountain 
rescue is assigned to private companies such as Air Glacier)

office=association ?


it's a pretty poor content tag, it doesn't say anything more
than office=yes operator:type=ngo
especially it doesn't say what the activity of this place is,
while all the other values (except =yes =compagny) describe the activity

I only use this tag temporarily when the activity of an association
is not known to me or when I don't know the tag by memory in case of 
contribution by mobile application, which sometimes limits the 
accessibility to wiki or less common values)






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

Re: [Tagging] Area of young trees - saplings

[Marc_marc]

Le 16.05.23 à 14:42, Dave F via Tagging a écrit :

areas where you trees are planted? Too small


natural =wood + start_date + height :)



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

Re: [Tagging] Tag government equals emergency defintion

[Marc_marc]

Hello,

Le 16.05.23 à 00:22, Graeme Fitzpatrick a écrit :

suggestion of office=government + government=transportation
+ emergency=control_centre


- there are 2 main keys (office and emergency), inevitably some objects 
will have only one of the 2 and this will complicate things
- some centres are not governmental (e.g. in Switzerland, mountain 
rescue is assigned to private companies such as Air Glacier)


so I think it is useful to make a difference between
- the administrative services of the state in charge of
a given subject -> office=*
- the logistic base

Regards,
Marc



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

Re: [Tagging] Tag government equals emergency defintion

[Marc_marc]

Hello,

Le 15.05.23 à 09:13, Warin a écrit :

clear definition
Possibly something like

"Used to mark the office of an emergency organization,  
where administration, planning and control is performed.


add government somewhere in the def :)
if not, the tag could be used for Red Cross office.

Regards,
Marc



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

Re: [Tagging] Tagging proposal On Wheels app 3 - Parking spaces for wheelchair users

[Marc_marc]

Le 14.05.23 à 19:59, Yves via Tagging a écrit :

everybody is not super accurate in drawing polygons


indeed, and most tools doesn't allow to request a polygon with a given 
lenght/width



I doubt a lot of mappers go trough a complete parking lot a measuring tape in 
their hands.
On the contrary, estimating a width from one's car


I don't understand this argument: the question is not to have the 
measurement (with a laser, with satellite imagery, by estimating

by comparison with his car)
the question is how to introduce this measure in osm with
3 possible choices :
either on a parent object (for example amenity=parking with 
parking_space:width parking_space:lenght) but that does not say

where the space is)
or an amenity=parking_space node with width and lenght: compared
to the previous solution, we gain the position of the space (and
anyone on the spot can obviously tell where he is when he parks
his vehicle)
or an amenity=parking_space polygon: compared to the previous
solution, we gain the surface and its orientation in relation
to the other objects.


I'd say yes to such a tag.
I have nothing against the tag, it would simply be necessary for the 
person/application in question to know that it is only one of the 3 
possible methods and that, out of the 3, it is the one that gives

the least information. so :
- if they have the possibility to make a method giving more
information, they might as well do it (at least a node 
amenity=parking_space)

- if osm has the information in the form of area, it shouldn't come
to the point of saying "no, it must be in the form of 
parking_space:width" and convert or ignore the precise methods

in favour of the less precise one
and if someone were to convert a parking_space:witdh 
parking_space:lenght to a surface of this size, the application

would not have to regress or worse, someone would have to revert
because the application does not handle it in this form

Regards,
Marc



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

Re: [Tagging] Tagging proposal On Wheels app 4 - Elevators wheelchair users

[Marc_marc]

Le 13.05.23 à 17:41, ro...@onwheelsapp.com a écrit :

*_Highway=elevator_*

**

We want to add some extra tags that are important for wheelchair users:

  * elevator:door_width


elevator:door:width on an object other that the elevator it-self
but this way of informing glued environment on the POI will quickly show 
its limits:
a POI in a building with an entrance with a small lift accessible to PRM 
and another classic entrance, it will not make sense to enter the width 
of a lift that is absent on the main entrance


same problem with the many public buildings that have an accessible 
entrance with an adapted button, but no accessible button yet on the 
lifts leading to the floors



  * elevator:width
  * elevator:depth


ok for the tag
same as in the other thread : you may also just draw an area


  * elevator_button:wheelchair  (yes, no)


we already have button_operated key [1]
so it should be :
button_operated:wheelchair  (if put on an highway=elevator)
elevator:button_operated:wheelchair (if put on another object)

take care of elevator without a button :)
button_operated=no imply that button_operated:wheelchair
is useless/unneeded/wrong

[1] https://wiki.openstreetmap.org/wiki/Key%3Abutton_operated

Regards,
Marc



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

Re: [Tagging] Tagging proposal On Wheels app 3 - Parking spaces for wheelchair users

[Marc_marc]

Hello,

thanks forr splitting topic by thread.

Le 13.05.23 à 17:03, ro...@onwheelsapp.com a écrit :

*_Amenity=parking, amenity=parking=space_*

We want to propose some new tags to add to parking spaces:

  * Parking_space:width
  * Parking_space:length


without the upper letter, that's a standard combination
you want to add this on a amenity=parking ?

because if someone is measuring it,
why not just add this information as amenity=parking_space geometry ?
more than one million places already have their dimensions filled in

Regards,
Marc



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

[Tagging] office=healthcare deprecated or bad documentation ?

[Marc_marc]

Hello,

in 2020, the wiki was changed [|] for this tag (I don't remeber
that we talk about it, no link in the comment of the change)

it is obviously wrong to use it for amenity=doctors or other
examples of reported errors.

however the correct usage (an office dealing with health
but not a health insurance company) is given as being able
to be "imrpoved/fixed" with office=compagny
is this really good advice ? company is a very generic value
that says nothing more than office=yes, without specifying
the activity that takes place there

[1] 
https://wiki.openstreetmap.org/w/index.php?title=Tag:office%3Dhealthcare=prev=2062630

[2] https://www.openstreetmap.org/node/7827856057

Regards,
Marc



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

Re: [Tagging] Help with new tags about wheelchair accessibility for On Wheels app

[Marc_marc]

Hello,

Le 02.05.23 à 17:34, ro...@onwheelsapp.com a écrit :

We want to add these tags:


I find the list too big to digest in one go, so I'll note a few tags 
that seem clearly ok

and some tags that clearly don't seem ok
the others, between the 2, deserve in my opinion to be treated
out of this mass to avoid to avoid having too long discussions
on too many tags in a single subject, which may make it indigestible


  * entrance:ramp:wheelchair      (for a ramp at the
entrance)


I find this tag too specific: the ramp can often be used by old people, 
parents with a baby carriage, a person with difficulty walking or even 
by a person with no difficulty
there is the entrance:ramp tag which combined with wheelchair describes 
in my opinion the accessibility well without having to describe the same 
object with at least 4 different tags



  * parking:sensor_ID          (for the
ID of a IOT Communithings sensor in a parking place)


if it's the ref of something, use ref:*, maybe ref:parking:sensor_ID
or ref:sensor_ID on the amenity=parking
it would be very useful to make a documentation page on what it is,
how to get it, how a contributor who is not a wheelchair user can
detect it, so that there can be other users than those of your app


  * entrance:kerb:height    (for the
height of the kerb at the entrance)


ok (in meter or add unit for ex 5 cm)


  * entrance:door:width         (for the
door width of the entrance)


why not entrance:width ? (entrance without door exist,
for ex when the door itself is not at the building outer
but after an covered area
sometimes it's not a door but a bay, overspecific tag
seems uninteresting to me for the datause


  * entrance:step_count         (for the
number of steps at the entrance)


ok (i'm using it myself :) with entrance:step:height


  * entrance:turn_point          (for free
space to turn at both sides of the entrance)


if the space is not enought, isn't it better to put entrance:wheelchair=no?


  * atm:wheelchair          (for
wheelchair accessible yes or no)


ok but I prefer to create an object amenity=atm + wheelchair=*


  * reception_desk:wheelchair     (for wheelchair
accessible yes or no)


ok


  * toilets:wheelchair


no need to ask, it's an in use tag :)


  * toilets:wheelchair:accessible_by   (to indicate if a
wheelchair toilet is accessible by stairs, lift or groundfloor)


groundfloor -> level=0
I don't really understand the need to describe the pathway and above
all I fear that it will end up adding accessible_by everywhere (how 
accessible is the parking ? how accessible is the shop ? ) which on 
their own don't mean anything (toilets on the ground floor can be 
wheelchair=no, accessible_by=stairs can be wheelchair=yes if the 
staircase has a motorized wheelchair platform.



  * toilets:accessible_by    (to
indicate if a normal toilet is accessible by stairs, lift or
groundfloor)


same as before


  * toilets:wheelchair:space_side    (for the free space
on the side of the toilet)
  * toilets:wheelchair:space_front  (for the free space
in front of the toilet)


toilets:wheelchair is not sufficient ?
when does a user need to know all these details?
I would have thought that what interests him is to know if in
the end it is accessible or not or is the goal to make a detailed 
inventory of ok and not ok points?



  * toilets:wheelchair:handrails   (for the number
of handrails)


are you talking about a handrail like on the stairs
or a bar located in the toilet allowing you to lean on
to lift yourself between the chair and the toilet bowl?
I fear a confusion of terms when the toilet has a staircase
to get there. another term seems more appropriate to me


  * toilets:wheelchair:door_width   (for the door width
of the toilet)


toilets:wheelchair:door:width but as before, i don't
see the usecase

  * toilets:wheelchair:narrowest_point_from_entrance  
(to indicate the narrowest point from the entrance

to the toilet)


osm is a geospatial database, adding tags describing
the positioning between objects doesn't seem like a good
idea to me (in the past, some have added tags to describe
the nearest bus stop to a park, the nearest address to
a bike station,
it's potentially endless and without real added value,
even if it's indoor, nothing prevents you from doing a highway=path 
indoor=yes connecting the object to its door, while waiting

for an indoor mappinng


  * elevator:width   (for
the width of the elevator)
  * elevator:depth   (for
the depth of 

Re: [Tagging] Feature Proposal - Approved - EV Charging Station Mapping

[Marc_marc]

Le 02.05.23 à 22:58, NKA mapper a écrit :
tir. 2. mai 2023 kl. 20:01 skrev Justin Tracey >:



There's no algorithmic way to tell


this is not correct.


can you share our algorithmic ?

I don't see how an algo will detect that 2 objects 
amenity=charging_station represent 2 sites on the same parking

(and are therefore valid in the new schema) and not 2 charging
stations on the same site (which would have to be changed to 
man_made=charging_station).


I don't see either how an algo will detect that an object 
amenity=charging_station isolated represents a site of

several charging stations (and is thus valid in the new schema)
and not an isolated charging station (which it would thus
be necessary to modify by adding man_made=charging_station)




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

Re: [Tagging] Feature Proposal - Approved - EV Charging Station Mapping

[Marc_marc]

Le 02.05.23 à 16:14, Illia Marchenko a écrit :

What is the impossibility of migration?


you can't select all object with the previous schéma
if you select amenity=charging_station,
you have both objet with the previosu schéma (for ex
an object representing a charging station site)
and the objects in the new scheme (the object
representing a site composed of several terminals)
if you don't know how to select only the objects of the old schema,
then you can't easily go through them one by one and you are limited
to having to select them a bit by chance, without avoiding that each 
contributor checks again and again each time the objects having the

tag amenity=charging_station common to the old and the new schema



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

Re: [Tagging] Feature Proposal - Approved - EV Charging Station Mapping

[Marc_marc]

Le 02.05.23 à 14:21, NKA mapper a écrit :
The EV Charging Station Mapping 
 proposal is now approved



I really wonder how we can approve a proposal that makes it impossible 
to migrate from the old scheme to the new one when we see that even 
those that allow it (power=sub_station) take over 10 years to migrate.

I wonder if a vote should not be planned in two stages:
- the idea: everyone was aware of the problem
- the implementation... that we should not vote as long as there is a 
concrete problem (and here there were 2: redefinition of existing tag 
and impossibility to select the objects of the old schema since the new 
schema uses a tag identical to the previous one).


bad day...



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

Re: [Tagging] roof:shape=pitched imprecise value ?

[Marc_marc]

Le 24.04.23 à 18:35, Martin Koppenhoefer a écrit :



sent from a phone


On 24 Apr 2023, at 16:03, Timothy Noname  wrote:

Probably a tagging error by someone who doesn't know the correct tags like 
skillion and gabled.


Unless we know there is a more established tag for it, we better not touch it.


skillion and gabled are established tag, so what did you mean ?



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

Re: [Tagging] shop=screenprinting

[Marc_marc]

Le 21.04.23 à 16:01, Mateusz Konieczny via Tagging a écrit :




Apr 21, 2023, 14:31 by marc_m...@mailo.com:

Le 21.04.23 à 14:08, Mateusz Konieczny via Tagging a écrit :




Apr 21, 2023, 01:33 by marc_m...@mailo.com:

On 20/04/2023 19:50, Mateusz Konieczny via talk wrote:

undocumented shop values


I'm using shop=screenprinting
https://taginfo.openstreetmap.org/tags/shop=screenprinting#overview
https://en.wikipedia.org/wiki/Screen_printing

a better value or a good value that need documentation ? :)

is it selling supplies for screen printing or offering it as a
service? Or both?


it sells the screenprinting-on-demand service as well as many
pre-screenprinted objects (e.g. t-shirts or coffee cups with slogans)

it doesn't sell supplies for screenprinting
craft is done elsewhere, not at the shop location

so is it about printing something on objects?

or is it also about regular printing on paper?


yes on objects
not "copy a paper on paper" nor print a pdf on paper,
it's not a shop=copyshop
https://en.wikipedia.org/wiki/Screen_printing



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

Re: [Tagging] shop=screenprinting

[Marc_marc]

Le 21.04.23 à 14:08, Mateusz Konieczny via Tagging a écrit :




Apr 21, 2023, 01:33 by marc_m...@mailo.com:

On 20/04/2023 19:50, Mateusz Konieczny via talk wrote:

undocumented shop values


I'm using shop=screenprinting
https://taginfo.openstreetmap.org/tags/shop=screenprinting#overview
https://en.wikipedia.org/wiki/Screen_printing

a better value or a good value that need documentation ? :)

is it selling supplies for screen printing or offering it as a service? 
Or both?


it sells the screenprinting-on-demand service as well as many
pre-screenprinted objects (e.g. t-shirts or coffee cups with slogans)

it doesn't sell supplies for screenprinting
craft is done elsewhere, not at the shop location



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

[Tagging] shop=screenprinting

[Marc_marc]

On 20/04/2023 19:50, Mateusz Konieczny via talk wrote:

> undocumented shop values

I'm using shop=screenprinting
https://taginfo.openstreetmap.org/tags/shop=screenprinting#overview
https://en.wikipedia.org/wiki/Screen_printing

a betterr value or a good value that need documentation ? :)



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

Re: [Tagging] openGeoDB* discardable ?

[Marc_marc]

Le 17.04.23 à 15:43, Mateusz Konieczny via Tagging a écrit :

Given how many of them are (<20 000) I think that bot edit
removing them would be a good idea.


this was also my first idea, but as a Swiss contributor is opposed
to it, the edition in question will not be done in Switzerland.
of course nothing prevents us from offering this edition in Germany and 
Austria, that would be one less noise.


Le 17.04.23 à 17:18, Kai Michael Poppe a écrit :
I'd recommend removing all but :loc_id, so that the ID corresponding to 
the _still_ available recordset on GitLab doesn't get lost.


2 issues:
1) if we had to do it again, we would use ref:* or wikidata to avoid
listing the id of all database in osm without added value for osm.
2) they have created in osm "municipality" objects (duplicating the 
relations) which have meanwhile become in osm cities/villages with

the same name.
so their id does not correspond anymore to the osm object.
But if this allows a certain consensus that the tags do not deserve
to be kept, it is already a step forward



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

[Tagging] roof:shape=pitched imprecise value ?

[Marc_marc]

Hello,

is roof:shape=pitched an imprecise value ?
I'm not a english naative but for me it could be :
mono-pitech roof roof:shape=skillion
duble-piteched roof roof:shape=gabled

Or I miss something due to the translation ?

Regards,
Marc



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

Re: [Tagging] Is tagging of fuel: assumed to be exhaustive?

[Marc_marc]

Le 20.04.23 à 03:28, Matija Nalis a écrit :

On Thu, 20 Apr 2023 00:47:21 +0200, Marc_marc  wrote:

Le 19.04.23 à 14:19, Matija Nalis a écrit :

I think that my point remains that:
- one method is clear and unambiguous ("fuel:lpg=no")
- one method is not clear / is ambiguous ("fuel=octane_98;diesel").

So the first one should be preferred. Does that make sense?


- one is a nightmare for datause
- one isn't a nightmare for datause
So the 2nd one should be preferred. Does that make sense?


Hmm, no, not at all (if ordering of your sentences is same as mine at the top 
quote)?

I'll assume that by "datause" you mean something like computer storing
data in some kind of database for purpose of retrieving


yes


- in "fuel:lpg=no" case it is VERY efficient and fast (using const lookup
   on composite index [key,value]) to look for e.g.

   SELECT * from t where key = "fuel:lpg" and value = "yes";


only if you are able to make an index on it
make a index on fuel=* is easy.
but creating an index on an unknown number of fuel:* keys is problematic
besides, this information will end up in the hstore for the same reason

for the preset, it's the same problem:
listing all cuisine=* values is possible (iD does it very well)
propose a preset that dynamically displays a yes/no field for all 
fuel:*, I've never seen this before, you're limited to hardcoding some


it is a confusion between key and value.



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

Re: [Tagging] unicode in direction_* for guildepost to describe what it is related to, e.g. hiking

[Marc_marc]

Le 20.04.23 à 01:04, Graeme Fitzpatrick a écrit :

Is that actually on the sign?


yes it contains also symbols of bicycle hiking and inline_skates



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

[Tagging] unicode in direction_* for guildepost to describe what it is related to, e.g. hiking

[Marc_marc]

Hello,

a specialist appearance contributor adds in unicode characters
to visually represent the type of travel present on a guildepost

is this really a good idea ? [1]

if i want to find all the signs of line 3 inline_skates
not only do I need to test 9 keys + a few more on ways,
but I will have to test value for "inline_skates" + all
the unicode characters that could represent an inline skates

how could this be improved?
replace the unicode characters with the value they represent ?
I haven't found any frequent use of :hiking or other suffixes

[1] https://www.openstreetmap.org/node/1024767

Regards,
Marc



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

Re: [Tagging] Is tagging of fuel: assumed to be exhaustive?

[Marc_marc]

Le 19.04.23 à 14:19, Matija Nalis a écrit :

I think that my point remains that:
- one method is clear and unambiguous ("fuel:lpg=no")
- one method is not clear / is ambiguous ("fuel=octane_98;diesel").

So the first one should be preferred. Does that make sense?


- one is a nightmare for datause
- one isn't a nightmare for datause
So the 2nd one should be preferred. Does that make sense?



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

Re: [Tagging] Is tagging of fuel: assumed to be exhaustive?

[Marc_marc]

Le 19.04.23 à 11:57, Philip Barnes a écrit :


if its octane 95 it will be E10



maybe
fuel:octane_95:E10 = yes
fuel:octane_99:E5  = yes


the ":" between octane and E gives the impression
that several combinations are possible.
If you say that this is not the case, then it seems more logical
to me to have one value for each combination
fuel:octane_95_E10 = yes
fuel:octane_99_E5  = yes



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

Re: [Tagging] Proposed automated edit of some barrier=kerb kerb=raised nodes (forum crosspost)

[Marc_marc]

Le 19.04.23 à 03:04, Matija Nalis a écrit :

following the automated edit code of conduct?


following it mean to use the correct place for that : the talk ml :)



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

Re: [Tagging] Is tagging of fuel: assumed to be exhaustive?

[Marc_marc]

Le 19.04.23 à 00:09, Matija Nalis a écrit :

With multi-tag standard it is unambiguous


only because we haven't invented the equivalent of =no
it would have been enough to do tag=diesel;-lpg



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

Re: [Tagging] Is tagging of fuel: assumed to be exhaustive?

[Marc_marc]

Le 18.04.23 à 18:26, Mateusz Konieczny via Tagging a écrit :


yes *:others=no but also *:*=only exist for that purpose

=only works only when you have station offering single fuel, right?


I have see (and maybe also use it mayself), a objet with 2 =only,
to describe that it's only what's listed,
that care has been taken to make the list complete



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

Re: [Tagging] Is tagging of fuel: assumed to be exhaustive?

[Marc_marc]

Le 18.04.23 à 16:53, Mateusz Konieczny via Tagging a écrit :

Is tagging of fuel: assumed to be exhaustive?


no, some contributors will fill in what they are interested in,
others will fill in everything that is visible (and may not
be able to see the blue additive pump not visible from the car pumps), 
others will do an exaustive survey



For example amenity=fuel + fuel:octane_80=yes

Is it implying that it is sole type of fuel available?


no


Is it possible to mark that fuel station
has solely fuel:octane_98 and fuel:octane_80 ?
It seems that fuel:others=no is used a bit for that purpose


yes *:others=no but also *:*=only exist for that purpose



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

[Tagging] openGeoDB* discardable ?

[Marc_marc]

Hello,

the openGeoDB* tags were added during an import in 2008 [1] in europe
and according to the wiki [2], the osm data maj project is long dead
and was problematic.
years later we still have plenty of occurrences of tag cases
if we had to do it again, current good practice would refuse to flood 
osm with internal tags to an external database (except sometimes an id 
such as wikidata)

I thus propose to change the status of these tags in discardable
so that those are not preserved during the edition of an object
some county, for ex Belgium, have already decided to remove them [3]

notice ?

Regards,
Marc

[1] https://taginfo.openstreetmap.org/keys/openGeoDB%3Aloc_id#chronology
[2] https://wiki.openstreetmap.org/wiki/OpenGeoDB
[3] https://www.openstreetmap.org/changeset/81642925




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

Re: [Tagging] Status of clothes=motorcycle

[Marc_marc]

Le 06.04.23 à 10:46, Illia Marchenko a écrit :
One of the wiki editors (Rtfm) insists that the clothes=motorcycle tag 
has been deprecated in favor of motorcycle:clothes=yes. For me it's not.
https://wiki.openstreetmap.org/wiki/Special:MobileDiff/2499835 


What do you think?


it's not, rtfm has a long history of falsifying reality and votes




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

Re: [Tagging] sport=inline_hockey a good value ?

[Marc_marc]

Le 03.04.23 à 13:14, Warin a écrit :
Would not both roller and inline skate hockey sports 
be played on the same court?


probably, I'll look into it


If so then sport=skate_hockey with skate=inline;roller ?

no, both are roller
so maybe sport=roller_hockey + roller_hockey=quad or inline



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

[Tagging] sport=inline_hockey a good value ?

[Marc_marc]

Hello,

https://en.wikipedia.org/wiki/Roller_in-line_hockey
one variety of hocket is to use inline roller "inline"
instead of quad roller as 
https://wiki.openstreetmap.org/wiki/Tag%3Asport%3Droller_hockey


in taginfo I found the undocumented value sport=inline_hockey
https://taginfo.openstreetmap.org/tags/sport=inline_hockey
does this term correspond to British English term ?
if so I will make a summary documentation page about it

Regards,
Marc



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

Re: [Tagging] [RFC] Feature Proposal - EV Charging Station Mapping

[Marc_marc]

Le 30.03.23 à 12:43, Lionel Giard a écrit :
we use the same idea for amenity=fuel where it just shows  
the place where there is one or more fuel pump. 


in no case did amentiy=fuel designate a pump and then be changed
to designate all the pumps in the same location.

it you really want to have an amenity to keep
the same idea as for fossil amenity,
why not amenity=charing_place
but keep the current in-use meaning amenity=charging_station inchanged

And it also seems logical to use "man_made" category to tag  
the individual charge points as we do for fuel pumps.


that doesn't answer my objection: don't change the meaning
of an existing tag :
For years we will end up with a tag with two meanings: the old and
the new and it will be impossible to review the old tag since part
of the new meaning (amenity=charging_station = a site of 
man_made=charging_station) uses the same tag as the current meaning 
(amenity=charging_station = a charging station, that may be part of

a bigger site)
not being able to migrate from the old to the new schema is the worst 
thing you can do to destroy data quality




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

Re: [Tagging] [RFC] Feature Proposal - EV Charging Station Mapping

[Marc_marc]

Hello,

Le 30.03.23 à 10:25, NKA mapper a écrit :

The definition of amenity=charging_station will change slightly and will represent 
both locations with a single charge point and locations with a group of chargers. 
A new optional feature, man_made=charge_point will be created to separate detailed 
mapping of each charge point from the main amenity amenity>=charging_station 
feature at locations.


I disapprove the idea of changing the meaning of "in use" tag.
we already have what you want :
- a charging station : amennity=charging_station
- a site of charging station relation type=site

Regards,
Marc



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

[Tagging] incubator for the birth of chicks

[Marc_marc]

Hello,

how to tag the industrial premises used as an incubator for the birth
of chicks?
amenity=animal_breeding animal_breeding=chick ?

the growing of chicks into chickens is done elsewhere

Regards,
Marc



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

Re: [Tagging] Slate roof tiles

[Marc_marc]

Le 13.03.23 à 21:52, Evan Carroll a écrit :

Slate is always black


maybe never :)
it's often from dark grey to blue grey,
sometime pale grey and some other minor colors



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

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

[Marc_marc]

Le 24.02.23 à 11:47, Martin Koppenhoefer a écrit :
If it fails, will it change the tag status from "de-facto" to what? 


it'll not change the status of the tag :)


voting is about a proposal, not about "tags"


the proposals endorse tags, this is playing with words.
It has the merit of saying that several people have collectively
thought about the choice of tag and that it seemed coherent to them,
at at the end we document this with an approved status on the tag page.
it is on average of better quality than a tag that became defacto 
because the automatic autocompletion of an editor encouraged the use

of the first occurrence of the tag without anyone having a critical look.

so for me if the person makes an RFC to have an opinion on the proposal, 
I have nothing against his request, on the contrary, take care about 
quality is always positive




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

Re: [Tagging] tactile_paving=* on highway=steps ?

[Marc_marc]

Hello,

Le 23.02.23 à 12:46, Matija Nalis a écrit :

seems somewhat incorrect (as the tactile
paving does not follow that way


it's always the difference between being tactile_paving
or being a staircase with a tactile_paving
for example ramp=yes does not say that there is a ramp at
the exact place of the osm object but simply that the main object
has a ramp, this one not necessarily being in the centre of
the staircase
the same with a bus stop (bin bench tactile_paving aren't
at the exact location of the bus stop node, it is
an abstraction which says that the bus stop has these characteristics

on a practical level, I would ask a blind person using osm,
but I doubt that making one node per step for stairs with a tactile 
paving per step, brings a real advantage, the piling up of nodes

being closer than the precision of a classic gps

Regards,
Marc



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

Re: [Tagging] Combining "locked=yes" with various access tags

[Marc_marc]

Feb 21, 2023, 15:24 by zeev.stad...@gmail.com:


 1. As far as non-emergency routing, the "locked" tag should be ignored.


it is up to the person doing the routing to decide (and if I were him,
I would impose a penalty: getting out of the vehicle and opening
the barrier takes more time than going through a route of the
same distance without a barrier


 2. A "locked=no" tag indicates that a legal access restriction is
not enforced by a lock and therefore could be overcome in case
of an emergency.


i agree


 3. A "locked=yes" tag indicates that the legal access restriction
is enforced by a lock and therefore cannot be overcome in case
of an emergency.


legal or not, it's enforced

Le 21.02.23 à 15:34, Mateusz Konieczny via Tagging a écrit :

That is better mapped by mapping path around barrier,  
at least in my opinion.


maybe for a barrier=gate

but a barrier=lift_gate/swing_gate hat is less wide than the whole road
is not really a barrier + a path that goes around the barrier.
ditto if for a dual retractable barrier=bollard  blocking vehicles
but pedestrians and cyclists pass in the middle
ditto for a lcoked barrier=gate with a unlocked barrier=wicket_gate
part of it to still allow pedestrian access

Regards,
Marc



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

Re: [Tagging] [RFC] Feature Proposal - Replace `*:signed` suffix key with `signed:*` prefix key

[Marc_marc]

Le 17.02.23 à 01:38, Matija Nalis a écrit :

Cross-posting from the forum:


thanks... we see the community split :
no reply from the other to the previous message
due to the fragmentation of several unconnected
interface



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

Re: [Tagging] key covered=* applied to storage tanks

[Marc_marc]

Le 02.02.23 à 17:44, Martin Koppenhoefer a écrit :



sent from a phone


On 2 Feb 2023, at 16:04, Marc_marc  wrote:

I thought there were only open-top tanks



there are but they are called basin or reservoir


did you mean that man_made=storage_tank open=top (or whatever the exact 
tag) is a tagging mistake and should be tagged as man_made=reservoir ?
if so, the 1st issue is a style one : this hidde the object on the major 
style and that prevend some ppl to use it (it should not, but it is)

or man_made=basin and/or natural=water + water=basin ?

(and man_made=reservoir_covered -> man_made=storage_tank ?)


we also have landuse=reservoir

it's a tag for the bin :
it's a landuse, so it should be the whole area dedicated to this 
function (the reservoir, the grassy area that sometimes surrounds it, 
the possible technical building, etc. until the fence that sometimes 
surrounds it)
on the main style everything is rendered in blue confusing a reservoir 
with the water body it contains (the reservoir closest to me today has a 
larger surface than the water body, as the reservoir at least includes 
the structure (concrete or earth) that holds the water)




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

Re: [Tagging] [Talk-us] New MapRoulette Challenge - Add Surface to Highways

[Marc_marc]

Le 03.02.23 à 15:32, Brian M. Sperlongano a écrit :

Let's make sure we're talking about the same thing


what's the issue with tag if TomTom doesn't reply ?
I suppose it's more for talk than tagging



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

Re: [Tagging] key covered=* applied to storage tanks

[Marc_marc]

Le 02.02.23 à 15:09, António Madeira a écrit :
My problem with storage_tank=open is that it still has ambiguity. Open 
where? On the top, on the side? Which side? This is very important in 
the case of storage tanks destined to firefighters.


I thought there were only open-top tanks, but if not
storage_tank=open + open=top (or another better key to come)
should give the information

for access via tap : tap=yes/north/south/ or tag the tap
with a dedicated object



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

Re: [Tagging] [RFC] Feature Proposal - Replace `*:signed` suffix key with `signed:*` prefix key

[Marc_marc]

Hello,


Le 01.02.23 à 16:47, Zeke Farwell a écrit :





this is the caricature of the confusion between key and value :
if a key has only one value then it is the value of another more 
relevant key
in this case the key *:signed=* has only one useful value, that of 
*:signed=no (e.g. name:signed=no) to allow collection tools not

to ask for name=* if there is nothing on the ground
unsigned=name also does this, in a much more consistent way
and if you have A:signed=no A:signed=no, you can obviously
just set unsigned=A;B

Regards,
Marc



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

Re: [Tagging] leisure=practice_pitch a bad idea because too overspecific for a main tag ?

[Marc_marc]

Le 30.01.23 à 18:34, Illia Marchenko a écrit :
unsuitable for normal game - for example, small basketball  
pitch with one basket.


It is a very good counter example:
as a child we regularly played on a pitch with one basket,
we played... we were not practising

ditto for the nearby hocket pitch: I know that it is a field
and that hocket is played there, at least for fun.
Is it a pro team that trains with a goal or is it a "normal game" pitch?
I have no idea and I don't see how this should influence the choice
of the main tag

let's move that to a subtag 
pitch=normal_game/child_size/unofficial_characteristic/... or whatever




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

[Tagging] leisure=practice_pitch a bad idea because too overspecific for a main tag ?

[Marc_marc]

Hello,

Le 30.01.23 à 16:24, Illia Marchenko a écrit :

leisure=practice_pitch is not suitable for full game.


I had not seen that this tag was documented and in the history
we already see the 2 opinions:
when you see an XYZ sports field, do you have to be an expert
in that sport with a measuring device in your pocket to know
if the field is suitable for a match or only for training ?
the news shows from time to time a sports field suddenly becoming
a "training pitch" because the legislation has changed. but if
you ask 1000 contributors who haven't heard the news, i doubt that
any contributor would choose another secondary tag than leisure=pitch
the dimension aspect should be given either by its dimennsions in osm, 
or in a secondary tag and not carried by the main tag.
the documentation of the tag before the last modification on the subject 
showed well that the current situation is to use leisure=pitch also for 
the training grounds


Regards,
Marc



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

Re: [Tagging] Deprecate sport=cricket_nets

[Marc_marc]

Le 30.01.23 à 14:54, Illia Marchenko a écrit :

recommend leisure=practice_pitch


what's the diff with a leisure=pitch ?



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

Re: [Tagging] craft vs office for service enterprises/establishments.

[Marc_marc]

Le 25.01.23 à 17:48, Daniel Bégin a écrit :
office=* refers to places mainly providing services  
and frequently selling them.


I would have rather described the key as being the place of cerebral or 
administrative tasks, as opposed to craf which is the place of manual 
tasks: technically it is not impossible that a craftsman has an office 
in one place and a workshop in another (and even a shop in a third place)



I would also use office=* for electricians because they provide services


it depends on the meaning of electrician:
if it is the person who comes to your house to change a plug or make
an electrical installation in a building, it is clearly a manual work 
and not a service.

if it is the person working for a company producing electricity,
it is industrial with offices (but where there is no electrician)




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

Re: [Tagging] Best practices for creating a categorical key=value

[Marc_marc]

Le 18.01.23 à 16:53, Casper Kersten a écrit :

office=company + company=construction


what's the added value versus office=construction ?
for me office=company is only usefull is you don't
known that kind of company quite close to office=yes.
if you known the company=*, it's a tautology



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

Re: [Tagging] Best practices for creating a categorical key=value

[Marc_marc]

Le 18.01.23 à 16:22, Daniel Bégin a écrit :
the mapping of a company that produces and installs precast concrete 
could be tagged as…


office=construction_company

construction_company=precast_concrete

but I have my doubts on the best way to do it. Any suggestion?



tag linking (A=B B=C) is very common and a good pratice
but is precast_concrete a correct 2nd level value ?
does the company manufacture concrete? or concrete elements?
in the 2nd case I would rather choose the type of use (building,
small street cabinet, ...)



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

Re: [Tagging] key covered=* applied to storage tanks

[Marc_marc]

Le 12.01.23 à 17:02, António Madeira a écrit :
If, for example, we state that it has a roof=no, you're defining a 
specific kind of covering, when it has none and you have no way to know 
if that would be a roof, a tarp, a shed, etc.


roof=* is indeed maybe too specific.
but closed or not tank and tank covered by another object
are 2 different things and therefore require 2 keys :
a tank can be closed or open and be under another object or not,
let's not distort the covered key by saying that unlike objects,
when used on tank, it does not describe anymore the presence
of another object that covers the first.



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

Re: [Tagging] key covered=* applied to storage tanks

[Marc_marc]

Hello,

Le 09.01.23 à 17:49, António Madeira a écrit :
include emergency storage tanks so that people know it's ok to add 
covered=* to those structures.


imho it's alread include by "covered reservoir"
but that's also a little wrong.
the reservoir isn't convered (under something that coverd it like
under a bridge or a roof.
the reservoir is closed, and the closed reservoir itselft isn't 
covered=*, that'sn't the same.


also "an area such as an underground parking lot" is a bad
usage of covered=*, it's more a indoor=* level=-1

Regards,
Marc



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

Re: [Tagging] Feature Proposal - Voting - Announce proposals on the community forum

[Marc_marc]

Le 07.01.23 à 21:15, Brian M. Sperlongano a écrit :
I checked out the site stats[1] and learned that over the last 30 days, 
the French forum has averaged 36 messages per day with 257 active users.


Then I headed over to talk-fr to investigate how much activity was 
happening there.  In the whole month of December there were just 65 
posts, and I counted 21 unique users.


So it sounds like there is very little fragmentation


you don't see of course that when user A post on the forum,
the user B on the mailing doesn't respond
and when the user B post on the mailing, the user A on the forum
doesn't respond
the overwall volume (forum+mailing) is lover that when everybody was 
only on one media

and the sub-projects also took a beating:
- don't look for the newcomers team, there is no real team anymore, some 
on the forum, some on the mailing list, no coordination or collective 
motivation
- don't look for the systematic follow-up of the schoolchildren (in 
France, osm is taught at school), it's the same problem

etc etc

and all this because the pro-forum people confused haste with speed... 
by giving time to time Discourse could have been a federation, a place 
accessible/usable with the 2 interfaces instead of being an additional 
and therefore fragmenting place




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

Re: [Tagging] Feature Proposal - Voting - Announce proposals on the community forum

[Marc_marc]

Le 07.01.23 à 18:39, Cartographer10 via Tagging a écrit :
For proposal authors, it means that they don't specifically  
have to interact with the ML. 


that is what I call a fragmentation, that's what happend
with the fragmentaiton of the fr community


There are people who feel discouraged to make a proposal because of the ML 
requirements


you say it again but i have never seen a proposal write that is blocked 
because the person did not post to the mailing list. if that was the 
case, you propose to post to the mailing list. so this problem does not 
exist. it would be really beneficial not to contradict you.
the only consequence of an acceptance of this proposal will be that some 
proposals will be discussed *only* on the forum (because as you say some 
don't want to discuss on the list AND because there is an impatience to 
discuss the proposals there even if the forum is currently failing for a 
correct use by email).




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

Re: [Tagging] Feature Proposal - Voting - Announce proposals on the community forum

[Marc_marc]

Le 07.01.23 à 17:17, Cartographer10 via Tagging a écrit :

Announce proposals on the community forum
https://wiki.openstreetmap.org/wiki/Proposed_features/Announce_proposals_on_the_community_forum 


t is revealing to see that you left a remnant of "switch to the forum", 
which seems since the real purpose of this proposal

still a no : this proposal is "against" the mailing list.
if the goal was to receive only the messages of the proposal 
announcements, then the solution would have been either to write how to 
make an email filter, or to make a tagging-announcement list, not to 
want to end that everyone must open a web browser to read a message


but i don't doubt that by forcing it without giving up,
it will eventually pass this time or in its version 42



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

Re: [Tagging] "Mörthe und Mosel"

[Marc_marc]

Le 04.01.23 à 11:31, Hartmut Holzgraefe a écrit :

On 1/4/23 11:08, Ulrich Lamm wrote:
Meurthe-et-Moselle ist ein Département der Republik Frankreich und 
sein Gebiet seit vielen Jahrhunderten frankophon.
Der Fluss Meurthe fließt in ganzer Länge durch französisches 
Sprachgebiet.
Die Eindeutschung zu "Mörthe und Mosel“ ist politisch inkorrekt und 
abscheulicher deutscher Nationalismus.



This is the wrong list for such kind of discussion, 
talk...@openstreetmap.org would have

been a better choice.


or nothing due the fact that the only "Mörthe und Mosel“
is on https://www.openstreetmap.org/relation/51856
with a name=* in french :)



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

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Marc_marc]

Le 22.12.22 à 18:10, Raphael a écrit :

I think we should rather decide where the tagging discussion should
take place and then announce proposals at that place.


the power of discourse, when it 'll be in a "full working state" is that 
is that it allows a unified communication between the users of the mail 
interface (knowing that it is itself connected to others) and those of 
the web interface.

This confrontation is therefore totally counter-productive.



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

Re: [Tagging] uphill vs. incline=up - direction of travel

[Marc_marc]

Hello,

Le 18.12.22 à 20:19, Patrick Strasser-Mikhail a écrit :
It was pointed out[3] that 'incline' is a tag and intended to indicate a 
*direction* and amount of inclination of *the road in relation to the 
mapping direction*, not the direction of the *vehicle driving* on the road.


that's not my reading/usage :
yes incline=* is about the direction of the way.
but it also not about the amount of inclination of the road,
it's about the maximum inclination of this segment :
you can have a route that goes up and then down to return to exactly
the same altitude. Depending on whether the maximum incline is up
or down, it will be incline=up or down and not incline=0/no.

Having never seen a road that requires chains to be put when
there is no ice nor snow, I wonder if the use of "@ (ice; snow)"
even makes sense, i find it useless.

To solve your problem, I think it is better to cut the highway=*
into sections that go only up or down not both.
(despite I find this sign absurd: a ice is just as slippery downhill
as it is uphill and I have never yet seen someone put their chains
at the top).

You can then simplify with
snow_chains=required
snow_chains:4wd:forward=no

PS: it seems that osm is using 4WD, not AWD,
see the badly named 4wd_only=*

Regards,
Marc



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

Re: [Tagging] Foot / sidewalk access tagging

[Marc_marc]

Le 18.12.22 à 21:29, Brian M. Sperlongano a écrit :

I would like to understand how folks in various places would interpret this:

highway=
foot=no
sidewalk=separate


I interpret it exactly as you describe it in the text:
there is a carrierway not allowed to pedestrians
there is another object to describe the sidewalk
if you don't want to load highway=footway/path,
then use this highway=* but the accuracy will be
a little less good since the geometry will be that
of the centre of the carrierway and not that of
the centre of the sidewalk

regarding the alternative :
highway=
foot=no
sidewalk=use_sidepath
it doesn't have the same meaning, it said that a sidewalk
exist but it doesn't said that the sidewalk have another object.
as a datauser agaim, if you don't want to load highway=footway/path,
then use this highway=*

but the real question is why would you not want to load objects
specific [1] to your use case, I find that strange

[1] highway=path path=sidewalk or highway=footway footway=sidewalk
and mayb highway=cycleway cycleway=sidewalk

Regards,
Marc



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

Re: [Tagging] Feature Proposal - RFC - Gender

[Marc_marc]

Le 17.12.22 à 21:58, Illia Marchenko a écrit :
Gender proposal is ready for voting. After the previous vote, this 
proposal has been reworked. I plan to start voting in a few days.

https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Gender 



Isn't it good practice to have an RFC after the last change
(i.e. today) ?
Always pushing to go faster only leads to no votes and starting over-

in skimming the proposal, i didn't understand how redefining the meaning 
of 3 tags will remove the ambiguity of one of the (unisex=yes)
Don't expect all contributors to read the counter-intuitive explanations 
you offer.

a =segrated =not-segrated value would be much more intuitive



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

Re: [Tagging] Homogenize diplomatic tags

[Marc_marc]

Le 17.12.22 à 12:03, Georges Dutreix via Tagging a écrit :
23990 - add office=diplomatic + diplomatic=embassy when 
[embassy][office!=diplomatic]
23992 - add diplomatic=embassy + embassy=* if 
[office=diplomatic][!diplomatic][~"^name"~"embass",i]
24031 - change to diplomatic=consulate if 
[diplomatic=embassy][~"^name"~"consul"]

24098 - change to office=diplomatic if [diplomatic][office!=diplomatic]
24182 - set consulate=honorary_consul if 
[diplomatic=consulate][consulate!=honorary_consul][~"^name"~"honor",i];
24295 - Replace diplomatic=high_commission with diplomatic=embassy + 
embassy=high_commission
24296 - Replace diplomatic=permanent_mission with diplomatic=embassy + 
embassy=mission"
24297 - Replace diplomatic=delegation with diplomatic=embassy + 
embassy=delegation
24298 - Replace the diplomatic=ambassadors_residence tag with 
diplomatic=embassy + embassy=residence
26851 - improve names of diplomatic offices which have, in their 
name(s), at least one group of capital letters or have a first letter in 
a lower case

26976 - move country=* in capital letters
26992 - move target=* in capital letters

The challenges causing this discussion (change tag x to tag y) seem to 
be the following ones :

24295 - 58 objects modified
24296 - I didn't find the number but there are today 148 embassy=mission 
nodes in the world

24297 - 32 objects modified
24298 - 119 objects modified


it is not only these 4 but the 12 I quoted above that are fully automatable
and therefore a mechanical edition

These modifications may be compared by exemple with the challenge 24032 
having modified 2537 objects.


witch is a mecanical edit too


The whole project doesn't look to me as a mechanical edit


mechanical editing is a criterion-based object loading and
a operation (add tag, change tag, ...) applied according to a 
"mechanical" logic.
maproulette 23990 select [embassy][office!=diplomatic] and on those 
object add office=diplomatic + diplomatic=embassy



You suggest to modify something in the wiki


you may check that all new tag have a wiki entry, at leasst by copying 
the old tag entry into the new one


Regards,
Marc



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

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

[Marc_marc]

Le 16.12.22 à 08:30, Mateusz Konieczny via Tagging a écrit :




16 gru 2022, 02:51 od graemefi...@gmail.com:


On Fri, 16 Dec 2022 at 10:59, Andy Townsend mailto:ajt1...@gmail.com>> wrote:

doesn't explain why "amenity=lifeboat" is "deprecated".  Like it
or not, this is used exactly how you'd expect:

https://map.atownsend.org.uk/maps/map/map.html#20/54.48811/-0.61310 



But as I've pointed out a couple of times before, by policy, OSM
doesn't map mobile items

e.g https://wiki.openstreetmap.org/wiki/Tag:building=houseboat


" Houseboats that are moving are not mappable in OSM"

Yes, that (totally undocumented & undiscussed) tag could be either
written up to specify it's the location where a lifeboat is moored,
or it could be changed to amenity=lifeboat_mooring, but, is it
verifiable? Can anybody walk up to that spot 24/7/365 & say Ah yes,
that's the /George//& Mary Webb/? Sorry, but no they can't, as it
may be elsewhere at that moment.

In this case amenity=lifeboat is - I expect - used to map lifeboat 
stationing place, not lifeboat itself


of course, like marina doesn't map boats but the mooring area




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

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

[Marc_marc]

Le 15.12.22 à 04:25, Graeme Fitzpatrick a écrit :
No further comments or discussion so moved to voting: 
https://wiki.openstreetmap.org/wiki/Proposed_features/emergency%3Dlifeboat_station#Voting 


it's a shame to have gone to the vote without resolving the 5 issues raised



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

Re: [Tagging] building=entrance

[Marc_marc]

Le 12.12.22 à 20:27, Martin Koppenhoefer a écrit :
Following a JOSM discussion I wanted to ask here, if someone else is 
using building=entrance to tag entrance buildings.


it doesn't look like to be a building but a indoor=* (root ? entrance ?) 
and sometime a building:part (for 3D tag)


i dislike the idea to have tag with several meaning depending
if it's on a node or a closed way



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

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

[Marc_marc]

Le 07.12.22 à 07:31, Warin a écrit :


On 7/12/22 01:54, Marc_marc wrote:

Le 06.12.22 à 00:47, Graeme Fitzpatrick a écrit :

https://lists.openstreetmap.org/pipermail/tagging/2022-November/066540.html

Are there any further comments that anybody would like to raise?


I have not issue with merging 3-4 tags with the same meaning but :

- what are we mapping ? reading the description, this seems to be more 
of a landuse=ermergency than mapping an emergency service i.e. where

you can go to get a service


Similar comments can be made for fire stations and ambulances - you call 
them up for them to come to you. As these are already accepted by the 
community I see no reason to exclude this case.


for the 2 fire stations I know, you can/must go there
for advice or a fireman's pre-notice about a new building.
It is very different from a technical room or an office closed
to the public.
Will we also tag office+parking with emergency=defibrillator for the 
office of the compagny dealing with maintenance or telephone support for 
defribilators? this seems inconsistent to me




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

Re: [Tagging] RFC - Proposed features/emergency=lifeboat station

[Marc_marc]

Le 06.12.22 à 00:47, Graeme Fitzpatrick a écrit :

https://lists.openstreetmap.org/pipermail/tagging/2022-November/066540.html

Are there any further comments that anybody would like to raise?


I have not issue with merging 3-4 tags with the same meaning but :

- what are we mapping ? reading the description, this seems to be more 
of a landuse=ermergency than mapping an emergency service i.e. where

you can go to get a service
I would not map a coordinating & controlling for doctors under 
emergency=* and so don't see a logic to map full "office only" place 
with a emergency=*


- proposing lifeboat_station for a helicopter rescue base seems
to me a bad idea. a more generic tag without "boat" seems better.
maybe rescue station (and it would be very logical to have the same
term as seamark)
otherwise another tag will naturally be created for those area
where the proposed tag is counter-intuitive

- should we vote on the meaning of "Deprecated" for this particular 
proposal? and thus expose ourselves to having proposals with a different 
meaning? it seems to me that it would be better to take this content out 
of the proposal, this is not what we are voting on, instead a link to a 
page describing this meaning would be ideal


- are we voting also for all "Tags used in combination" ?
the seamark mess (including duplicate and :type meaningless) would lead 
me to automatically vote no to a proposal that would try to include them 
in something else without reason


- what's a lifeboat:class ? it would be a good idea to describe it 
better or to take it out of the proposal and postpone it to a next time 
(this does not prevent to have it on the wiki page of the tag, without 
the approved status and thus likely to be improved easily)


- The various seamark categories *should* be included
sorry I disagree. it may, it not mandatory and perfectly valid/usefull
to create a object without these tags (especially those which
are only repetition of other osm tags), the next contributor has
the opportunity to add to the first contribution

- lifeboat = offshore / inshore : the description is not clear if it 
informs the place of intervention of the boats (the stations of Lake 
Geneva are inshore despite of its size) or the extent of the coverage:
a rescue station probably would be preferable to have a more generic 
tag, more thoughtful so that it can be applied to non-water rescue. 
something describing the extent (maybe scope)

if not, does emergency=marine_rescue implie lifeboat=offshore or
not always ?

- Remove incorrect tagging of amenity=lifeboat, currently being used
to show the location that lifeboats are moored at.
ok, but list the correct tag

Regards,
Marc



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