Re: [Tagging] The reason to not use loc_name is far too subjective.

[Mateusz Konieczny via Tagging]

Mar 27, 2024, 20:33 by tagging@openstreetmap.org:

> If it's not on a road sign or in a street gazetteer database then it's almost 
> certain not to have a name. 
>
maybe in some areas of world, but not everywhere

many names are not in either of that
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Where should name tags be added on administrative boundaries?

[Mateusz Konieczny via Tagging]

something weird is with your link in some views

reposting it:

https://community.openstreetmap.org/t/where-should-name-tags-be-added-on-administrative-boundaries/110895


Mar 24, 2024, 17:31 by etienne.jul...@gmail.com:

>
> I’m thinking about expanding the administrative boundaries in my area, and 
> from what I’ve found in my research, the most effective approach involves 
> creating a relation and specifying roles like ‘outer,’ ‘admin_center,’ and 
> ‘label’ as detailed on the wiki page:
>
>
>
>
>
> https://wiki.openstreetmap.org/wiki/Relation:boundary 2 
> 
>
>
>
>
>
> However, I’m a bit unsure about where to add name tags. Should I exclusively 
> add them on the label node, only on the relation, or on both the label and 
> relation?
>
>
>
>
>
> Looking at examples from around the world, it seems that name tags are often 
> found on both entities but aren’t consistently synchronized, which could lead 
> to inconsistencies.
>
>
>
>
>
> FYI I have also posted the same question on Discourse: > 
> https://community.openstreetmap.org/t/where-should-name-tags-be-added-on-administrative-boundaries/110895
>  
> 
>
>
>
>
>
>
>
>

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

Re: [Tagging] tagging "loose" paving stones

[Mateusz Konieczny via Tagging]

I also would go with surface=paving_stones - and maybe add also smoothness tag,
and agree with Fernando

Feb 21, 2024, 01:47 by fernando.treb...@gmail.com:

> I think they are surface=paving_stones because:
> - the stones are very flat on top
> - it seems that the objective was to arrange them snugly, although the fit 
> may have deteriorated a little
> - it seems pretty easy to ride a bike there, but not skate, which is what one 
> generally expects from surface=paving_stones; surface=sett is a little more 
> difficult for cycling because the stones are less flat and the surface as a 
> whole is also less flat
>
> I think surface=sett is usually more like this: > 
> https://www.mapillary.com/app/?lat=53.345215550023994=-6.265817519990492=19.230259053537715=516305962724410=photo=0.5077006613416395=0.584942612357=0
>
> On Sat, 17 Feb 2024 at 15:55, Anne-Karoline Distel via Tagging <> 
> tagging@openstreetmap.org> > wrote:
>
>>
>>
>> That's the best I can do for now: >> 
>> https://www.mapillary.com/app/?lat=52.65192667=-7.251596667=17=1685817985195902=photo=0.22772882642716127=0.968169011381621=0>>
>>   You can kind of see the gaps between the stones.
>>
>> On 17/02/2024 17:46, Åbn wrote:
>>
>>> I think you should provide a picture.
>>>
>>>
>>> On February 17, 2024 5:19:06 PM UTC,  Anne-Karoline Distel via 
>>> Tagging >>>  
>>> >>
 I'm not sure I'm understanding the differences between surface=sett 
 andsurface=paved or if what I'm trying to map is covered by either. Where 
 Ilive, there are some streets that are paved, but the stones aren't 
 setfirmly, so they wobble a bit when you drive/ cycle over them. It 
 isperfectly safe, but it allows rainwater to drain quicker, at least 
 Ithink that is the reason for this type of paving. It sounds a bit like 
 axylophone (well, lithophone, I guess), when going over them.Considering 
 climate change and the higher likelihood of flooding etc, itwould be 
 important to map the difference between paved streets thatdon't allow for 
 quick drainage and these loosely paved streets. There isprobably some 
 technical term for it.So, in short: Do we have a tagging scheme for those 
 or not?Anne
 Tagging mailing list Tagging@openstreetmap.org 
 https://lists.openstreetmap.org/listinfo/tagging

>> ___
>>  Tagging mailing list
>>  >> Tagging@openstreetmap.org
>>  >> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Fernando Trebien
>

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

Re: [Tagging] Liquidator store tagging

[Mateusz Konieczny via Tagging]

is it selling specific type of products or everything from dried fruits through 
clothes
and mugs to industrial solvents and cars?


Dec 17, 2023, 23:03 by jheromemig...@gmail.com:

> any idea for which is the best tag for a liquidator store (one that sells 
> goods from liquidated retailers)?
>

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

Re: [Tagging] shops for display

[Mateusz Konieczny via Tagging]

Nov 22, 2023, 22:05 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>> On 22 Nov 2023, at 18:33, Mateusz Konieczny via Tagging 
>>  wrote:
>>
>> I would consider it more as device than showroom
>>
>
>
> can you provide a dictionary definition for “device” that could refer to a 
> room? Because the ones I looked at wouldn’t fit.
>
I was referring to display setup in windows and/or orientationally boarded up 
vacant shop, not to a room.

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

Re: [Tagging] shops for display

[Mateusz Konieczny via Tagging]

Nov 22, 2023, 17:47 by dieterdre...@gmail.com:

> Am Mi., 22. Nov. 2023 um 17:12 Uhr schrieb Anne- Karoline Distel
> :
>
>>
>> My case was where you can't enter the premises, it's really just displaying 
>> goods or even (slightly different) displaying contact details for the 
>> business which has moved to the outskirts of town.
>>
>
>
> yes, your thread was somehow "hi-jacked" because we discovered we
> might also need tagging for showrooms. I think the best solution for
> your situation is no shop and maybe some advertising=* tag
> Actually "advertising" says it is for advertising devices, and your
> situation isn't a device I guess, so maybe it is a showroom without
> admittance?
>
I would consider it more as device than showroom
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shops for display

[Mateusz Konieczny via Tagging]

there is also https://wiki.openstreetmap.org/wiki/Tag:shop%3Doutpost

"Shop primarily used to pick-up items ordered online. May have meager supply of 
products."
which was used for shops which has basically no actual supply of products (
or sometimes nothing at all)

>From what I heard name of shop type makes no sense in English in this context,
shop=* is dubious here but I am not aware of a better tagging for that


Nov 22, 2023, 11:22 by p...@trigpoint.me.uk:

> This is becoming much more of a problem.
>
> In the UK we have a shop called Argos, where you order from a catalogue then 
> the item appears on a conveyor from an attached storage area a few minutes 
> later. You could also ask to see something before you bought it. A few years 
> ago they were large shops that had stock of pretty much everything in the 
> catalogue.
>
> Now they have become small areas in a supermarket which have no stock and 
> everything has to be ordered online and collected the next day. Other high 
> street shops are going the same way and making themselves irrelevant.
>
>
> On 21 November 2023 20:42:02 GMT, Niels Elgaard Larsen  
> wrote:
>
>> On Tue, 21 Nov 2023 13:01:32 +0100
>> Martin Koppenhoefer  wrote:
>>
>>>
>>>
>>> sent from a phone
>>>
 On 21 Nov 2023, at 12:47, Niels Elgaard Larsen 
 wrote: The wiki for Tesla says that Tesla showrooms are tagged
 shop=car A lot of shop=kitchen are really showrooms where you can
 order a kitchen which will be installed in you kitchen. The shop do
 not actually have kitchens for sale in the store.

>>
>>
>> I agree with that.
>>
>> But from the users point of view, there are some implicit expectations
>> depending of what is sold.
>>
>> For shop=estate_agent it should be obvious that you do not get anything
>> physical at the store.
>>
>> For shop=car it is less clear.
>> Also for shop=kitchen, some places will sell you a flatpack kitchen,
>> that you can put in the back of your car.
>>
>> I once drove to a shop=pet only to find out that it was the office for
>> a pet webshop that had a small showroom of cat scrathcing pads, etc.
>>
>> For eg furniture, appliances, bathroom devices, bicycles, glassware
>> there are showrooms and a user could reasonable expect to be able to go
>> there and just buy an item.
>>
>> With more stuff being sold online, we will probably see more showrooms,
>> and I think we should have a way to tell users if they can buy anything
>> at a shop, or it is just a showroom.
>>
>>>
>>> „ordering“ a kitchen or car in a shop is a sale, IMHO. The word sale
>>> does not imply you take the goods away with you immediately, nor that
>>> they are necessarily present at the point of sale.
>>>
>>> Cheers Martin 
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>

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

Re: [Tagging] shops for display

[Mateusz Konieczny via Tagging]

advertising=display_window works much better than shop=display_only
(as it is not a shop)

though maybe there is value with more immediately clear meaning?


Nov 20, 2023, 21:37 by 1998alexk...@gmail.com:

>
> Sounds like something like "advertising=display_window" or similar would make 
> more sense
>
>
> Alex
>
>
> On Mon, Nov 20, 2023, 21:29 Martin Koppenhoefer <> dieterdre...@gmail.com> > 
> wrote:
>
>>
>>
>> sent from a phone
>>  
>>  > On 20 Nov 2023, at 20:59, Anne-Karoline Distel <>> annekadis...@web.de>> 
>> > wrote:
>>  > 
>>  > Hi,
>>  > 
>>  > is there a way to tag shops that are not used for selling goods
>>  > directly, but are just used for display for the actual shop or even to
>>  > advertise something different? Here in Ireland, I think they are often
>>  > used to hide the fact that it's actually a vacant premises, and rates
>>  > are also different, I believe, if you're not actually conducting
>>  > business there. Would "shop=display_only" be a way to do it? I would
>>  > still like to have an option to mark them as vacant,  in a way.
>>  > 
>>  > They could be using the space inside to display their goods or even just
>>  > have the windows covered in decals to advertise that they have moved or
>>  > to advertise local sights or whatever.
>>  
>>  
>>  according to the wiki a shop is selling goods or services, if they don’t do 
>> either it’s not a shop for OpenStreetMap.
>>  
>>  Cheers Martin 
>>  ___
>>  Tagging mailing list
>>  >> Tagging@openstreetmap.org
>>  >> https://lists.openstreetmap.org/listinfo/tagging
>>

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

Re: [Tagging] Proposal: Use description instead of name for route relations

[Mateusz Konieczny via Tagging]

Oct 18, 2023, 09:30 by 61sundow...@gmail.com:

>
>
>
> On 17/10/23 23:22, Paul Johnson wrote:
>
>>
>>
>> On Tue, Oct 17, 2023 at4:51 AM Warin <>> 61sundow...@gmail.com>> 
>> >wrote:
>>
>>>
>>>
>>>
>>> On 17/10/23 04:17, Paul Johnson wrote:
>>>
 Presently, it's common for route  relations to have names 
 that violate "name is only the  name" and "name is not 
 ref" and "name is not  description" rules for name=* tags.

>>>
>>>
>>>
>>>
>>> I don't find it common in 'my area' of mapping. One ortwo 
>>> examples would demonstrate the situation?
>>>
>>>
>>>
>>>
>>>
>>> In any case:
>>>
>>>
>>> The name tag is used on may things for example;buildings, 
>>> parks, schools, highways ... 
>>>
>>>
>>> The use of the name tag as 'name only' applies whereever 
>>> the name tag is used. This is similar for othertags such as 
>>> elevation, width, colour etc. No matterwhat feature they 
>>> are used on the tags carry the samecharacteristics and 
>>> restrictions. It is not necessary torepeat these 
>>> characteristics and restrictions for everymain feature.
>>>
>>>
>> Routes have names, too!  For example, here's the relationfor OK 
>> 51, named for the name of the route.  >> 
>> https://www.openstreetmap.org/relation/3108562
>>
>> Meanwhile, I 40 in Arkansas has a good example of a namethat is 
>> actually a ref and a description, not a name.  >> 
>> https://www.openstreetmap.org/relation/6843700
>>
>>  Finally, OK 19 is an example of a properly describedno-name 
>> route.  >> https://www.openstreetmap.org/relation/7479405
>>
>
>
>
>
> Ok. I still don't see a necessity of repeating the name tag  information 
> inside the relation tag...
>
>
this proposal wants to remove wrong advise that advocates adding fake names to
relations

maybe just removing this bad advise without proposal would be a good idea
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Use description instead of name for route relations

[Mateusz Konieczny via Tagging]

Oct 17, 2023, 11:49 by 61sundow...@gmail.com:

>
>
>
> On 17/10/23 04:17, Paul Johnson wrote:
>
>> Presently, it's common for route relations to havenames that violate 
>> "name is only the name" and "name is not ref"and "name is not 
>> description" rules for name=* tags.
>>
>
>
>
>
> I don't find it common in 'my area' of mapping. One or two  examples 
> would demonstrate the situation?
>
>
See 
https://wiki.openstreetmap.org/wiki/Proposal:Use_description_instead_of_name_for_route_relations#Examples

name=Tram 64 (nocny): Bronowice Małe => Os. Piastów
from https://www.openstreetmap.org/relation/3171712 is an example

this tram line has no name

"Tram" is additionally wrong as not matching local language and "nocny" part)

useful label could be made from ref=* from=* to=* tags and there is no need
at all for this fake name.

Note that info that it is a night tram is not provided in any structured form, 
only as part of the fake name. This fake name should be removed and info
that it is a night tram put into some tag or into description=* 

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

Re: [Tagging] Tagging for the renderer : One-way "flow" bicycle tracks

[Mateusz Konieczny via Tagging]

Sep 10, 2023, 23:37 by graemefi...@gmail.com:

>
> On Mon, 11 Sept 2023 at 01:25, Niels Elgaard Larsen <> elga...@agol.dk> > 
> wrote:
>
>> Volker Schmidt:
>>  > Be careful: oneway=* is a legal access tag, only valid for vehicles, not 
>> for pedestrians.
>>  
>>  
>>  We do have a lot of highway=footway,oneway=yes
>>
>
> Also know of suspended Tree Walk walkways e.g. > 
> https://www.openstreetmap.org/#map=19/-28.23281/153.13822>  which are 
> signposted as oneway, & tagged the same
>
And there are oneway hiking trails where it is a legal restriction.

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

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

[Mateusz Konieczny via Tagging]

Aug 7, 2023, 02:58 by miketh...@gmail.com:

>
>
> On Sun, Aug 6, 2023 at 6:39 PM Evan Carroll <> m...@evancarroll.com> > wrote:
>
>>
>>
>> While I don't disagree, that's not an argument for OSM. OSM's job isn't to 
>> mitigate real world safety issues caused by technology. It's to map 
>> generally useful geographically verifiable things.
>>
> I don't understand how cell coverage isn't verifiable - visit the site (e.g. 
> campground) in question, pull out your phone, note how many bars, try to make 
> a call, send a text, use some data (perhaps run a speed test). Yes, it is 
> only good for your carrier, but the carrier should be recorded. Yes, there 
> could be network congestion, or a tower could be out, but we map roads, and 
> they can be congested, or closed due to accidents, flooding, landslides, 
> construction, etc.  In some way, this is getting back to our roots, actually 
> getting out and surveying, rather than just relying on satellite/aerial 
> imagery.
>
Mapping congestion of roads is also out of scope for OSM.

And cell phone reception varies wildly based on weather, time of year, 
operational
internals of operator, load on operator...

What seems potentially mappable is a place where people go (in area of poor or 
missing
coverage) to use phones as connection is better or existing at all there.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

Jul 30, 2023, 19:48 by marc_m...@mailo.com:

> Le 30.07.23 à 18:52, Brian M. Sperlongano a écrit :
>
>> On Sun, Jul 30, 2023 at 12:08 PM Marc_marc > > 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
>
esperanto is not a neutral language either (more neutral in some aspects,
less in some other aspects)

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

Re: [Tagging] [Talk-GB] Fords and how to provide information to help with routing apps

[Mateusz Konieczny via Tagging]

Jul 4, 2023, 17:05 by tagging@openstreetmap.org:

> On Tue, Jul 04, 2023 at 03:14:47PM +0100, Ian Dent wrote:
>
>> Previously it was tagged as ford=impassable but this isn't a valid value and
>>
>
> On reflection, that doesn't seem such a bad tag.
>
ford=impassable makes no sense

ford is by definition a passable place across waterway, if 
something is impassable then it is not a ford

if passage across waterway become destroyed: delete that
section of road/cycleway/footway.

(as usual, if really needed it is possible to temporarily use
lifecycle prefixes to prevent bad edits if nothing is left,
or map disused:highway= as long as some remains are visible

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

Re: [Tagging] [RFC] Feature Proposal - Wave Lounger

[Mateusz Konieczny via Tagging]

Jul 2, 2023, 10:40 by hungerb...@gmail.com:

> Am So., 2. Juli 2023 um 10:10 Uhr schrieb Mateusz Konieczny via Tagging
>
>>
>> Why not subtag for https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dlounger 
>> ?
>>
>
> That other tag can be applied to areas in two different ways: either
> representing a single item - or as a place, where
> commonly/sometimes/seasonally/depending on time of day/and who knows
> what - none, one, or more loungers can be found.
>
> This one is meant for fixed installs only and not for use on areas.
> The lounger tag cannot be reused because it is designed too badly.
>

I do not really see a big problem here, if someone wants they can 
add extra tags counting capacity/number of loungers or
intermittent=yes or seasonal=yes
But this should be listed in proposal to let people judge is it a good idea___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [RFC] Feature Proposal - Wave Lounger

[Mateusz Konieczny via Tagging]

Why not subtag for 
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dlounger
?

amenity=lounger lounger=wave
amenity=lounger lounger=wave_lounger

seems better to me as someone can map lounger without classifying
it subtype (and we may have ideas to map more lounger classes in
future)

And mentioning how to distinguish amenity=lounger from
amenity=wave_lounger would be useful in either case

---

"Generalisation should be up to the cartographers and not the mappers."

1) it depends on generalization type, some generalisation
is unavoidable at time of mapping and makes sense
Any classification of real objects (tagging objects in OSM)
already is some generalization

2) It is not changing that 

(A) cascading tagging
( amenity=general_class general_class=detail )

(B) using properties 
( amenity=general_class property=value )

is very often better
than (C) direct superdetailed classification
- amenity=super_detailed_subtype_a
- amenity=super_detailed_subtype_b
- amenity=super_detailed_subtype_c
- amenity=super_detailed_subtype_d
- amenity=super_detailed_subtype_e

amenity=wave_lounger sounds to me like using natural=oak
rather then natural=tree + separate property for mapping that
it is an oak ( say, taxon:en=oak )

or historic=memorial_bench instead of historic=memorial memorial=bench
or historic=blue_plaque instead of historic=memorial memorial=blue_plaque
or... (see other values at 
https://wiki.openstreetmap.org/wiki/Tag:historic=memorial?uselang=en#Tags_to_use_in_combination
 )
Jul 2, 2023, 00:55 by hungerb...@gmail.com:

> Please weigh in on this proposed new tag, here, in the community
> forum, in the wiki talk page:
>
> https://wiki.openstreetmap.org/wiki/Proposal:Wave_lounger
>
> Looking forward
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

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

[Mateusz Konieczny via Tagging]

Jun 20, 2023, 06:35 by matkoni...@tutanota.com:

> Jun 20, 2023, 01:36 by g...@lexort.com:
>
>> In English, the adjective for the shop tends to be singular, when that
>> adjective is a noun.  The plural just sounds funny.  For example we have
>> "car dealer", "grocery store", "grocery store", "cell phone store", etc.
>> So I am fine with shop=guns being viewed as a typo for shop=gun.
>>
> Can anyone else confirm this? I though that shop=guns would be preferable
>
> But after that comment and looking at > 
> https://wiki.openstreetmap.org/wiki/Key:shop
> I am not really sure.
>
I documented shop=gun at https://wiki.openstreetmap.org/wiki/Tag:shop%3Dgun
and reverted one of my edits that changed shop=gun to shop=firearms

(will look at all shop=firearms and shop=guns and check whether any other were
retagged from shop=gun by me recently)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

Jun 25, 2023, 01:13 by g...@lexort.com:

> Martin Koppenhoefer  writes:
>
>> sent from a phone
>>
>>> On 24 Jun 2023, at 00:29, Minh Nguyen  wrote:
>>>
>>> But if we focus too pedantically on legal status at the expense of
>>> common sense, then we've reinvented designation=*, and mappers and
>>> data consumers have to find yet another key to express what could've
>>> been in highway=*.
>>>
>>
>> oh yes, absolutely, if legal status and common sense/reality are not 
>> congruent we should record both.
>>
> (...)
>
> But none of that matters to OSM; if there is a shop that is selling
> cannabis, then it is tagged as such, regardless of whether it is a
> federal crime but not a state crime, a crime under neither legal regime,
> or a crime under both.  And it doesn't matter exactly how either regime
> defines what is or is not unlawful.
>
> So I find the attention to legal definitions in the present discussion
> bizarre.
>
That is a different situation. 

shop=medical_cannabis would be analogous to shop=firearms
as it is a legal term (if I understood it right) with variety of differences
across places and wild changes in its definition over time, and
therefore a poor terms to use in OSM (like shop=firearms apparently)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

Jun 21, 2023, 15:51 by g...@lexort.com:

> It is absolutely the wrong thing to say that shop=firearms means "a shop
> that sells whatever the local law means by firearms".   This is a
> general principle in OSM that we define something and then expect
> mappers to use the OSM definition, not local language.
>
Though if some specific term is primarily legal term and has crazy
definitions varying across world - then using a different term is a better idea,
if such term is available and is less confusing.

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

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

[Mateusz Konieczny via Tagging]

Jun 22, 2023, 14:46 by g...@lexort.com:

> Martin Koppenhoefer  writes:
>
>> sent from a phone
>>
>>> On 21 Jun 2023, at 15:52, Greg Troxel  wrote:
>>>
>>> It is absolutely the wrong thing to say that shop=firearms means "a shop
>>> that sells whatever the local law means by firearms".   This is a
>>> general principle in OSM that we define something and then expect
>>> mappers to use the OSM definition, not local language.
>>>
>>
>> I am not sure I can subscribe to this. Generally our tags are used
>> when the thing meets the local expectations of “such thing”, e.g. an
>> amenity=cafe or amenity=pub in England is probably different from
>> places with such a tag in Germany. Or a shop=bakery in England will
>> not necessarily sell the same kind of bread than one in France.
>>
>
> Of course it won't have the same kind of bread.  But it will still be a
> shop that sells primarily things that have been baked, pastry and bread.
>
> Suppose in some other country, bakery is a term that means a shop that
> primarly sells sausages.  We wouldn't say that this should be
> amenity=bakery.
>
And this is not merely theoretical!

word "bar" in Polish does not mean the same as in English and has
much wider meaning range.

See https://en.wikipedia.org/wiki/Bar_mleczny
See https://pl.wikipedia.org/wiki/Bar_(plac%C3%B3wka_gastronomiczna)

Place selling 
https://commons.wikimedia.org/wiki/File:Bar_mleczny_Kalina,_Poznan,_pomidorowka,_watrobka.jpg
as typical thing is not amenity=bar even if it is locally called "bar".

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

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

[Mateusz Konieczny via Tagging]

Jun 20, 2023, 01:36 by g...@lexort.com:

> In English, the adjective for the shop tends to be singular, when that
> adjective is a noun.  The plural just sounds funny.  For example we have
> "car dealer", "grocery store", "grocery store", "cell phone store", etc.
> So I am fine with shop=guns being viewed as a typo for shop=gun.
>
Can anyone else confirm this? I though that shop=guns would be preferable

But after that comment and looking at 
https://wiki.openstreetmap.org/wiki/Key:shop
I am not really sure.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

Jun 19, 2023, 23:57 by graemefi...@gmail.com:

>
> On Tue, 20 Jun 2023 at 03:48, Marc_marc <> 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 e.g. > https://www.kingofknives.com.au/> , & which is not just a 
> shop=houseware as they also sell hunting, fishing & trade (chef / butchers 
> etc) knives.
>
I have created https://wiki.openstreetmap.org/wiki/Tag:shop%3Dknives

>
> You also have shops that only sell ammunition, not guns: > 
> http://www.uniquemunitions.com/
>
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dammunition has single use
Is there a different tagging for that or is it not mapped/extremely rare?

> There should probably also be a shop=archery, as bows & arrows are often 
> found in their own shop, not associated with shooting.
>
I would use shop=sports sport=archery, though shop=archery has some uses
(maybe there are archery shops where shop=sports sport=archery would be 
invalid?)

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

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

[Mateusz Konieczny via Tagging]

OSM Wiki currently claims that

shop=guns should be replaced by shop=weapons
https://wiki.openstreetmap.org/w/index.php?title=Tag:shop%3Dweapons

Tag:shop=firearms redirects to shop=weapons
https://wiki.openstreetmap.org/w/index.php?title=Tag:shop%3Dfirearms=no

Tag:shop=gun redirects to shop=weapons
https://wiki.openstreetmap.org/w/index.php?title=Tag:shop%3Dgun=no

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)
- remove shop=firearms and shop=gun and shop=guns redirects

Maybe also create shop=knives page
https://wiki.openstreetmap.org/w/index.php?title=Tag:shop%3Dknives=edit=1

Create shop=firearms page, describing shop=gun and shop=guns as duplicates of 
it.

-

Basically I propose to
- document shop=knives
- document shop=firearms
- undeprecate shop=firearms
- change deprecation targets of shop=gun and shop=guns

-

Comments are welcome!

PS maybe shop=weapons weapons=guns or shop=weapons weapons=firearms
would make sense, and be preferable over shop=firearms?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] road accident memorials

[Mateusz Konieczny via Tagging]

In Poland many of them are small crosses without any text or description
so it is not entirely obvious why they were placed (though you can guess 
quite reliably).


Jun 11, 2023, 14:31 by annekadis...@web.de:

>
> I would think that they are still memorials, if they commemorate  an 
> accident or suicide.
>
>
> I'm not aware of terribly many use cases for man_made=cross,  maybe at 
> open air church service locations or along stations of  the cross.
>
>
> Food for thought, anyway.
>
>
> Anne
>
> On 11/06/2023 10:29, Mateusz Konieczny  via Tagging wrote:
>
>> I typically tagged such crosses as man_made=cross
>>
>> historic=memorial memorial=cross man_made=cross ?
>>
>> Jun 11, 2023, 02:27 by >> annekadis...@web.de>> :
>>
>>> A historic=wayside_cross does not mark the spot; it is not  left in 
>>> a
>>> location where someone is buried or died. It is a way to  make sure 
>>> the
>>> soul of the deceased gets into heaven easier by having  passers by 
>>> pray
>>> for the soul. You don't have to believe in it, but that's  what 
>>> people
>>> believed back then (and maybe some still do).
>>>
>> note that it is not the only reason for placingthem
>>
>>
>> ___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] road accident memorials

[Mateusz Konieczny via Tagging]

I typically tagged such crosses as man_made=cross

historic=memorial memorial=cross man_made=cross ?

Jun 11, 2023, 02:27 by annekadis...@web.de:

> A historic=wayside_cross does not mark the spot; it is not left in a
> location where someone is buried or died. It is a way to make sure the
> soul of the deceased gets into heaven easier by having passers by pray
> for the soul. You don't have to believe in it, but that's what people
> believed back then (and maybe some still do).
>
note that it is not the only reason for placing them

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

Re: [Tagging] [RFC] Feature Proposal - Extended playground equipment

[Mateusz Konieczny via Tagging]

playground=ride

Is it supposed to include also coin operated ones that make 
noise/lights/movements?

https://www.google.pl/maps/@50.054966,19.8545417,3a,15.3y,207.67h,84.22t/data=!3m7!1e1!3m5!1sHED2kF0PByYJyi9CYVjXXw!2e0!5s20110801T00!7i13312!8i6656?entry=ttu
caught one

re: playground=hammock

These are also placed independently from playgrounds. Maybe have single tag for 
both?

re: playground=artwork
why not just normal artwork tagging? 

"If it has a significant art relevance, consider also adding tourism=artwork. "

Note that vast majority of tourism=artwork has no art relevance and definitely 
no
significant art relevance

re: playground=steps
why not use regular step tagging?

(the same goes for some other tags)


May 27, 2023, 08:46 by supap...@riseup.net:

>
> Hi all,
>
>
>
>
> anyone who maps playground equipment from time to time might be  familiar 
> with the issue: The playground values from the wiki  represent only a 
> small range of possible playground devices, for  many others you have to 
> get creative, come up with your own tags  or dig through TagInfo to see 
> how other mappers might have mapped  a device.
>  
>  As a group of mappers who regularly map playgrounds, we are  proposing 
> more values to the list of documented playground  equipment to better map 
> typical devices that had no documented  value before.
>  
>  > https://wiki.openstreetmap.org/wiki/Proposal:Extended_playground_equipment
>  
>  Please discuss this proposal on its Wiki Talk page.
>
>
>
>
>
>
> Best,
>  Alex for the group of proposal authors
>
>
>
>

___
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

[Mateusz Konieczny via Tagging]

Is it about https://wiki.openstreetmap.org/wiki/Key:changing_table
for adults?


May 22, 2023, 14:20 by ro...@onwheelsapp.com:

>
>  
>
>
>  
>
>
> Changing places
>
>
>  
>
>
> For the moment there is no tag for a changing place: > 
> https://www.changing-places.org/
>
>
> With the On wheels app we want to add
>
>
>  
>
> amenity=changing_places
>
>  
>
>
> Possible tag combinations would be:
>
>
>  
>
> toilets:wheelchair  (yes, no)
> entrance:width    (number)
> shower:wheelchair    (yes, no)
> hand_basin:wheelchair (yes, no)
> changing_table   (yes, no)
>
>  
>
>
>  
>
>
> Changing_table:
>
>
>  
>
>
> We want to add the following new tags to changin_table:
>
>
>  
>
> changing_table:size or changing_table:user_type   (children, adults)
> changing_table:hoist      
>   (yes, no)
> changing_table:type   
>    (manual, electric, fixed)
>
>  
>
>
>  
>
>
> Robin Julien
>
>
> On Wheels
>
>
>  
>
> 
>
> Virusvrij.> www.avast.com 
> 
>  
>
>

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

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

[Mateusz Konieczny via Tagging]

Apr 24, 2023, 18:43 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>
>> On 20 Apr 2023, at 22:04, Marc_marc  wrote:
>>
>> is roof:shape=pitched an imprecise value ?
>>
>
>
> as you ask about imprecise, what about “round” or “many”?
> https://taginfo.openstreetmap.org/keys/roof:shape#values
>
"many" has valid use case
"Marks that building has multiple different roof shapes at once"
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] openGeoDB* discardable ?

[Mateusz Konieczny via Tagging]

Apr 20, 2023, 22:18 by marc_m...@mailo.com:

> 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.
>
oh, then such sad workaround may be needed (though personally
I would rather put on TODO list and retry in in 2025 - still faster
than centuries of waiting till all objects with discardable tag will
be edited by editor that has discardable tag list for removal)

but in such case adding them to discardable tags is also fine
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=screenprinting

[Mateusz Konieczny via Tagging]

Apr 21, 2023, 16:19 by marc_m...@mailo.com:

> 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
>
shop=printing_on_objects ? seems more clear than shop=screenprinting

(not a native speaker disclaimer)

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

Re: [Tagging] shop=screenprinting

[Mateusz Konieczny via Tagging]

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?

BTW, we also miss a good tag for printing services more developed
than A4 copies in low quality covered by shop=copyshop
- we have no good way to mark places where you can go and print
few copies of A3 or A2, in colour, in reasonable quality - shop=printing
was also widely used for places where you can print only low quality
A4 prints.
Maybe subtags for availability of A2/A3 print services would be helpful?
Not sure is separate shop=* tag is a good idea as there is no clear border
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=screenprinting

[Mateusz Konieczny via Tagging]

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 betterr value or a good value that need documentation ? :)
>
is it selling supplies for screen printing or offering it as a service? Or both?

shop=screen_printing_supplies seems better for first
and maybe craft=screen_printing for second?
Or shop=screen_printing_services ?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

Apr 19, 2023, 22:46 by elga...@agol.dk:

> Matija Nalis:
>
>> Hm, I do, but as it would be rather hard to prove (and such proof is not
>> paramount here), lets us just agree that it is how certain amount of
>> mappers use it (without trying to quantify it with subjective guesses).
>>
>
>
> I think it depend a lot from key to key.
>
>> 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").
>>
>
> Yes, but only because we have no way of denoting that lpg is not being sold 
> in the second format and that you knew that lpg was not being sold when 
> tagging it.
>
> consider instead for example opening_hours.
>
> The wiki is not very clear about whether it is exhaustive. I.e., if you for a 
> facility tag:
>
>  opening_hours=Mo-Fr 09:00-20:00
>
> is it open on weekends, or is it not specified?
>
For opening hours I would expect that at least normal operation is tagged
(it may be still closed during some general nationwide holidays but 
this specific case I would expect to be closed on weekends and if
open on weekends then it would tagging mistake)

Similarly
opening_hours=Mo 09:00-20:00
means that it is open only on Mondays


> If I know that it is closed on weekends, I prefer to tag it:
>
>  opening_hours=09:00-20:00; Sa-Su off
>
> to avoid ambiguity.
>
Not sure does it help much.

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

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

[Mateusz Konieczny via Tagging]

Apr 19, 2023, 00:14 by mnalis-openstreetmapl...@voyager.hr:

> On Tue, 18 Apr 2023 17:08:39 +0200, Marc_marc  wrote:
>
>> 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
>>
>
> Agreed.
>
I made initial edit in
https://wiki.openstreetmap.org/w/index.php?title=Key:fuel=2506079=2451100

Feel free to edit/amend/improve.

Thanks for all comments!

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

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

[Mateusz Konieczny via Tagging]

Apr 18, 2023, 17:12 by marc_m...@mailo.com:

> 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
>
Great, I will note it at relevant wiki page unless someone will protest.

>> 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
>
=only works only when you have station offering single fuel, right?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

Apr 18, 2023, 17:39 by p...@trigpoint.me.uk:

> I have come across a few cases where a mapper has has blindly answered no to 
> a list of octane ratings that do not exist in the country they are mapping in.
>
> In the UK it is safe to assume every filling station sells Euro 95/E10 and 
> diesel.
>
Are there also LPG-only stations in UK?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

For example amenity=fuel + fuel:octane_80=yes

Is it implying that it is sole type of fuel available?
Would it be mistake to tag 
amenity=fuel + fuel:octane_80=yes
when also some other fuels are available?
It seems to be fine, is it right?

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
resulting in
amenity=fuel
fuel:octane_80=yes
fuel:octane_98=yes
fuel:others=no

Previously asked on
https://wiki.openstreetmap.org/wiki/Talk:Key:fuel#Is_tagging_of_fuel:_assumed_to_be_exhaustive?
but there was minimal response
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] openGeoDB* discardable ?

[Mateusz Konieczny via Tagging]

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

I see a point of making tag discardable if there are say 100 000 000 uses
of it, but at this volume bot edit seems preferable over slowly removing it over
centuries as other edits are being made.

Apr 15, 2023, 16:46 by marc_m...@mailo.com:

> 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
>

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

Re: [Tagging] Difference between graffiti and mural

[Mateusz Konieczny via Tagging]

why only "notable"?


Apr 15, 2023, 19:17 by dcapil...@gmail.com:

> Hi,
>
> I would like to properly document the use of 'artwork_type=graffiti', a 
> previously undocumented but widely used tag, to clarify the difference (if 
> any) between a graffiti and a mural ('artwork_type=mural').[1]
>
> Any suggestions? Any comments would be appreciated.[2]
>
> Regards,
>
> Daniel Capilla
>
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:artwork_type%3Dgraffiti
>
> [2] 
> https://community.openstreetmap.org/t/difference-between-graffiti-and-mural/98056
>
>
> ___
> 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] Status of clothes=motorcycle

[Mateusz Konieczny via Tagging]

As far as I see they have not provided - either on page or in edit description
why it is deprecated or where it was discussed.

I reverted it.

Thanks for catching it.

I am not aware of any deprecation here or of a good reasons for that.
This tags may make sense at least for some shops, though I am
not familiar with this type of retail.

Apr 6, 2023, 10:53 by illiamarchenk...@gmail.com:

> 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?
> Regards, 
> Illia. 
>

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

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

[Mateusz Konieczny via Tagging]

Mar 31, 2023, 01:53 by ajt1...@gmail.com:

> On 30/03/2023 18:13, NKA mapper wrote:
>
>> tor. 30. mar. 2023 kl. 18:14 skrev Andy Townsend  <>> 
>> ajt1...@gmail.com>> >:
>>
>>>
>>> How do I know if an "amenity=charging_station" in theOSM 
>>> data is a "single charge point" or a "group ofchargers"?
>>>
>>>
>> The intention is to not have a difference. Both a singlecharger 
>> location and a multi-charger location is a placewhere you could 
>> charge your vehicle, and the proposal is tomap them the same 
>> way. This is similar to a fuel station,where I would tag one 
>> single pump, typically at a rurallocation, as amenity=fuel. 
>>
>
> That would be a problem, as trying to use the same tag for  different 
> physical objects always is in OSM.  If I
>
>
>
>
> gis=> select count(*) from [some database table] where amenity  = 
> 'charging_station';
>   count
>  ---
>     267
>  (1 row)
>
>
>
>
> How do I know what I am counting?  How do I count just "single  charge 
> points"?  How do I count "groups of chargers"
>
>
You are counting distinct charger points, some of them may have single charge 
point
with capacity for one car (may be tagged capacity=1), some may be single charge
point with capacity for more cars (may be tagged capacity=2 or something), some 
may be
groups of two charge points and so on.

Note that currently you also can get both "30 charger points, each as own 
object"
and "single station mapped once" so situation will get better, not worse.

>> Of course tags like capacity and socket would giveindications.
>>
>
> If tagged, but plenty exist without those: > https://overpass-turbo.eu/s/1ta8
>
>
Yes, problem exists also now anyway.


StreetComplete asks about this missing info


>> And if amenity=charging_station is tagged as an areaaround a 
>> number of charge points, that would be a group.
>>
>
> That'd need to be a spatially-aware query, and I wouldn't assume  that 
> data consumers can easily do that.  At the place where I  detect charging 
> stations I don't have that capability: > 
> https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L1492>
>   .
>
>
> If the same tag must be used for both, the only way to tell  "single 
> charge point" from "group of chargers" is to have a tag  that is set to 
> indicate which is which.  If "newtag=single" it  means it's a single 
> charge point, if "newtag=group" it's a group,  and if "newtag" is not 
> set, we don't yet know, and need to  encourage local mappers to add the 
> tag.
>
>
I guess that can be useful.

How you distinguish "marks group of chargers" and "marks single charger within
group of chargers" now?

Is it "ideally proposal would introduce this ability" or "proposal breaks 
existing ability"?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

Mar 30, 2023, 18:14 by ajt1...@gmail.com:

> On 30/03/2023 09:25, NKA mapper wrote:
>
>> 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.
>>
>
> How do I know if an "amenity=charging_station" in the OSM data is  a 
> "single charge point" or a "group of chargers"?
>
>
I guess that in such cases it may be possible to tag it both as charging 
station and
a charge point at the same time?

Invent charge_point_count=1 ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

Mar 30, 2023, 16:11 by marc_m...@mailo.com:

> 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
>
that would be far worse: break many data consumers and require retagging far 
more cases

And would also redefine amenity=charging_station anyway

>> 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
>
It is sufficient to review all cases with amenity=charging_station next to each 
other,
which is doable and only tiny amount of cases will require on the ground checks
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

Mar 30, 2023, 10:50 by marc_m...@mailo.com:

> 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
>
type=site are highly obnoxious to use, create and edit

with relatively low number of affected objects, no need
for action from data consumer side in most cases and better
semantics it seems rare case where redefining in use tag
makes sense

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

Re: [Tagging] [OSM-talk] Proposed automatic replacements of multiple surface=* and shop=* values (review welcomed!)

[Mateusz Konieczny via Tagging]

Feb 25, 2023, 23:21 by dieterdre...@gmail.com:

> I'm moving this to tagging.
>
> Am Sa., 25. Feb. 2023 um 22:04 Uhr schrieb Mateusz Konieczny via talk <> 
> t...@openstreetmap.org> >:
>
>>>
>>>
>> Shops selling pierogi are definitely not shop=pasta
>>
>
>
> compare these pictures, 
>
> pierogi: > https://commons.wikimedia.org/wiki/File:Pierogi_z_cebulk%C4%85.jpg
> pasta: > 
> https://blog.giallozafferano.it/ilpeperonerosso/wp-content/uploads/2019/01/IMG_2133-768x576.jpg
>
> maybe it should be shop=noodles? I had tagged a pasta shop with noodles, but 
> when I checked in taginfo I saw there were only 3 others, but more than 600 
> shop=pasta so I changed the tag.
>
Huh.

I guess that my protest was caused by being aware only about pasta secca (dried)
https://en.wikipedia.org/wiki/Pasta

I guess that you can argue that fresh pasta is subtype of dumpling 
( https://en.wikipedia.org/wiki/Dumpling ) or that dumplings are subtype of 
fresh pasta.

still tagging shop selling pierogi (that require heating/boiling to be eaten)
 as shop=pasta seems alien to me and I would prefer something else
And https://en.wikipedia.org/wiki/Noodle seems something separate.

my tagging ideas for place selling pierogi almost ready to eat but 
requiring further cooking, sold fresh - not frozen:

shop=food food=pierogi
shop=food food=prepared_meal cuisine=pierogi
shop=food food=prepared_meal prepared_meal=pierogishop=food 
prepared_meal=pierogi
shop=food main_food=pierogi
shop=prepared_meal prepared_meal=pierogi

or if I would hate data consumers

shop=pierogi

but this way you will get endless shop values for various food,
as there is basically endless variety of shops selling some highly
specific food type. Just from Poland you would get
shop=oscypek (special type of cheese)
shop=obwarzanek (special type of bread snack)
shop=śliwowica (some plum-related alcohol)
shop=smoked_mackerel (specific method of preparing specific fish)
and so on

(I would tag them with more generic fitting value and add this info as
additional tag, say shop=cheese cheese=oscypek )


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

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

[Mateusz Konieczny via Tagging]

Feb 25, 2023, 20:57 by g...@lexort.com:

> Mateusz Konieczny via Tagging  writes
>
>
>> what worse, even if tagged in say highway=service this gate may
>> be not large enough to fit a car
>>
>
> highway=service by definition is enough for cars so if there is a gate
> on a highway=service that does admit cars on both sides, but is not wide
> enough for a car, then I would say this is mistagged and there should be
> a short way that is path or whatever.
>
Good point, I even argued for that viewpoint recently.
Still, car can fit but maybe lets say that bus will not fit.


>>> With
>>>
>>>  access=private
>>>  foot=yes
>>>  locked=yes
>>>
>>> then it says that phsical passage is not possible and hence if people
>>> can walk around then it needs a way representing walking around.
>>>
>> this one is tricky and expecting that it will be used consistently
>> will not work well
>>
>
> True, but we have to guess at what is right, and then when users do it
> wrong explain and fix.
>
I kind of hope for more clear solution.

>> +1 to separate bypass ways if matching reality
>> not sure how to handle cases where bypass way does not work
>> (for example you can crawl under lift gate, it is allowed, you cannot get 
>> around it)
>>
>
> I guess that's still a separate way that's path with a height
> restriction, even if it overlaps.
>
I was thinking about case where there is no path at, you walk on road,
under lift gate.

>>> I realize there have  been "but we can invent complicated bypass tags"
>>> but those seem to not interact well with existing data consumers and it
>>> does not seem we have consensus.
>>>
>> +1 though some cases where bypass way does not work are annoying
>>
>
> I think if we let it overlap it's ok.
>
https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
If there is only road and there is no path then mapping path does
not work well either.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

In general I agree but

Feb 25, 2023, 19:58 by g...@lexort.com:

> I am assuming --  but the wiki is unclear -- that
>
>  access=private, tagged on barrier=gate
>
> means that all modes of travel have a right of access only with
> permission
>
note that some may not physically fit (even with permission your elephant
may be still not fitting some entrances)

>
>  and that
>
>  access=private
>  foot=yes
>
> means that all modes need permission except for foot which has a legal
> right to pass.
>
note that often foot=permissive would be more accurate
but foot=yes is used
(especially common in areas where legal right of way is rare or not
existing and basically all =yes are actually =permissive)


> With
>
>  access=private
>  foot=yes
>  locked=no
>
> then it's clear that physical passage is possible for all modes.
>
not entirely

for example if tagged on highway=footway line then  I would
not assume that car would fit there

what worse, even if tagged in say highway=service this gate may
be not large enough to fit a car

>
>   With
>
>  access=private
>  foot=yes
>  locked=yes
>
> then it says that phsical passage is not possible and hence if people
> can walk around then it needs a way representing walking around.
>
this one is tricky and expecting that it will be used consistently
will not work well

+1 to separate bypass ways if matching reality
not sure how to handle cases where bypass way does not work
(for example you can crawl under lift gate, it is allowed, you cannot get 
around it)

> I realize there have  been "but we can invent complicated bypass tags"
> but those seem to not interact well with existing data consumers and it
> does not seem we have consensus.
>
+1 though some cases where bypass way does not work are annoying

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

Re: [Tagging] [RFC] Feature Proposal - landcover proposal V2

[Mateusz Konieczny via Tagging]

Feb 21, 2023, 12:30 by 61sundow...@gmail.com:

>
>
>
> On 19/2/23 06:00, Mateusz Konieczny via  Tagging wrote:
>
>>
>>
>>
>> Feb 17, 2023, 11:03 by >> 61sundow...@gmail.com>> :
>>
>>>
>>>
>>>
>>> On 16/2/23 21:11, Mateusz Konieczny via Tagging  wrote:
>>>
>>>>
>>>>
>>>>
>>>> Feb 16, 2023, 10:18 by >>>> 61sundow...@gmail.com>>>> :
>>>>
>>>>>
>>>>> landuse=meadow should delete the vegetation in the  
>>>>> description leaving the use ... "Used to tag an area of  land 
>>>>> used for hay (meadow) or for grazing animals  (pasture)." 
>>>>> That would make it clear and possibly reduce  its misuse. If 
>>>>> you can only see grass then you don't know  if it is a 
>>>>> meadow, so don't map that .. but map the grass!
>>>>>
>>>>>
>>>> note that barn storing hay is notlanduse=meadow and according 
>>>> to 
>>>> "land used for hay (meadow)" maybe interpretedin way claiming 
>>>> this.
>>>>
>>>
>>>
>>>
>>>
>>> That problem already exists with the present description, so  no 
>>> change there. 
>>>
>>>
>> It does not exist:
>>
>> "An area of meadow or pasture: land primarilyvegetated by grass
>> and other non-woody plants, mainly used for hay orgrazing."
>>
>>
>>
>
>
>
>
> Arr I see your point (finally) .. How is this?
>
>
> "Used to tag an area of land used to produce hay (a meadow) or  for 
> grazing animals (a pasture)."
>
>
seems to work for me
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

Feb 24, 2023, 00:43 by g...@lexort.com:

> It's a little unclear to me what a "locked=no" gate is.
>
access=private locked=no would be a gate that anyone can open
but they are not allowed to without a permission from owner.

Personally I would consider mapping this as quite dubious.

>  foot=yes on a barrier=gate means that a person on foot can pass the
>  gate (perhaps by walking around it) with minimal difficulty, such that
>  the gate's presence should not affect routing
>
1) if they can walk around it then map path around it

2) if they can but are not allowed to bypass it then it will not be foot=yes
(also on path around it)

https://www.openstreetmap.org/way/368814327 is an example
of path where barriers can be bypassed but is illegal and dangerous to use
(has signs mentioning how many people died there while illegally
crossing railway tracks)

>
>  barrier=gate locked=no (or no locked, default?) means that all modes
>  may physically pass, with a mode-specific typical cost
>
>
>  barrier=gate locked=yes means that all modes may not pass, unless
>  there is a mode-specific foot=yes or bicycle=yes
>
(...)

>
> So we need three properties:
>
>  legal right of access, perhaps only needed on ways
>
>  physical ability to pass a gate
>
>  is the gate locked, and if so which modes does that apply to
>
agree

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

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

[Mateusz Konieczny via Tagging]

Feb 24, 2023, 09:25 by 61sundow...@gmail.com:

>
>
>
> On 23/2/23 21:18, Peter Elderson wrote:
>
>> I would like to change the status of thisestablished tag to 
>> approved. I have altered the previous >> proposal 
>> >>  to 
>> match the establishedpractice.
>>
>
>
>
>
> No, it has not been 'approved' so it would be misleading to claim  it is 
> 'approved'. (Approval is given by voting on a proposal these  days.)
>
>
> The status might be 'de-facto'. 
>
>
And I changed it to "de-facto".

Personally, I would consider vote just to change status to "approved" seems 
pointless.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

Feb 21, 2023, 22:05 by tagging@openstreetmap.org:

> They can also be removed by maintenance workers operating with permission 
> from the local Council  (I have tagged the access rights of the ways with 
> "motor_vehicle=permit"
>
=permit is for cases where permit is routinely granted to all

this would be rather =private at most

we really should deprecate rename this access field, it is misinterpreted all 
the time
making it useless (=permit_ordinarily_granted ? )
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

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

> I would like the help of the list to clarify the meaning of having a 
> "locked=yes" tag on a barrier node together with some allowed access tags.
>
> The introduction to the "locked" tag wiki page > 
> https://wiki.openstreetmap.org/wiki/Key:locked>  says:
>
>> access >> =*>>  is used to 
>> describe the legal permission to travel through a barrier but does not 
>> indicate in emergencies what the physical access is
>>
>
> Therefore, my understanding is that 
> As far as non-emergency routing, the "locked" tag should be ignored.
> 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.
> 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.
>
In general I agree.

---

It may be nitpicking but I would phrase it "cannot be overcome by just opening 
it"

Depending on exact barrier it may be relative easy to cross, and depending on
exact emergency, customs and local law barrier may be destroyed by responders,
in some cases quite easily.

In some cases for example gate may be locked by you can get around it easily.



> The "How to map" description in the wiki page seems to assume a gate or a 
> barrier with a simple "access=no". It is not clear with respect to any 
> permitted access methods. 
>
>  For example, barrier node with the following tags:
>
>
>
> tag
> value
> barrier
> gate
> motor_vehicle
> no
> locked
> yes
> bicycle
> yes
> foot
> yes
>
>
>
> I think this tagging says: 
> There is a locked gate that blocks motor vehicles
> There are no access restrictions for pedestrians and bikes
>

I agree but I cannot imagine such barrier.

> This is not the interpretation of other people, as seen in a discussion on a 
> GraphHopper routing issue
>   > 
> https://github.com/graphhopper/graphhopper/issues/2757#issuecomment-1434806229
> There you could also find a picture of such a barrier.
> Please help us resolve the differences
>
That is better mapped by mapping path around barrier, at least in my opinion.

See say https://www.openstreetmap.org/way/1079963925

This can be more easily understood without elaborate hard to interpret tagging

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

Re: [Tagging] [RFC] Feature Proposal - landcover proposal V2

[Mateusz Konieczny via Tagging]

Feb 17, 2023, 11:03 by 61sundow...@gmail.com:

>
>
>
> On 16/2/23 21:11, Mateusz Konieczny via  Tagging wrote:
>
>>
>>
>>
>> Feb 16, 2023, 10:18 by >> 61sundow...@gmail.com>> :
>>
>>>
>>> landuse=meadow should delete the vegetation in the  description 
>>> leaving the use ... "Used to tag an area of land  used for hay 
>>> (meadow) or for grazing animals (pasture)." That  would make it 
>>> clear and possibly reduce its misuse. If you can  only see grass 
>>> then you don't know if it is a meadow, so don't  map that .. but 
>>> map the grass!
>>>
>>>
>> note that barn storing hay is not landuse=meadowand according to 
>> "land used for hay (meadow)" maybe interpreted inway claiming this.
>>
>
>
>
>
> That problem already exists with the present description, so no  change 
> there. 
>
>
It does not exist:

"An area of meadow or pasture: land primarily vegetated by grass
and other non-woody plants, mainly used for hay or grazing."


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

Re: [Tagging] [RFC] Feature Proposal - landcover proposal V2

[Mateusz Konieczny via Tagging]

Feb 13, 2023, 20:14 by fl.infosrese...@gmail.com:

> Hi,
>
> Le lun. 13 févr. 2023 à 14:11, Andy Townsend <> ajt1...@gmail.com> > a écrit :
>
>>
>> > By the way, I saw some changes leading to x10 contribution  rates and 
>> > be criticized as disrupting longstanding practices or  established 
>> > tagging.
>>
>>
>> An actual example would be really useful here.
>>
>>
> Here are some, very specific tagging but whatever:
> * Back to 2013, replacing power=station and power=sub_station by 
> power=substation and power=plant
> Respectively 4 + 11 in 5 years (30k/year) versus 50 + 7 in 8 
> years (71k/year) => x2.3
>
Have you compared increase in activity with change in OSM activity in general
or other unrelated object types where no such changes happened?
For example other power network tagging where no such proposal happened
or happened at a different time?

It seems dubious to attribute that change solely to this deprecation.

More likely seems that whatever reason caused greater interest resulted in the
increased mapping activity and tagging proposals.
Not that tagging proposals resulted in greater activity.

Is it possible that change in tag use was result of imports?

>
> * In 2018, replacement of voltage-high/voltage-low by 
> voltage:primary/voltage:secondary
> Respectively 6200 + 4600 in 8 years (1350/year) versus 11+95000 in 5 
> years (41k/year) => x30
>
https://taginfo.openstreetmap.org/keys/voltage%3Aprimary#chronology has clear
sign of import/bot edits

no idea why you would attribute that to tagging proposal

>
> * In 2021, replacement of tower:type=branch by line_management=branch or 
> split or cross
> Respectively 3600 in 7 years (515/year) versus 22030 in 2 years (11k/year) => 
> x21
>
here using tower:type was a clear mistake, so making tagging this detail more 
acceptable
could have a good effects.

Though not sure had this tag change had any serious opposition.

> Regarding the valuable point you make on tagging meta data making osm tags 
> invisible for common users, I wonder why we are busy with writing readable 
> proposals and then stuck on updating manually every toolchain with the same 
> information.
>
because various tool do different things with OSM data

(though area data type for example would help, see
https://github.com/osmlab/osm-data-model/discussions/9
https://github.com/osmlab/osm-data-model/issues/44 )

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

Re: [Tagging] [RFC] Feature Proposal - landcover proposal V2

[Mateusz Konieczny via Tagging]

Feb 16, 2023, 10:18 by 61sundow...@gmail.com:

>
> landuse=meadow should delete the vegetation in the description  leaving 
> the use ... "Used to tag an area of land used for hay  (meadow) or for 
> grazing animals (pasture)." That would make it  clear and possibly reduce 
> its misuse. If you can only see grass  then you don't know if it is a 
> meadow, so don't map that .. but  map the grass!
>
>
note that barn storing hay is not landuse=meadow and according to 
"land used for hay  (meadow)" maybe interpreted in way claiming this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [RFC] Feature Proposal - landcover proposal V2

[Mateusz Konieczny via Tagging]

Or to be more specific solved problems, if any, are much smaller than size 
of change of longstanding tagging practices.

Deprecation of old-style multipolygons was also change of
"longstanding tagging practices" but much smaller in scope and with much 
greater benefits.

I listed some obvious issues at the talk page, but in general to start process 
of 
replacing natural=water you would need really good arguments.


Feb 10, 2023, 19:16 by zelonew...@gmail.com:

> This is a change to longstanding tagging practices and is therefore dead on 
> arrival.
>
> On Fri, Feb 10, 2023, 11:33 AM Cartographer10 via Tagging <> 
> tagging@openstreetmap.org> > wrote:
>
>> Tjuro and I started a proposal to formalize the usage of `landcover=*`. The 
>> proposal is now open for feedback 
>> https://wiki.openstreetmap.org/wiki/Proposed_features/landcover_proposal_V2
>>
>> Please discuss this proposal on its Wiki Talk page.
>>
>> Kind regards,
>> VIncent
>> ___
>>  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] [Talk-us] New MapRoulette Challenge - Add Surface to Highways

[Mateusz Konieczny via Tagging]

Users in Algeria were asked to map motorway surface in tunnels, based
on aerial imagery.

It become marked as surface=ground, see 
https://www.openstreetmap.org/way/490378286/history

adding surface to motorways is of so dubious utility that for example
StreetComplete is not asking to specify such surface if missing.

Overall effort/effect ratio is really bad here and effect may be more negative
than positive.

I agree that mapping surface on more minor roads is useful and in fact I am 
right now coding a better support for that in StreetComplete (surface overlay).

But mapping surface of motorways seems to not be a good use of time,
and asking others to do this is quite surprising.

H, maybe I should implement 
"motorways are assumed to be concrete/asphalt" in StreetComplete surface 
overlay.

Feb 3, 2023, 10:23 by walker.t.brad...@gmail.com:

> I use routing to measure accessibility to schools and health clinics here in 
> west Africa. I have to make sure that my models also work in South Asia. 
> Having the surface tag attributed makes processing infinitely easier because 
> I don’t have to adjust my default values based on country.  Across Africa, 
> and south Asia, many secondary, primary, trunk roads are not paved. Knowing 
> which ones are and which ones aren’t is important to me.
>
>  I understand that having tagging like this does not benefit you, but does it 
> hurt you? If it doesn’t hurt you and it may help somebody else is there a 
> problem?
>
> Even outside the routing world, surface tags can be used to estimate the 
> amount of noise coming from a roadway. for example, Concrete is way louder 
> than asphalt. Such data could be used to estimate the noise pollution levels.
>
> This is very analogous to some of the attributes that one can find on 
> schools. Does the school have running water? Does the school have bathrooms? 
> None of these apply in California, but all of them apply elsewhere in the 
> world.
>
>
>
>
>> On Feb 3, 2023, at 03:25, Brian M. Sperlongano  wrote:
>>
>> 
>> I see that despite this discussion, TomTom is proceeding with its quixotic 
>> quest to get mappers to tag surface tags on motorway, just now in other 
>> countries:
>>
>> https://maproulette.org/browse/challenges/37540
>>
>> Would you care to inform the community what it is that you're trying to 
>> accomplish here?
>>
>> On Mon, Jan 30, 2023 at 12:49 PM David Salmon <>> david.sal...@tomtom.com>> 
>> > wrote:
>>
>>>
>>> Hi All,
>>>
>>>
>>>  
>>>
>>>
>>> Thank you for the discussions and pointers. I’ve disabled the challenge for 
>>> now and will re-evaluate with the team.
>>>
>>>
>>>  
>>>
>>>
>>> Much appreciated,
>>>
>>>
>>> David
>>>
>>>
>>>  
>>>
>>>
>>>
>>>
>>> From:>>>  Brian M. Sperlongano <>>> zelonew...@gmail.com>>> > 
>>>  >>> Sent:>>>  Friday, January 27, 2023 4:04 PM
>>>  >>> To:>>>  David Salmon <>>> david.sal...@tomtom.com>>> >
>>>  >>> Cc:>>>  Matthew Whilden <>>> matthew.whil...@gmail.com>>> >; Eric H. 
>>> Christensen <>>> e...@aehe.us>>> >; Joseph Eisenberg <>>> 
>>> joseph.eisenb...@gmail.com>>> >; talk-us <>>> talk...@openstreetmap.org>>> >
>>>  >>> Subject:>>>  Re: [Talk-us] New MapRoulette Challenge - Add Surface to 
>>> Highways
>>>
>>>
>>>
>>>
>>>  
>>>
>>>
>>>
>>> You don't often get email from >>> zelonew...@gmail.com>>> . >>>  Learn why 
>>> this is important 
>>>
>>>
>>>
>>> If all you care about is paved vs unpaved distinctions for routing, you can 
>>> safely delete the challenge, because all highway=motorway in California are 
>>> paved.
>>>
>>>
>>>  
>>>
>>>
>>> On Fri, Jan 27, 2023, 3:12 PM David Salmon <>>> david.sal...@tomtom.com>>> 
>>> > wrote:
>>>
>>>

 Hi All,


  


 Thank you for the questions. I checked with a couple of colleagues and 
 Surface is used in some applications if users want to avoid Unpaved roads 
 during a route.


  


 I don’t sense a consensus yet on the approach of using Paved versus a 
 specific surface value. Would you prefer that I make the challenge Not 
 Discoverable until there’s time to conclude the discussion?


  


 Alternately, if there’s a topic of higher priority or interest that you’d 
 like to see created as an editing challenge or existing challenge where 
 TomTom could support, I’m open to suggestions.


  




 All the best,
  David




  




 From:  Matthew Whilden < matthew.whil...@gmail.com > 
   Sent:  Wednesday, January 25, 2023 2:01 PM
   To:  Eric H. Christensen < e...@aehe.us >
   Cc:  Joseph Eisenberg < joseph.eisenb...@gmail.com >; 
 David Salmon < david.sal...@tomtom.com >;  
 talk...@openstreetmap.org
   Subject:  Re: [Talk-us] New MapRoulette Challenge - Add Surface 
 to Highways

Re: [Tagging] Deprecate sport=cricket_nets

[Mateusz Konieczny via Tagging]

Feb 2, 2023, 12:09 by 61sundow...@gmail.com:

>
> Again sport=soccer implies a rectangular playing field with goals  at 
> either end - that is physical infrastructure. Without the  playing field 
> and goals there cannot be a game of soccer... 
>
>
> The sport ping pong implies physical infrastructure of a table  with a 
> net, tennis implies a rectangular court with a net ... many  sports imply 
> a physical infrastructure... 
>
>
note that sport=* can be validly combined with for example shop=sports
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] foreign names for stuff, was: "Mörthe und Mosel"

[Mateusz Konieczny via Tagging]

Jan 5, 2023, 17:36 by frede...@remote.org:

> Hi,
>
> On 1/5/23 11:00, Anne- Karoline Distel wrote:
>
>> I personally found old, yet now maybe offensive names on OpenStreetMap very 
>> useful
>>
>
> Yes, this is something people occasionally quote as a reason for keeping old 
> street names as well - genealogy and other historic research. Such names 
> should always be in an old_name tag though, to avoid a multi-lingual map 
> showing them prominently.
>
sometimes with language suffix, like old_name:de
https://taginfo.openstreetmap.org/keys/old_name%3Ade#values

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

Re: [Tagging] Feature Proposal - RFC - yarn shops

[Mateusz Konieczny via Tagging]

Jan 5, 2023, 01:19 by n...@natewessel.com:

>
>  The > Polish(?)wiki page 
> >  for shop=wool does 
> seem to mention yarn and  knitting directly. 
>
>
Yes, https://wiki.openstreetmap.org/wiki/Pl:Tag:shop%3Dwool is a Polish page
(PL/Pl being commons shortcut for Poland/Polish).
"artykuły dziewiarskie" mentioned there seems to mean "knitting materials"

> Anyway, if there is consensus that `shop=wool` is an accepted tag  for a 
> store selling > yarn> , 
>
(...)

>
>
>  * shop=wool is a shop that sells yarn, even if there is no literal  wool 
> on premises
>
>
>
That seems really ugly and I would not support this (but I am not an expert at 
all on this topic).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - yarn shops

[Mateusz Konieczny via Tagging]

Jan 3, 2023, 15:16 by n...@natewessel.com:

>
> shop=wool >  ... this 
> seems like almost exactly what I'm proposing. And is used  much > more 
> frequently >  than  shop=yarn. 
>
>
> And yet for me, I never even thought to search for this. And the  word 
> 'yarn' doesn't actually appear anywhere on the page or it  would have 
> shown up in my searches of the wiki. 
>
>
Added in 
https://wiki.openstreetmap.org/w/index.php?title=Tag:shop%3Dwool=2458814=2018646

>
> It's also not referenced anywhere on the > shop=sewing 
> >  page, which 
> explicitly mentions knitting needles, etc. Nor on the > shop=fabric 
> >  nor > 
> shop=haberdashery 
> >  pages. 
>
>
Feel free to add them to "See also" section!

>
> It seems like maybe the real problem here is that the various  tags 
> related to the "fibre-arts" aren't all that well documented  yet and not 
> at all well cross-referenced. Would anyone object to  an attempt to 
> better cross-reference and distinguish these  categories? 
>
>
No, and in general feel free to add such "see also" 
(except cases like linking barely used controversial tags, but this does not 
apply here)

>
> In particular it seems to me like shop=wool should encompass  things like 
> knitting needles, and specify that it would be selling  (wool) yarn, and 
> not wool fabric as that would fall under  shop=fabric. 
>
>
> I would also want to drop references to yarn and knitting needles  from 
> shop=sewing, pointing to shop=wool for that. 
>
>
> It seems like shop=haberdashery and shop=sewing need some further  
> discussion, as they seem almost impossible to distinguish from the  wiki 
> documentation.
>
>
Note that maybe they are effectively duplicates with the same meaning in 
practice
And in such cases OSM Wiki should not pretend that there is some systematic 
difference.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - High seas

[Mateusz Konieczny via Tagging]

(1)
In general I agree but I would de-emphasize current issues in specific data 
consumers
("Areas tagged place=sea without natural=water do not render in major renderers
such as OpenMapTiles or the Standard Tile Layer.") which may be trigger for 
this 
proposal but is not a good reason for changing data design in OSM.

("Data consumers do not and cannot do X and X is important" would be a good 
reason,
"Data consumers do not do X and refused to do X for reasonable reasons" also 
would be
while "Data consumers are not doing X" is not a good reason and results in 
things
like manual data processing of bus stops in so called PTv2 which could be 
easily automated)

"The exact water boundary of an oceanic sea is inexact and not verifiable" was 
put at the
end while it is among the most serious issues (unless you intended to start 
from minor ones
and end with the most substantial?)

(2)
"Below is a listing of all beast megapolygons" can you add reference with 
explanation
how you get them? Even if it is SQL query in global osm2pgsql database which is 
not easily accessible for all then it can also be useful for some or future you 
updating
this page. And maybe someone will learn something new how to use OSM data :)

(3)
"and thus a wikidata QID should be tagged" - maybe
"and thus a wikidata QID is useful to be tagged"?
I would not imply that someone not adding wikidata is doing something 
incorrectly.

(4)
I think that for example
https://wiki.openstreetmap.org/wiki/File:Mediterranean_Americana.jpg
is missing {{ODbL OpenStreetMap}} on its file page
https://wiki.openstreetmap.org/wiki/Template:ODbL_OpenStreetMap
(disclaimer: IANAL, info based on my best current personal knowledge)

Maybe making Americana equivalent of
https://wiki.openstreetmap.org/wiki/Template:OSM_Carto_screenshot
would be nice and useful?

Also, I would recommend uploading such images to Wikimedia Commons
instead at https://commons.wikimedia.org/ .
That makes them usable for wider community and uploading images
there has much lower number of traps caused by unmaintained software
(Wikimedia Commons is a bit creaky and underfunded by WMF that prefers to
waste funds, but their image upload process is actually maintained)

Jan 2, 2023, 03:55 by zelonew...@gmail.com:

> A proposal[1] to recommend the tagging of oceanic seas as nodes rather than 
> areas is now open for comments.
>
> This proposal follows a community forum discussion[2] regarding the modeling 
> of the Gulf of Mexico as a node rather than as a crude polygon. This change 
> was made in [3]. This proposal would codify the practice of tagging seas as a 
> node as a general practice.
>
> If approved, this proposal would create a recommendation that mappers not 
> create complex "beast" mega polygons on top of the ocean (outside the 
> coastline), such as the 5,400+ member Gulf of Saint Lawrence [4], as this 
> practice is unnecessary for labeling.
>
> [1] > https://wiki.openstreetmap.org/wiki/Proposed_features/High_seas
> [2] > 
> https://community.openstreetmap.org/t/gulf-of-mexico-object-rendering-of-large-seas
> [3] > https://www.openstreetmap.org/changeset/130767988
> [4] > https://www.openstreetmap.org/relation/9428957
>
>

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

Re: [Tagging] Feature Proposal - RFC - yarn shops

[Mateusz Konieczny via Tagging]

What about shops that sell about equal amount of them and
as nonspecialist[1] I have no idea which is dominating?

Would it be reasonable to use shop=sewing sewing=yarn type of schema?

[1] I tried knitting just enough to confirm that it is not a hobby for me,
my sewing supplies do not expand beyond buttons/thread.

Jan 2, 2023, 18:14 by n...@natewessel.com:

>
> Howdy y'all, 
>
>
> I am proposing to make official a tag that is already in use to  some 
> degree, > shop=yarn> , for shops that primarily sell yarn  and other 
> knitting/crochet supplies. Currently the wiki has these  falling under 
> shop=sewing. As a long-time sewer who has recently  taken up knitting, I 
> can say with confidence that these are very  different things; though 
> sometimes larger stores will sell both. 
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/yarn_shops
>
>
> Please discuss this proposal on its Wiki Talk page.
>
>
> Thanks,
>
>
>
> Nate Wessel
>  >  Cartographer, Planner, Transport Nerd
>  >  NateWessel.com 
>
>

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

Re: [Tagging] Route names being applied to tracks/paths

[Mateusz Konieczny via Tagging]

This does not apply everywhere, even if applies in some cases.

Many trails are minor and their names are not actually names of roads/paths
where they lead even if this road/path is nameless.

In Poland even for 
https://pl.wikipedia.org/wiki/G%C5%82%C3%B3wny_Szlak_Beskidzki
it is debatable whether its name should carry to paths and for example
almost certainly not applying to
https://pl.wikipedia.org/wiki/Wschodni_Szlak_Rowerowy_Green_Velo

And clearly not happening with many minor trails.

Dec 30, 2022, 03:19 by bradha...@fastmail.com:

> +1
>  If the only name is the route name I think it makes good sense toput it 
> on the local way too, that's the name of the trail. 
>

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

Re: [Tagging] Feature Proposal - RFC - Gender

[Mateusz Konieczny via Tagging]

If we have inconsistent tagging of unisex=yes and it is unclear which
is its meaning then passing proposal does not really solve it

unisex=yes data will still have the same problem

in case of such damaged tag[1] it would be better to introduce a new one

(though if vast majority is using this tag in this way and it merely reaffirms 
it
then it is fine, but 
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Gender#Rationale
does not read this way)

[1] https://en.wikipedia.org/wiki/Skunked_term

17 gru 2022, 23:16 od illiamarchenk...@gmail.com:

> Thanks for feedback! 
>
> Marc_marc <> marc_m...@mailo.com> >:
>
>> 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>>  
>> <>> 
>> 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) ?
>>
>
>
>>
>>
> RFC isn't voting. 
>
>
>> 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)
>>
>
>
>>
>>
> This proposal isn't limited to clarification 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
>>
>
>
>>
>>
> I added  female=separate and male=separate to the proposal. 
>
>

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

Re: [Tagging] Foot / sidewalk access tagging

[Mateusz Konieczny via Tagging]

That is an irritating case.

1) with you assumptions it is possible to argue that it refers to case where
there is a separately mapped sidewalk that nevertheless is inaccessible
(some technical/escape route in a tunnel or on motorway?)

2) in practise it is far more likely to be used in case where user tags each
way with own access tags.
Basically
> that foot=* applies to "the whole of the road" including the roadway,
> shoulders, verge, sidewalks, and so forth
has added at the end
> "unless represented with separate geometry"

3) to avoid problem from (2) foot=use_sidepath was invented to mark
"yes, on carriageway you cannot walk, but you can walk on separately
mapped sidewalk"

---

practical advise:

- if there is no separately mapped footway then sidewalk=separate
is wrong and should be fixed
- if pedestrian cannot walk on carriageway and can on sidewalk
and it is separately mapped then use foot=use_sidepath instead

---

No idea:

- how to tag situation from (1) that distinguishes it from case (2)

Not sure:
- should we treat foot=no instead of foot=use_sidepath in case (2)
as invalid data

> Would folks regard that as accurate data modeling?  I.e. should I change my 
> software to treat streets tagged in this way as pedestrian-accessible, or 
> would folks regard this combination as a tagging error?
>
For start, is there a separately mapped sidewalk geometry there?
If no then tagging is invalid.
If yes, then I personally would be treating as invalid data and assume road to 
be 
pedestrian accessible, maybe flag is worth reviewing and ask users for feddback
what is going on there and ask for photo.

18 gru 2022, 21:29 od zelonew...@gmail.com:

> Hello,
>
> I am the author of a data consumer which generates a list of streets that are 
> accessible to walkers and joggers. The idea is that a user would have a map 
> of the streets in their town and can challenge themselves to walk/jog down 
> every street, and they can look at statistics on which streets they've 
> completed.  I use a 25-meter rule, so if a user can walk along the shoulder, 
> or on a sidewalk/pavement, or in the verge, that's acceptable.
>
> I recently came across an unexpected tagging combination and I would like to 
> understand how folks in various places would interpret this:
>
> highway=
> foot=no
> sidewalk=separate
>
> In my software's logic, I've made the assumption that foot=* applies to "the 
> whole of the road" including the roadway, shoulders, verge, sidewalks, and so 
> forth and thus excluded any roads that include that tag, regardless of other 
> tagging. I came to understand that this tagging was used by a mapper to 
> indicate that "pedestrians are not allowed on the roadway, however, they are 
> allowed on the sidewalk"
>
> Would folks regard that as accurate data modeling?  I.e. should I change my 
> software to treat streets tagged in this way as pedestrian-accessible, or 
> would folks regard this combination as a tagging error?
>
>
>

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

Re: [Tagging] Foot / sidewalk access tagging

[Mateusz Konieczny via Tagging]

18 gru 2022, 23:27 od graemefi...@gmail.com:

> It would be much nicer to drop the sidewalk=separate from the road, & draw a 
> separate footway, which would fix everything!
>
note that sidewalk=separate is used to indicate that separately mapped 
sidewalk(s)
is/are mapped.

Not sure why you propose to delete it in such case.

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

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

[Mateusz Konieczny via Tagging]

17 gru 2022, 01:19 od graemefi...@gmail.com:

>
>
> On Fri, 16 Dec 2022 at 17:55, Marc_marc <> marc_m...@mailo.com> > wrote:
>
>> Le 16.12.22 à 08:30, Mateusz Konieczny via Tagging a écrit :
>>
>>  > 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
>>
>
> Yes, that is how they are being used, but the tag is being completed with the 
> name & details of the lifeboat itself, which, to me at least, infers that 
> this boat is always at this spot, & it isn't.
>
> The other issue with the currently mapped info is that most of it appears to 
> have come from an unauthorised source.
>
Can you link problematic changeset? (if there is import from invalid source 
then 
contacting DWG is a good idea. Also, I hope that I am not writing this
to DWG member again)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] de facto -Status not working?

[Mateusz Konieczny via Tagging]

Can you link any of pages where it is happening?

For example https://wiki.openstreetmap.org/wiki/Key:taxi_type
seems to work fine with it (though it seems dubious to have tag used 156 times 
as
"de facto")

16 gru 2022, 13:29 od dieterdre...@gmail.com:

> It seems that for some reason "de facto" is not recognized as value in the 
> templates any more? 
>
> Cheers,
> Martin
>

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

Re: [Tagging] Homogenize diplomatic tags

[Mateusz Konieczny via Tagging]

15 gru 2022, 20:55 od ajt1...@gmail.com:

>
> > Deal? 
>
>
> No.  
>
>
> You appeared to have ignored the advice that you were given and  gone 
> ahead and performed a mechanical edit anyway.
>
> (...)
>
> However - nothing whatsoever about the others.  You didn't bother  to 
> wait for a reply to the message below, you (and > 
> https://www.openstreetmap.org/user/zorglubu>  , who actually created  the 
> maproulette automated edit challenges***) just went ahead and  did the 
> changes anyway.
>
>
> (...)
>
> Clearly "replace tag X with tag Y" IS a just mechanical edit.
>
If this edit was in violation of 
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
then I would recommend notifying DWG
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

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

>
> On Fri, 16 Dec 2022 at 10:59, Andy Townsend <> 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 (it may or may be confusing enough that new tag us useful).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] plantation=yes?

[Mateusz Konieczny via Tagging]

10 gru 2022, 19:23 od mark+...@carnildo.com:

> On Sat, 10 Dec 2022 18:49:00 +0100
> Florian Lohoff  wrote:
>
>> On Sat, Dec 10, 2022 at 01:10:33PM +, Dave F via Tagging wrote:
>> > Hi
>> > 
>> > What does plantation=yes represent?
>> > Associated with woods, but nothing in the wiki. 2437  uses
>> > worldwide. Seems too vague to be OSM useful. 
>>
>> Interesting - I would say natural=wood + plantation=yes is more likely
>> landuse=forest isnt it? 
>>
>> At least for me natural=wood is a non artifical forest, but those are
>> pretty rare at least around where i live. All of the forest has been 
>> chopped down at least a hundret times since mankind arrived in Europe.
>>
>
> As actually used on the map, "natural=wood" and "landuse=forest" are
> synonyms.
>
See https://wiki.openstreetmap.org/wiki/Forest for gory details

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

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

[Mateusz Konieczny via Tagging]

2 gru 2022, 20:50 od m...@nguyen.cincinnati.oh.us:

> Vào lúc 08:44 2022-12-02, Mateusz Konieczny via Tagging đã viết:
>
>> I have good news! There is preprocessing solution for large (nearly all?) 
>> simple cases,
>> written in Kotlin and is a part of StreetComplete.
>>
>> StreetComplete would be able to handle cases listed in its sidewalk detection
>> (used to skip sidewalk/cycleway quests in presence of nearby separately 
>> mapped sidewalk
>> - note that in new versions this quests are disabled by default as overlays
>> are intended to replace them)
>>
>> You can test how it works by finding place where roads have no sidewalk=* 
>> tags
>> and there are separately mapped sidewalks, navigate there in StreetComplete 
>> and
>> disable all quests except sidewalk/cycleway.
>>
>> You will get them on matching roads - except ones with detected nearby 
>> sidewalks.
>> You can also tweak filter rules to enable sidewalk and cycleway quest for 
>> all roads
>> to skip tag based filtering (which skips some roads unlikely to have 
>> cycleways
>> or sidewalks or already tagged with sidewalk* and cycleway* tags)
>>
>> This code would handle with slight modifications vast majority of cases.
>> Simplest one would be enlarging default buffer and other parameters.
>> Possible changes include taking into account cycleway*=separate tags and
>> sidewalk*=separate tags to search for larger distance if sidewalk was not 
>> found
>> and other obvious tweaks - all examples listed here would be handled.
>>
>
> Are you referring to this code? [1] A running time of O(n^3) is not 
> necessarily something others would consider a solution. Imagine a router 
> running this algorithm over a whole continent or planet when building the 
> routing graph. Yet it's also too sensitive to where a way happens to be 
> split. Either the footway or the roadway could be split at arbitrary points 
> for arbitrary reasons or no reason at all.
>
Yes, it is just a proof that it is at least partially doable - not something 
readily usable
for planet processing.
Still, makes me really dubious about applying this tagging everywhere - 
especially
if people applying it expect people editing highway tags or name tags or ref 
tags
to maintain this new tags.

> A more general algorithmic solution may be feasible, but it would probably 
> look much more like Skeletron [2], which conflates dual carriageways, or the 
> map matching algorithms in various routing engines, which are normally used 
> to align GPS traces to the road network. These approaches are overkill for 
> StreetComplete but may be a good fit for a routing engine. The edge cases in 
> [3] would require walking the routing graph to some extent. This is something 
> the Overpass API was originally designed to do, so it isn't inconcievable, 
> but it isn't purely a trigonometric problem.
>
+1

>> Yes, it will take some effort to write or adapt this code. But this proposal 
>> asks
>> mappers to manually preprocess millions of sidewalk sections.
>> Just currently marked footway=sidewalk (small part of all separately mapped 
>> sidewalks)
>> have 3 300 000+ sections.
>> Lets take optimistic 5s per section, initial tagging that alone would consume
>> 4695 hours of mapping (and also software costs to allow such efficient 
>> mapping!).
>> And likely 5s per way is very optimistic.
>> Add to that all separately mapped sidewalks without footway=sidewalk.
>>
>
> For what it's worth, this would be a similar scope of work as adding name=* 
> to each of the sidewalk ways, just as with dual carriageways. Mappers in some 
> cities are already systematically adding name=* to sidewalk ways, but it 
> hasn't really caught on globally, maybe because of how it clutters a typical 
> map. (But a renderer could simply avoid labeling footway=sidewalk.)
>
I would be also against this tagging style for similar reasons. Though at least 
it has
lower duplication and reclassifying highway=* way (not an unusual activity!)
is not resulting in pointless drudgery.

> Inevitably, there will be unhandled edge cases regardless of the algorithm. 
> Maybe a compromise would be to treat is_sidepath:of=* as an override for 
> difficult cases only, similar to name:pronunciation=*. The benefit over 
> name=* is that nothing changes for a renderer unless they opt into processing 
> the new key.
>
That would work for me - but this difficult cases should be identified.
I expect that relations may be needed for some, and this proposed tags will not
be sufficient in especially pathological ones (for example where road splits in 
multiple
named in the same way).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

[Mateusz Konieczny via Tagging]

2 gru 2022, 16:54 od o...@tobias-knerr.de:

> On 02.12.22 15:02 Mateusz Konieczny wrote:
>
>> Or is it justifiable because it is outright impossible to do reliably
>> with automatic preprocessing?
>>
>
> I would say that's the reason. Of course, it's hard to prove that something 
> is impossible. But so far no one has built a working solution for inferring 
> this information where it isn't explicitly mapped.
>
>> If yes, can you give examples where it would be beneficial
>> and explicitly ask to introduce such tagging solely in
>> cases where preprocessing is doomed to fail?
>>
>
> Given the current lack of working preprocessing solutions for even the easier 
> situations you've linked to, I'm not sure it's easy to tell where the 
> dividing between "solvable" and "unsolvable" is. It would also have to be 
> defined and explained in such a manner that mappers (and editing tools like 
> StreetComplete who might some day ask users to fill this in) can easily 
> understand where it is or isn't needed.
>
I have good news! There is preprocessing solution for large (nearly all?) 
simple cases,
written in Kotlin and is a part of StreetComplete.

StreetComplete would be able to handle cases listed in its sidewalk detection
(used to skip sidewalk/cycleway quests in presence of nearby separately mapped 
sidewalk
- note that in new versions this quests are disabled by default as overlays
are intended to replace them)

You can test how it works by finding place where roads have no sidewalk=* tags
and there are separately mapped sidewalks, navigate there in StreetComplete and
disable all quests except sidewalk/cycleway.

You will get them on matching roads - except ones with detected nearby 
sidewalks.
You can also tweak filter rules to enable sidewalk and cycleway quest for all 
roads
to skip tag based filtering (which skips some roads unlikely to have cycleways
or sidewalks or already tagged with sidewalk* and cycleway* tags)

This code would handle with slight modifications vast majority of cases.
Simplest one would be enlarging default buffer and other parameters.
Possible changes include taking into account cycleway*=separate tags and 
sidewalk*=separate tags to search for larger distance if sidewalk was not found
and other obvious tweaks - all examples listed here would be handled.

Yes, it will take some effort to write or adapt this code. But this proposal 
asks
mappers to manually preprocess millions of sidewalk sections.
Just currently marked footway=sidewalk (small part of all separately mapped 
sidewalks)
have 3 300 000+ sections.
Lets take optimistic 5s per section, initial tagging that alone would consume
4695 hours of mapping (and also software costs to allow such efficient 
mapping!).
And likely 5s per way is very optimistic.
Add to that all separately mapped sidewalks without footway=sidewalk.

And that is a small part. The worst part is that any time you update
highway=* value or name or ref there is an added drudgery to update this
on sidewalks.


>> If it is second case of preprocessing being impossible -
>> why do massive duplication and ask to duplicate ref value
>> AND name value AND highway value?
>>
>
> The duplication-free solution of referencing the road's way ID as 
> is_sidepath:of = w4087515 is going meet some resistance from people pointing 
> out the need for, and current lack of, editor support to make such values 
> usable.
>
> (Not from me, though, I'd love that approach and have dozens of ideas for 
> other places where it would be helpful. :))
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Tagging] Feature Proposal - RFC - "is_sidepath" as a sidepath concept

[Mateusz Konieczny via Tagging]

"or only with the significant effort of using geometric  processing
(which most applications can't perform)"

why doing it manually would be preferable?

Is it repeating mistake of adding pointless work for mappers
because it "causes extra preprocessing for routing software."?
And valuing time of mappers as worth nothing?
(PTv2 asks mappers to do something derivable from highway=bus_stop
location and roads within bus relation, massive amount of work
of mappers wasted to do preprocessing manually
https://wiki.openstreetmap.org/w/index.php?oldid=625726 )

Why https://www.openstreetmap.org/way/24034881
needs to be preprocessed manually?
The same for https://www.openstreetmap.org/way/788729
https://www.openstreetmap.org/way/118390194
https://www.openstreetmap.org/way/233305340 
https://www.openstreetmap.org/way/119380508
(all examples from the proposal)

Or is it justifiable because it is outright impossible to do reliably
with automatic preprocessing?
(that is the justification for
https://wiki.openstreetmap.org/wiki/Tag:dual_carriageway%3Dyes
)
If yes, can you give examples where it would be beneficial
and explicitly ask to introduce such tagging solely in
cases where preprocessing is doomed to fail?

If it is second case of preprocessing being impossible -
why do massive duplication and ask to duplicate ref value 
AND name value AND highway value?



Also, I think that
https://www.openstreetmap.org/way/119380508 is clearly a sidewalk
of that road.

2 gru 2022, 13:31 od supap...@riseup.net:

>
>
> Paths and ways along a road can be mapped separately in OSM, but  those 
> separate geometries cannot be identified as part of the  road, or only 
> with the significant effort of using geometric  processing (which most 
> applications can't perform). However, the  information whether a path is 
> attendant to a road or not is  important for many use cases and can offer 
> various advantages.
>  
>  Therefore, a sidepath concept using the tag "is_sidepath" as an  
> additional tag on ways (in particular cycle ways or foot paths) is  
> proposed to indicate whether a way is related/attendant to a road  (i.e. 
> adjacent and parallel to a road) or whether it runs  
> independently/isolated without any relationship to a road.  Furthermore, 
> an extended set of sub-tags is proposed to allow to  explicitly tag 
> important road attributes on the sidepath itself.
>  
>  > https://wiki.openstreetmap.org/wiki/Proposed_features/Key:is_sidepath
>  
>  You can discuss this proposal on its Wiki Talk page or here.
>
>
>
> Best, Alex
>
>

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

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

[Mateusz Konieczny via Tagging]

30 lis 2022, 14:02 od dieterdre...@gmail.com:

> Am Mi., 30. Nov. 2022 um 01:10 Uhr schrieb Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> >:
>
>>
>>
>> 29 lis 2022, 22:55 od >> dieterdre...@gmail.com>> :
>>
>>>
>>>
>>> sent from a phone
>>>
>>>> On 29 Nov 2022, at 09:02, Mateusz Konieczny via Tagging <>>>> 
>>>> tagging@openstreetmap.org>>>> > wrote:
>>>>
>>>> "no traffic signals" applies also only in some jurisdictions
>>>>
>>>
>>>
>>> If there are traffic signals the crossing in OpenStreetMap gets tagged 
>>> crossing=traffic_signals, this is regardless of jurisdiction AFAIK.
>>>
>> there are >38k crossing_ref=zebra in Poland
>> https://overpass-turbo.eu/s/1onT
>>
>
>
> yes, also here, I already wrote that the "crossing_ref" tag is about crossing 
> markings and not about typology (around here, I know that the wiki may not be 
> so clear on this). The "no traffic signals" was referring to crossing=zebra, 
> not crossing_ref
>

also 19k+ crossing=zebra, see https://overpass-turbo.eu/s/1orm
example of one with traffic lights: 
https://www.openstreetmap.org/node/3586404853
(and not tagged with anything directly indicating that)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

[Mateusz Konieczny via Tagging]

29 lis 2022, 22:55 od dieterdre...@gmail.com:

>
>
> sent from a phone
>
>> On 29 Nov 2022, at 09:02, Mateusz Konieczny via Tagging 
>>  wrote:
>>
>> "no traffic signals" applies also only in some jurisdictions
>>
>
>
> If there are traffic signals the crossing in OpenStreetMap gets tagged 
> crossing=traffic_signals, this is regardless of jurisdiction AFAIK.
>
there are >38k crossing_ref=zebra in Poland
https://overpass-turbo.eu/s/1onT

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

Re: [Tagging] Feature Proposal - RFC - Crossing cleanup and deprecation

[Mateusz Konieczny via Tagging]

29 lis 2022, 00:18 od dieterdre...@gmail.com:

> Crossing=zebra is about a zebra crossing, it implies also vertical signs- in 
> some jurisdictions and some conditions at least - and it implies that there 
> aren’t traffic signals. 
>
"no traffic signals" applies also only in some jurisdictions
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny via Tagging]

Mapping standard location of lifeboat mooring or
lifeboat station location seems entirely fine.

(I am person who added this claim to wiki
https://wiki.openstreetmap.org/w/index.php?title=Tag:building%3Dhouseboat=1931553=1797928
)

27 lis 2022, 02:03 od graemefi...@gmail.com:

> In regard to mapping the location of a lifeboat, just noticed this: > 
> https://www.openstreetmap.org/edit?node=6952187784#map=19/53.09914/5.94569
>
> & the wiki for houseboats > 
> https://wiki.openstreetmap.org/wiki/Tag:building=houseboat> , states 
> "Houseboats that are moving are not mappable in OSM".
>
> I think the same would apply to lifeboats, except even more so!
>
> Thanks
>
> Graeme
>
>
>
>

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

Re: [Tagging] species:language to loc_name:language

[Mateusz Konieczny via Tagging]

Not sure how change proposed in the second paragraph solves what
you mentioned in the first.

It also goes against established meaning of loc_name

loc_name:en is for English local name of a tree, not for English name of its 
species
(this is rarely used as local names are rarely in multiple languages, but
there is no benefit from breaking this definition and mostly
systematic tag variants for names)


21 lis 2022, 17:22 od erielk...@gmail.com:

> In a lot of cases, users are using local names in the values for species and 
> genus keys.
> This is an error as genus and species only exist in latin. For local/vulgar 
> name users should use another key or be obtained using the wikidata 
> information. 
>
> I suggest changing species:language to > l 
> > oc_name:language as for 
> the same species there exists a huge variability of common names, not only 
> differing by language.
>
> Wiki for species:wikidata: > Key:species:wikidata - OpenStreetMap Wiki 
> 
> Wiki for species: > Key:species - OpenStreetMap Wiki 
> 
> Use of the key species: > Resultados de la búsqueda | OpenStreetMap Taginfo 
> 
>

___
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

[Mateusz Konieczny via Tagging]

20 lis 2022, 17:06 od dieterdre...@gmail.com:

>
>
> sent from a phone
>
>> On 20 Nov 2022, at 02:27, Matija Nalis  
>> wrote:
>>
>> Because, someone has to do that summarizing work for extra channels to make 
>> sense, and it is IMHO only fair that would
>> be proposal author (expecting that EVERYBODY will do that SAME task is both 
>> extremely wasteful, hugely unrealistic,
>> and likely to lead to few participating members willing to do that becoming 
>> burned out prematurely).
>>
>
>
> the first and foremost reason for the tagging mailing list to exist was the 
> desire to offload tagging discussions on a central place, off the other 
> channels, because people there felt overwhelmed with the discussions needed 
> to agree on tags to describe the whole world, and it seemed helpful to reduce 
> the volume on the talk list to a size that can be followed with significantly 
> less dedication of time. Moving back to discussing tagging everywhere will 
> make these other channels less useful for some people, I guess. Maybe this is 
> unfounded because it came out, tagging is relevant all over OpenStreetMap 
> (i.e. tagging discussions already happen on all channels, lately even on 
> osmf-talk) and you can hardly ignore it, and because the structure of the 
> contributors has changed, or something like this.
>
The new forum may be also more capable of handling large volume of posts - you 
can
easily mute threads and entire categories.

As result massive posting in one thread is easier to ignore in its entirety.

This is in theory achievable with filtering and so on, but much harder to apply 
in
practice, with mailing lists.

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

Re: [Tagging] amentiy=donation_centre?

[Mateusz Konieczny via Tagging]

that is for place giving clothes, not collecting them

it does not mean that they collect them
(and even with place collecting and giving located at the same place
they may have separate opening hours or other detail)


Nov 14, 2022, 13:59 by antoniomade...@gmx.com:

> It seems good.
>  It even has a subtag > social_facility 
> > => clothing_bank 
> 
>  
>  
>  
> Às 11:41 de 14/11/2022, Martin  Koppenhoefer escreveu:
>
>> maybe these can be seen 
>> asamenity=social_facility?___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] Relations of type=site + tourism=camp_site

[Mateusz Konieczny via Tagging]

Nov 12, 2022, 14:22 by li...@fuchsschwanzdomain.de:

> Mateusz Konieczny via Tagging  wrote:
>
>> So
>> https://www.openstreetmap.org/relation/13012999#map=19/49.12702/10.86422
>> site relation is including nearby restaurant and shop?
>>
>
> Right!
>
>> That are not actually part of camp site?
>>
>
> Wellm, they are not part of it geographicaly because the are located outside 
> the
> actual campground but they are part of it in organizational terms.
>
In which sense? Are they operated by camp site?

Or is it just "place where many people from camp site are using"?
In such case - what is stopping people from adding also
https://www.openstreetmap.org/node/534602086 parking and 
https://www.openstreetmap.org/node/534372433 post box and
https://www.openstreetmap.org/way/615814536 beach and 
https://www.openstreetmap.org/way/37585648 lake and
https://www.openstreetmap.org/node/4703294282 train stop?

>
> Is this that hard to understand?
>
>> And just included there to manually do processing part of finding nearby
>> shops/restaurants?
>>
>
> Wrong. They are not only nearby somethings but as I wrote above are parte of
> the site in organizational terms.
>
see above

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

Re: [Tagging] Relations of type=site + tourism=camp_site

[Mateusz Konieczny via Tagging]

Nov 10, 2022, 21:49 by li...@fuchsschwanzdomain.de:

> Yves via Tagging  wrote:
>
>> Site relations are often used to models thing that aren't spatially
>> joined, like windfarms, universities...  I can easily imagine it's
>> reasonable to use them for campings in some corner cases where a single
>> area doesn't work.
>>
>
> Yes, let me clarify this with an example:
>
> E.g. This site has a working site relation (without tourism=camp_site 
> removed):
>
> https://opencampingmap.org/#15/49.0815/7.9123/1/1/bef/node/3824691120
>
> The camp_site node is https://www.openstreetmap.org/node/3824691120
> Site relation is https://www.openstreetmap.org/relation/13009876
>
> While it is currently tagged toilets=yes and openfire=yes this is not
> mandatory because evaluating the corresponding site relation will give us a
> toilet and a fireplace.
>
> So what I do with site relations here is basically the same I do with
> camp_site areas.  With areas I check if any supported object is inside the
> area (spatial join) and assume that this is a feature of this particular
> camp_site.
>
> With site-relations this is even easier as I can consider all objects
> related to the site a feature of the camp-site in the relation.
>
> I think this is elegant especially in comparison to the alternatives
> suggested here like expanding the campsite polygon into areas open to the
> general public like reception desks, restaurants or even toilets also used
> by other facilities like sport-centers.
>
obviously camp site should not be fakely expanded to cover nearby 
restaurants

what about automatically detecting nearby restaurants/toilets and so on?
rater than listing them manually with site relation (optionally, check 
operator tag - that would apply only in cases where there are multiple
camp sites or other objects each with access=customers objects)

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

Re: [Tagging] Relations of type=site + tourism=camp_site

[Mateusz Konieczny via Tagging]

Nov 10, 2022, 21:21 by li...@fuchsschwanzdomain.de:

> Marc_marc  wrote:
>
>> taking one random exemple :
>> https://www.openstreetmap.org/relation/13012999#map=19/49.12702/10.86422
>> according to the parking name=*, the parking may be include in the 
>> tourism=site_camp
>>
>
> Yes but this is simply not as it is on the ground. The parking is not _part_
> of the camp-site but for visitors as well as the restaurant and shop. They
> are not stritly cusomers only like the enclosed area.
>
>> if someone think that the restaurant and the shop are also part of the 
>> camp site, then it's easy to extend the area to include those.
>>
>
> Which is just plain wrong as they are not _only_.
>
So
https://www.openstreetmap.org/relation/13012999#map=19/49.12702/10.86422
site relation is including nearby restaurant and shop?

That are not actually part of camp site?

And just included there to manually do processing part of finding nearby
shops/restaurants?

In which way this shop/restaurant is part of being camp site except of being 
nearby?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Relations of type=site + tourism=camp_site

[Mateusz Konieczny via Tagging]

Yes, using site relation in addition to actual object breaks this rule
and it is undesirable (and site relations in general are problematic).

It would be also problem with type=site site=camp_sites and similar
trying to hide duplication.

Is there some reason why this camp sites cannot be mapped as areas
if someone is doing such detailed mapping?

or map operator of a toilet or extra features?


Nov 9, 2022, 22:00 by li...@fuchsschwanzdomain.de:

> Hello,
>
> about a year ago I implemented support for site relations in OpenCampingMap.
>
> My announcement from back then is at:
> https://blog.geggus.net/2021/09/announcing-support-for-site-relations-in-opencampingmap/
>
> Now a recent changeset discussion is questioning my whole approach because it
> arguably violates the "One feature, one OSM element principle":
>
> https://www.openstreetmap.org/changeset/126035627
>
> Ignoring the principle (which is not absolute anyway) in this case and
> adding a relation of type=site + tourism=camp_site containing the actual
> tourism=camp_site object as a member does solve the problem thus I would go
> for doing just this as I did a year ago.
>
> Obviously others seem to differ here.
>
> Currently the above changeset breaks my map regarding those campsites where
> the tourism=camp_site tag has been removed from the site relation.
>
> External features are no longer shown :(
>
> So how to resolve this problem?
>
> campsites with external features (e.g.  sanitary facilities used by a
> campsite and a sport-center) do exist in the wild and they usually do also
> have on-the-ground objects (way, node, polygon-relation) where no other tag
> than tourism=camp_site does make sense.
>
> What do you think?
>
> Sven
>
> ___
> 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] Possible merge of marine_rescue & lifeboat_station tags?

[Mateusz Konieczny via Tagging]

I think so?


Nov 9, 2022, 07:45 by graemefi...@gmail.com:

> Thanks!
>
> Once again, would =lifeboat_station cover them?
>
> Thanks
>
> Graeme
>
>
> On Wed, 9 Nov 2022 at 16:38, Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> > wrote:
>
>> Fixed link on it.
>>
>> By looking at >> https://mopr.com.pl/stacje-i-ratownicy/>>  there are two 
>> that are definitely
>> serious inland ones, maybe four of them among operated by MOPR.
>>
>> And yes, there are only few of them - but still, ideally they would be 
>> covered
>> by nonconfusing tagging (none of "=marine_rescue redefined to not be marine")
>>
>> And I expect that other countries with major freshwater lakes and major 
>> rivers
>> also have them already or will have them in future.
>>
>> Nov 9, 2022, 01:38 by >> graemefi...@gmail.com>> :
>>
>>> Thanks, but are they usually found inland?
>>>
>>> I found a few rescue / lifeboat stations along the Polish coast, but only 
>>> one mapped inland, which either doesn't exist anymore, or it's website has 
>>> changed?
>>>
>>> https://www.openstreetmap.org/way/254564700
>>>
>>> https://mopr.com.pl/1-nasza-stacja/stacje-i-ratownicy-gizycko-galeria-stacji.html
>>>
>>> (Either that, or the previous mapper made a mistake! :-))
>>>
>>> Thanks
>>>
>>> Graeme
>>>
>>>
>>> On Wed, 9 Nov 2022 at 09:37, Mateusz Konieczny via Tagging <>>> 
>>> tagging@openstreetmap.org>>> > wrote:
>>>
>>>>
>>>>
>>>>
>>>> Nov 9, 2022, 00:19 by >>>> graemefi...@gmail.com>>>> :
>>>>
>>>>> Looking at some of the "inland" examples shown on OT, I wonder if they 
>>>>> should actually be tagged as a "lifeboat-station" at all, or whether they 
>>>>> would be better shown as a lifeguard base?
>>>>>
>>>> MOPR and MOPR Giżycko station specifically for example has proper boats:
>>>>
>>>> https://mopr.com.pl/sprzet/>>>>  lists what MOPR operates
>>>>
>>>> https://www.google.com/maps/uv?pb=!1s0x46e188778f5ccdbb%3A0x59ce788583f65b5a!3m1!7e115!4shttps%3A%2F%2Flh5.googleusercontent.com%2Fp%2FAF1QipPer7fMBHgyY5wg8EFphzvbrhgS-pl2WK4Exnc%3Dw213-h160-k-no!5sMOPR%20Gi%C5%BCycko%20-%20Google%20Search!15sCgIgAQ=!1e10!2sAF1QipPer7fMBHgyY5wg8EFphzvbrhgS-pl2WK4Exnc=en=X=2ahUKEwjcgO7d3p_7AhUxXvEDHdiDBj0Qoip6BQi9ARAD
>>>>
>>>> https://mopr.com.pl/stacje-i-ratownicy/
>>>>
>>>>
>>>> ___
>>>> Tagging mailing list
>>>> Tagging@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>
>>
>> ___
>>  Tagging mailing list
>>  >> Tagging@openstreetmap.org
>>  >> https://lists.openstreetmap.org/listinfo/tagging
>>___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Possible merge of marine_rescue & lifeboat_station tags?

[Mateusz Konieczny via Tagging]

Fixed link on it.

By looking at https://mopr.com.pl/stacje-i-ratownicy/ there are two that are 
definitely
serious inland ones, maybe four of them among operated by MOPR.

And yes, there are only few of them - but still, ideally they would be covered
by nonconfusing tagging (none of "=marine_rescue redefined to not be marine")

And I expect that other countries with major freshwater lakes and major rivers
also have them already or will have them in future.

Nov 9, 2022, 01:38 by graemefi...@gmail.com:

> Thanks, but are they usually found inland?
>
> I found a few rescue / lifeboat stations along the Polish coast, but only one 
> mapped inland, which either doesn't exist anymore, or it's website has 
> changed?
>
> https://www.openstreetmap.org/way/254564700
>
> https://mopr.com.pl/1-nasza-stacja/stacje-i-ratownicy-gizycko-galeria-stacji.html
>
> (Either that, or the previous mapper made a mistake! :-))
>
> Thanks
>
> Graeme
>
>
> On Wed, 9 Nov 2022 at 09:37, Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> > wrote:
>
>>
>>
>>
>> Nov 9, 2022, 00:19 by >> graemefi...@gmail.com>> :
>>
>>> Looking at some of the "inland" examples shown on OT, I wonder if they 
>>> should actually be tagged as a "lifeboat-station" at all, or whether they 
>>> would be better shown as a lifeguard base?
>>>
>> MOPR and MOPR Giżycko station specifically for example has proper boats:
>>
>> https://mopr.com.pl/sprzet/>>  lists what MOPR operates
>>
>> https://www.google.com/maps/uv?pb=!1s0x46e188778f5ccdbb%3A0x59ce788583f65b5a!3m1!7e115!4shttps%3A%2F%2Flh5.googleusercontent.com%2Fp%2FAF1QipPer7fMBHgyY5wg8EFphzvbrhgS-pl2WK4Exnc%3Dw213-h160-k-no!5sMOPR%20Gi%C5%BCycko%20-%20Google%20Search!15sCgIgAQ=!1e10!2sAF1QipPer7fMBHgyY5wg8EFphzvbrhgS-pl2WK4Exnc=en=X=2ahUKEwjcgO7d3p_7AhUxXvEDHdiDBj0Qoip6BQi9ARAD
>>
>> https://mopr.com.pl/stacje-i-ratownicy/
>>
>>
>> ___
>>  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] Possible merge of marine_rescue & lifeboat_station tags?

[Mateusz Konieczny via Tagging]

Nov 9, 2022, 00:19 by graemefi...@gmail.com:

> Looking at some of the "inland" examples shown on OT, I wonder if they should 
> actually be tagged as a "lifeboat-station" at all, or whether they would be 
> better shown as a lifeguard base?
>
MOPR and MOPR Giżycko station specifically for example has proper boats:

https://mopr.com.pl/sprzet/ lists what MOPR operates

https://www.google.com/maps/uv?pb=!1s0x46e188778f5ccdbb%3A0x59ce788583f65b5a!3m1!7e115!4shttps%3A%2F%2Flh5.googleusercontent.com%2Fp%2FAF1QipPer7fMBHgyY5wg8EFphzvbrhgS-pl2WK4Exnc%3Dw213-h160-k-no!5sMOPR%20Gi%C5%BCycko%20-%20Google%20Search!15sCgIgAQ=!1e10!2sAF1QipPer7fMBHgyY5wg8EFphzvbrhgS-pl2WK4Exnc=en=X=2ahUKEwjcgO7d3p_7AhUxXvEDHdiDBj0Qoip6BQi9ARAD

https://mopr.com.pl/stacje-i-ratownicy/


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

Re: [Tagging] Feature Proposal - RFC - Street vendors

[Mateusz Konieczny via Tagging]

There are also places with someone operating shop from their truck.

They would travel on assigned times through valleys and stop in from of each 
house.

They would sell (at very slight markup) products, allowing people to travel 
just 50m-200m
from their house rather than getting kilometres to shop in the village center.

In both cases I would be dubious about mapping their presence as it is 
extremely short
(and mapping such selling location in front of every single house in valleys 
would
be quite silly and misleading, I think)


Nov 7, 2022, 22:58 by graemefi...@gmail.com:

> Another version of sort of a street-vendor that I was wondering about is 
> mobile food vans.
>
> They drive into a site (building site, warehouse complex etc) at morning tea 
> time, blow their horn, stay for 15-20 minutes, then leave & come back at 
> lunch time.
>
> Are they a street vendor?
>
> Thanks
>
> Graeme
>
>
> On Tue, 8 Nov 2022 at 05:57, Volker Schmidt <> vosc...@gmail.com> > wrote:
>
>> Just to make the list complete:
>> Around here (or at least in my city and nearby towns) we have regular open 
>> air markets with assigned locations for specific stalls.
>> Do we already have a mapping approach to that type of stalls? (I couldn't 
>> find one).
>> If we really don't have one already, it might be worth looking at how to map 
>> stalls in general as I cudl see a lot of similarities.  
>> I do part of my shopping in such markets, and I go to specific stalls for 
>> specific goods.
>>
>> Il giorno lun 7 nov 2022 alle ore 17:03 Joseph Eisenberg <>> 
>> joseph.eisenb...@gmail.com>> > ha scritto:
>>
>>> I disagree with classing if all “street vendors” and one feature.
>>>
>>> This proposal seems to assume conditions in contemporary Europe, where 
>>> shops are usually located in permanent buildings due to climate conditions.
>>>
>>> In many subtropical and tropical regions the air temperature is never cold, 
>>> so a fully enclosed permanent building with walls and heating is not very 
>>> necessary.
>>>
>>> In this case many “street vendors” will have a tent and some storage which 
>>> stays at a certain place, but is closed up at night. In that regards it is 
>>> similar to a shop which is closed up with a metal gate at night, making it 
>>> poorly visible except during opening hours.
>>>
>>> But consider shop=kiosk - in North America these are often small stands on 
>>> a sidewalk of pedestrian street or mall, with one person wgo sells 
>>> newspapers, snacks etc to pedestrians, functioning quite like a common kind 
>>> of street vendor, except that they are in a tiny shed. Is it really better 
>>> to have a totally different way of tagging a similar business which instead 
>>> uses a mobile push-cart or a tricycle instead?
>>>
>>> In Southeast Asia, many of the businesses that Westerners might call street 
>>> vendors sell newly cooked food, thus they are more like amenity=fast_food - 
>>> and often an enclosed eatery will have only the kitchen indoors, with 
>>> customers eating outside under a canopy.
>>>
>>> Even here in Oregon, in the United States, we have small restaurants which 
>>> are ambiguous under this proposal: they are “food carts” because they are 
>>> small kitchens in trailers with wheels, which can be moved by attaching 
>>> them to a truck. But usually they are semi-permanently installed on rented 
>>> private land, with the landowner providing hook-ups for electricity and 
>>> water, and usually covered seating with a canopy and picnic tables. So 
>>> while they look similar to at more mobile “food truck” (which has its own 
>>> engine and drivers seat, and thus can be moved every day) they are more 
>>> permanent.
>>>
>>> Rather than approving this proposal I would recommend more use of property 
>>> tags. The existing street_vendor=yes tag is probably best, but building=no 
>>> is also common (10k uses) and makes it clear that a feature is not a 
>>> building. 
>>> https://taginfo.openstreetmap.org/tags/building=no
>>>
>>> - Joseph Eisenberg
>>>
>>>
>>>
>>> On Sun, Nov 6, 2022 at 9:31 PM >>> map...@t-online.de>>>  <>>> 
>>> map...@t-online.de>>> > wrote:
>>>

 Hi all,


  


 I  propose to deprecate street_vendor=* and to tag mappable street 
 vendors with amenity=street_vendor + vending=* + opening_hours=* instead.





 https://wiki.openstreetmap.org/wiki/Proposed_features/Street_vendors





 Please discuss this proposal on its Wiki Talk page.


  


 Cheers,


  


 Freetz


  




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

>>> ___
>>>  Tagging mailing list
>>>  >>> Tagging@openstreetmap.org
>>>  >>> 

Re: [Tagging] Possible merge of marine_rescue & lifeboat_station tags?

[Mateusz Konieczny via Tagging]

Nov 7, 2022, 23:05 by graemefi...@gmail.com:

>
>
> On Mon, 7 Nov 2022 at 20:03, Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> > wrote:
>
>>>
>>>
>>
>> What about such stations on freshwater lakes and on rivers? Is "marine" 
>> fitting there?
>>
>
> That one's easily covered by definition, as in the original marine-rescue 
> proposal:
>
> "the base areas or buildings of groups, sometimes Government operated, but 
> also frequently volunteer only, dedicated to the rescue of vessels / sailors 
> in distress, usually in Open or Coastal waters, but also possibly in inland 
> waters. They may also be involved in rescue operations on coastal cliffs, mud 
> flats etc."
>
Having tag name that clearly excludes freshwater water rescue and changing it
in description is highly confusing and I would prefer to avoid it if at all 
possible.

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

Re: [Tagging] Feature Proposal - RFC - Street vendors

[Mateusz Konieczny via Tagging]

Nov 7, 2022, 23:43 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>> On 7 Nov 2022, at 20:57, Volker Schmidt  wrote:
>>
>> If we really don't have one already, it might be worth looking at how to map 
>> stalls in general as I cudl see a lot of similarities.
>>
>
>
> I mapped some of them with shop tags, e.g. shop=butcher shop=greengrocer 
> shop=florist shop=seafood
>
I mapped some of similar shop=greengrocer (assigned space on tables) with
shop=greengrocer street_vendor=yes

Outside their operating hours you will just see empty tables with roofs over 
them

See 
https://www.google.com/maps/@50.0577089,19.9489765,3a,34.3y,256.07h,86.78t/data=!3m6!1e1!3m4!1sn2XHi-4s_3Wj04dLfs4MJg!2e0!7i13312!8i6656?hl=en

https://www.openstreetmap.org/node/6723283136#map=19/50.05763/19.94947 


(I wanted to map each seller with constant presence with their name and exact
location, and exact opening hours, but I had no time for that. 
For now it kind of approximates situation but at leat gives approximate info

nearby famous food truck is better mapped:
https://www.openstreetmap.org/node/2910306864#map=19/50.05859/19.94949 


https://www.google.com/maps/place/Kie%C5%82baski+z+Ro%C5%BCna+Pod+Hal%C4%85+Targow%C4%85/@50.0579891,19.9487817,19z/data=!4m12!1m6!3m5!1s0x47165b15ba6d6e31:0xa3f63eac8bf35f1d!2sMarket+Hall!8m2!3d50.0579727!4d19.9486499!3m4!1s0x47165b15c9b031b7:0x4e4bb61683d84a0a!8m2!3d50.0584563!4d19.9485406?hl=en
)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - archaeological_site

[Mateusz Konieczny via Tagging]

Oct 24, 2022, 11:12 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>> On 23 Oct 2022, at 22:15, Mateusz Konieczny via Tagging 
>>  wrote:
>>
>> personally it seems to me that it has chance of being a good idea
>>
>
>
> which one, deprecating site_type or ignoring the „rejection“ of the voting?
>

deprecating site_type has chance of being a good idea
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Street vendors

[Mateusz Konieczny via Tagging]

if street_vendor / vending would mirror shop values rather
than trying to duplicate shop categorisation, just with different values
then it would be much less problematic.

(I still would have major problems with it but it would get better)

Nov 7, 2022, 11:24 by illiamarchenk...@gmail.com:

> As alternative, I would suggest use either
> (i) street_vendor=* with values similar to values of the shop=*, for example 
> amenity=street_vendor & street_vendor=snack; or
> (ii) made values of vending=* similar to values if the shop=*.  
>
> пн, 7 нояб. 2022 г., 13:01 Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> >:
>
>> My main problem is that this proposals wants to create vending=* equivalent
>> for every single shop value, with values that are in general different.
>>
>> That alone seems to be not worth all benefits that this proposal can bring.
>>
>> Nov 7, 2022, 06:28 by >> map...@t-online.de>> :
>>
>>>
>>> Hi all,
>>>
>>>
>>>  
>>>
>>>
>>> I >>> propose to deprecate street_vendor=* and to tag mappable street 
>>> vendors with amenity=street_vendor + vending=* + opening_hours=* instead.
>>>
>>>
>>>
>>>
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Street_vendors
>>>
>>>
>>>
>>>
>>>
>>> Please discuss this proposal on its Wiki Talk page.
>>>
>>>
>>>  
>>>
>>>
>>> Cheers,
>>>
>>>
>>>  
>>>
>>>
>>> Freetz
>>>
>>>
>>>  
>>>
>>>
>>>
>>>
>>> 
>>>
>>
>> ___
>>  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] Possible merge of marine_rescue & lifeboat_station tags?

[Mateusz Konieczny via Tagging]

Nov 7, 2022, 00:27 by jm...@gmx.com:

>
> On 11/6/2022 6:18 PM, Graeme Fitzpatrick wrote:
>
>
>>
>> I definitely agree that it should be emergency=, ratherthan 
>> amenity=. I must also admit to a slight personalpreference for 
>> =marine_rescue :-), but the vast majority ofusage is in the UK & 
>> Western Europe, where =lifeboatseems to be the most popular, so 
>> I'm happy to go along withthat.
>>
>> I'll see if there's any other comments before starting afull RFC
>>
>
> "Lifeboat" is an ambiguous term  -- it even has a disambiguation  page on 
> Wikipedia  which lists > https://en.wikipedia.org/wiki/Lifeboat_(shipboard)>  
> ahead of > https://en.wikipedia.org/wiki/Lifeboat_(rescue)>  .
>
>
> Favoring emergency=marine_rescue seems sensible to me
>
>

What about such stations on freshwater lakes and on rivers? Is "marine" fitting 
there?

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

Re: [Tagging] Feature Proposal - RFC - Street vendors

[Mateusz Konieczny via Tagging]

My main problem is that this proposals wants to create vending=* equivalent
for every single shop value, with values that are in general different.

That alone seems to be not worth all benefits that this proposal can bring.

Nov 7, 2022, 06:28 by map...@t-online.de:

>
> Hi all,
>
>
>  
>
>
> I > propose to deprecate street_vendor=* and to tag mappable street vendors 
> with amenity=street_vendor + vending=* + opening_hours=* instead.
>
>
>
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Street_vendors
>
>
>
>
>
> Please discuss this proposal on its Wiki Talk page.
>
>
>  
>
>
> Cheers,
>
>
>  
>
>
> Freetz
>
>
>  
>
>
>
>
> 
>

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

Re: [Tagging] Easy way to find proposals [was: Healthcare]

[Mateusz Konieczny via Tagging]

Note that any proposals from
https://wiki.openstreetmap.org/wiki/Category:Archived_proposals
will be skipped in this listing.

Nov 6, 2022, 18:13 by zelonew...@gmail.com:

> You should bookmark this site to keep track of proposals:
>
> https://osm-proposals.push-f.com/
>
> Ideally this should probably be linked to more places.
>
> On Sun, Nov 6, 2022 at 7:31 AM ael via Tagging <> tagging@openstreetmap.org> 
> > wrote:
>
>> A very general comment:-
>>  
>>  I very seldom consider voting on proposals, but I did want to look over
>>  this one.
>>  
>>  However, when I logged into the wiki, there seemed to be no easy way
>>  to find current proposals nor to identify those with active voting.
>>  Perhaps if I had kept a copy of the initial messages in this thread,
>>  I would have found an URI.
>>

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

Re: [Tagging] Feature Proposal - Voting - Healthcare 1.1 - General comment

[Mateusz Konieczny via Tagging]

Nov 6, 2022, 13:27 by tagging@openstreetmap.org:

> A very general comment:-
>
> I very seldom consider voting on proposals, but I did want to look over
> this one.
>
> However, when I logged into the wiki, there seemed to be no easy way
> to find current proposals nor to identify those with active voting.
> Perhaps if I had kept a copy of the initial messages in this thread,
> I would have found an URI.
>
https://wiki.openstreetmap.org/wiki/Category:Proposals_with_%22Voting%22_status
I added link to it at
https://wiki.openstreetmap.org/wiki/Proposal#Lists_of_proposals

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

Re: [Tagging] Feature Proposal - Voting - Healthcare 1.1

[Mateusz Konieczny via Tagging]

Nov 6, 2022, 01:11 by robin.bu...@gmx.de:

>
>  
>
>
>  
>
> "Mateusz Konieczny via Tagging" tagging@openstreetmap.org – 6. November 2022 
> 00:24
>  
>
>>
>> 1) there was no consensus even among people who voted in that old proposal
>>
>>
>
>  
>
>
> And what do you say to the result of 41 : 9 ? That is not a "consensus"? 
>
>
Consensus has a clear meaning, and is far stronger than "only small part is 
opposed".

Consensus was not reached in this case.

> Then why is healtcare also considered approved? Ah well, maybe because it is 
> an approved proposal and therefore the "consensus" for OSM.
>
You can get proposal approved without it being a consensus position.
Also, consensus can change over time.

---

I am dubious about claim that we need to deprecate more heavily used things
to make things more attractive to programmers and data consumers.

"something that you are using just got deprecated" is a guaranteed way to annoy
any programmer. Works well also for manager in a large company.

Also, I will link 
https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/398555
again.
Titled "Deprecated or duplicate tagging schemes in use are not critical issues"___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - Healthcare 1.1

[Mateusz Konieczny via Tagging]

1) there was no consensus even among people who voted in that old proposal
https://wiki.openstreetmap.org/w/index.php?oldid=589962

2) there was no consensus among OSM community at that time

3) proposal process is useful to get review of proposal and thorough nitpicking
and criticism, and to make people aware about some concept.
It can be sort of useful to gauge support for some ideas.
It is not so useful at forcing people to do stuff.
It is thoroughly useless at forcing people to deprecate basic tags.
For example proposal deprecating highway=motorway would not result
in dropping support for highway=motorway, it would result in dropping
support for proposals deprecating things.

4) even if double tagging is unacceptable (I disagree), then this proposal
failed to explain why amenity=hospital rather healthcare=hospital is 
being deprecated

5) "This, by the way, is one reason why certain companies refuse to use OSM 
data."
5a) [citation needed] it will make some programmers grumble a bit at most
5b) OSM data model is not unusually bad compared to many other curious or
insane stuff in geoinformatics, geodatabases, databases, programming in general.
Compared to some stuff I have seen it is working remarkably well.
5c) even if that claim is true, so what?

6) proposal vote getting results you dislike is not a valid reason to deprecate
proposal process

Nov 5, 2022, 23:42 by robin.bu...@gmx.de:

>
> There is no reason?! Sorry, but a consensus of the community that has clearly 
> been reached is clearly a reason.
>
>
>
> And if we now get to the point of just "throwing away" the consensus of 12 
> years ago. We are leading the entire consensus process ad adsurdum. Because 
> then we won't need all this any more. Simply total anarchy. 
> This is also becoming a question: do we still need the proposal process at 
> all? Because the result from 12 years ago is also completely ignored by you. 
> And if you read the old proposal really hard, it was already decided to 
> deprecate in 2010, but no one has finally implemented it.
>
>
>
> In this community, we seem to be moving further and further into a system 
> where improvements to the system are massively prevented and established 
> double tagging is simply left in place instead of finally being cleaned up. 
> This, by the way, is one reason why certain companies refuse to use OSM data. 
> The data structure is unnecessarily inflated and complicated by such 
> duplications. If we don't stick to our own conventions and enforce consensus, 
> perhaps the consensus process should be abolished altogether? 
>
>
>
>
> Abschließend: Ich stelle garnicht in Frage, welches Tagging besser oder 
> schlechter ist. Das ist 2010 schon in einem Consensus von 42 zu 9. Ich stelle 
> dies garnicht zur Diskussion. Es ist schon entschieden worden. 
>  
>
>
> "Joseph Eisenberg" joseph.eisenb...@gmail.com – 5. November 2022 23:27
>  
>
>>
>> This debate has gone on for a long time.
>>
>>
>> I do not have time to review every proposal when there have been so many 
>> lately and many did not appear to be well developed enough to come to a 
>> vote. 
>>
>>
>> I admit that I did not take the proposal seriously since it did not have any 
>> argument in favor of this change. Here is the entire rationale section:
>>
>>
>> ">> With the 2010 proposal there is a double-tagging option for health 
>> facilities. Some of the editors once included it and then discarded it. This 
>> leads sometimes to confusion by mappers. 
>>
>>
>> To tidy up this situation, I propose the following changes. Likewise, 
>> editors, mappers and data users will then have a uniform consensus for 
>> further development."
>>
>>
>>
>> This statement could also be made in favor of deprecating the duplicate, 
>> less popular tags like healthcare=hospital, healthcare=dentist and instead 
>> encouraging use of the more common amenity=hospital, amenity=dentist. There 
>> was no argument or explanation for why the "new" (12 year old) tags under 
>> healthcare should be preferred to the "de facto" standards under the 
>> "amenity" key. 
>>  
>>
>>
>>
>> In fact I would propose to deprecate healthcare=hospital since it is less 
>> common, and amenity=hospital is a good tag which is already used and 
>> interpreted by mappers and database users. 
>>
>>
>> During the start of the pandemic, I started to attempt deprecation of 
>> healthcare=pharmacy as a first step but abandoned the effort due to lack of 
>> time and energy: (>> 
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Deprecate_healthcare%3Dpharmacy>>
>>  ) 
>>
>>
>> - Joseph Eisenberg
>>
>>
>>
>>
>> On Sat, Nov 5, 2022 at 3:00 PM Robin Burek <>> robin.bu...@gmx.de 
>> >> > wrote:
>>  
>>
>>
>>
>>>
>>>
>>> What kind of reversal of guilt is that? If someone does not participate in 
>>> the RFC. And it has been discussed both here and in the new forum. Even 
>>> constructive support, which I have received and not a little.
>>> I have yet to talk to anyone who didn't