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

[Illia Marchenko]

Matija Nalis :

> Relatedly, there are:
>
> https://wiki.openstreetmap.org/wiki/Key:intermittent
> https://wiki.openstreetmap.org/wiki/Key:flood_prone
> https://wiki.openstreetmap.org/wiki/Key:seasonal
>
>
> which might be useful for such cases.
>
> --
> Opinions above are GNU-copylefted.
>

See also wiki.openstreetmap.org/wiki/Tag:hazard=flooding

Regards,
Illia.

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

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

[Illia Marchenko]

But "freeway" is de facto equivalent of motorway, right?

Regards,
Illia.

Brian M. Sperlongano :

>
> yes, but motorway is an exception because it is usually defined by signs
>> rather than characteristics (e.g. if the signs are missing but it looks and
>> feels like, we use motorroad=yes in some countries)
>
>
> Iknow you said 'usually' but this sounds like a very European perspective
> to me.  We have no such distinction in the US. I've learned on this project
> to be quite careful about projecting what we think to be a normal structure
> onto other locations in the world.  In the US it's a motorway if it's
> physically constructed like one, and there's many edge cases that we
> scratch our heads on.
> ___
> 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] Adding 'flood' as value to the key 'hazard' (to be used in combination with the tag boundary=hazard)

[Illia Marchenko]

Just see wiki.openstreetmap.org/wiki/Tag:hazard=flooding

Regards,
Illia.

Cornelia Scholz via Tagging :

> Hi all,
>
> Many thanks for the responses and feedback! :) Here a few comments:
>
> - The aim would be to collect information on historic floods and community
> knowledge of hazard exposure. I work for the Red Cross Climate Centre on
> hazard assessments in typically data scarce areas (e.g. East Sudan). While
> in many western countries most flood areas have high-quality flood maps
> derived from scientific flood models, in those areas we lack this
> information. There are of course global flood models, but they lack
> verification and validation on a local level in many areas I am looking
> into. Especially there, being able to capture information of historic, true
> flood extents and community knowledge is crucial to fill those data gaps
> and improve disaster risk reduction efforts.
> - I reviewed existing tags and tag info, but I thought it lacked some
> uniformity. While with boundary=hazard and the added value there already
> exist approved natural hazard tags which I find make more sense to add in
> here.
> - The OpenHazrdMap was set up as Wiki Page but wasn`t followed through and
> no voting or approval for suggested tags was carried out.
>
> Please let me know what you think, and whether you would approve to adding
> the flood value 'flood' as value to the key 'hazard' (to be used in
> combination with the tag boundary=hazard).
>
> All the best and many thanks,
> Cornelia
>
>
> On Fri, Jun 16, 2023 at 9:13 AM Jez Nicholson 
> wrote:
>
>> Noted.
>>
>>
>> I was [over]reacting to the section from OP about return periods.
>>
>> If this proposal is specifically about areas of historical flooding
>> rather than areas deemed at risk of flooding then they *can* be observed
>> on-the-ground.
>>
>> On Fri, 16 Jun 2023, 01:08 Andy Townsend,  wrote:
>>
>>> On 15/06/2023 20:47, Jez Nicholson wrote:
>>>
>>> Whilst it is a great idea to capture local knowledge about flooding,
>>> especially where it is currently not available, I am concerned that this
>>> doesn't have on-the-ground verification.
>>>
>>> I don't think that anyone has suggested that - at least not in this
>>> thread?
>>>
>>> The original email said "The location and extent of these hazard areas
>>> is often well known by local communities with knowledge of past events."
>>>
>>> When I talked about "what is currently flooded based on current
>>> measured level and previous observations" I meant exactly that -
>>> recording that when a river level at a known point reads X, land at Y (in
>>> the vicinity of X) will also be flooded.
>>>
>>>
>>> Flood risk areas are predictions generated via modelling software and it
>>> depends on which software you use, and the quality of the input data.
>>>
>>> Indeed - the Environment Agency in the UK (and other agencies elsewhere)
>>> make extensive use of this sort of model, but I suspect that mapping this
>>> sort of thing goes  bit beyond what can usefully done within OSM, though of
>>> course it can be combined with OSM data by a data consumer to create "risk
>>> maps".
>>>
>>>
>>> The current hazardous areas get away with it by mapping areas marked out
>>> by signage. Sure, the signs may have been placed following predictions, but
>>> they are physically there to be seen.
>>>
>>> I suspect that this isn't true for all "boundary=hazard" in OSM at the
>>> moment (picking one at random, the signage for
>>> https://www.openstreetmap.org/way/500428513 and the wider
>>> https://www.openstreetmap.org/relation/15680620 doesn't look especially
>>> extensive - see
>>> https://www.abc.net.au/radio/programs/australia-wide/australia-wide/13490888#:~:text=Wittenoom%20is%20the%20largest%20contaminated,site%20in%20Western%20Australia%27s%20Pilbara.
>>> )
>>>
>>> Best Regards,
>>>
>>> Andy
>>> ___
>>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Illia Marchenko]

As possible solution, *shop=weapon* with *sells=firearms;knives*.

Regards,
Illia.

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

[Illia Marchenko]

Hi, Robin!
Please see wiki.openstreetmap.org/wiki/Tag:amenity=dressing_room
Regards,
Illia.



22 May 2023, 15:20 :

>
>
>
>
> *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
> 
> <#m_15727959591987647_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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 - Approved - EV Charging Station Mapping

[Illia Marchenko]

2 May 2023, 16:52 Marc_marc :

> Le 02.05.23 à 14:21, NKA mapper a écrit :
> > The EV Charging Station Mapping
> > <
> https://wiki.openstreetmap.org/wiki/Proposal:EV_Charging_Station_Mapping>
> proposal is now approved
>
>
> I really wonder how we can approve a proposal that makes it impossible
> to migrate from the old scheme to the new one when we see that even
> those that allow it (power=sub_station) take over 10 years to migrate.
> I wonder if a vote should not be planned in two stages:
> - the idea: everyone was aware of the problem
> - the implementation... that we should not vote as long as there is a
> concrete problem (and here there were 2: redefinition of existing tag
> and impossibility to select the objects of the old schema since the new
> schema uses a tag identical to the previous one).
>
> bad day...
>

What is the impossibility of migration? Just use man_made=charge_point
instead of amenity=charging_station for charging points. If the charging
point is already marked as amenity=charging_station, just change it to
man_made=charge_point.
Regards,
Illia.

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

Re: [Tagging] openGeoDB* discardable ?

[Illia Marchenko]

As minimum, openGeoDB:auto_update=* (automatic updates not performed),
openGeoDB:version=* (no sense outside of openGeoDB) and openGeoDB:layer=*
(openGeoDB internal concept) may be dropped without information loss.

22 Apr 2023 г., 12:09 Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

>
>
>
> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Illia Marchenko]

Is it not too late to switch to fuel=* and drop fuel:*=*?

Marc_marc :

> Le 20.04.23 à 03:28, Matija Nalis a écrit :
> > On Thu, 20 Apr 2023 00:47:21 +0200, Marc_marc 
> wrote:
> >> Le 19.04.23 à 14:19, Matija Nalis a écrit :
> >>> I think that my point remains that:
> >>> - one method is clear and unambiguous ("fuel:lpg=no")
> >>> - one method is not clear / is ambiguous ("fuel=octane_98;diesel").
> >>>
> >>> So the first one should be preferred. Does that make sense?
> >>
> >> - one is a nightmare for datause
> >> - one isn't a nightmare for datause
> >> So the 2nd one should be preferred. Does that make sense?
> >
> > Hmm, no, not at all (if ordering of your sentences is same as mine at
> the top quote)?
> >
> > I'll assume that by "datause" you mean something like computer storing
> > data in some kind of database for purpose of retrieving
>
> yes
>
> > - in "fuel:lpg=no" case it is VERY efficient and fast (using const lookup
> >on composite index [key,value]) to look for e.g.
> >
> >SELECT * from t where key = "fuel:lpg" and value = "yes";
>
> only if you are able to make an index on it
> make a index on fuel=* is easy.
> but creating an index on an unknown number of fuel:* keys is problematic
> besides, this information will end up in the hstore for the same reason
>
> for the preset, it's the same problem:
> listing all cuisine=* values is possible (iD does it very well)
> propose a preset that dynamically displays a yes/no field for all
> fuel:*, I've never seen this before, you're limited to hardcoding some
>
> it is a confusion between key and value.
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Illia Marchenko]

Presumably, sign contains symbols (hiker, bicycle and skate) and text.

Graeme Fitzpatrick :

> Is that actually on the sign?
>
> If not, it shouldn't be mapped.
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Illia Marchenko]

Niels Elgaard Larsen :

> For example if you use the template for restaurants and fast_food (but not
> cafes for
> some reason) in JOSM, you get a combobox where you can select one or more
> values for
> "cuisine". I would not assume that if I select indian or sushi that it
> excludes asian.
>

Then clothes=women;underwear doesn't exclude regular clothes? Or does it
mean lingerie?

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

Re: [Tagging] openGeoDB* discardable ?

[Illia Marchenko]

Mateusz Konieczny via Tagging :

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

Are you suggesting removing all or just some of them?

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

Re: [Tagging] openGeoDB* discardable ?

[Illia Marchenko]

Marc_marc :

> Hello,
>
> the openGeoDB* tags were added during an import in 2008 [1] in europe
> and according to the wiki [2], the osm data maj project is long dead
> and was problematic.
> years later we still have plenty of occurrences of tag cases
> if we had to do it again, current good practice would refuse to flood
> osm with internal tags to an external database (except sometimes an id
> such as wikidata)
> I thus propose to change the status of these tags in discardable
> so that those are not preserved during the edition of an object
> some county, for ex Belgium, have already decided to remove them [3]
>
> notice ?
>
> Regards,
> Marc
>
> [1] https://taginfo.openstreetmap.org/keys/openGeoDB%3Aloc_id#chronology
> [2] https://wiki.openstreetmap.org/wiki/OpenGeoDB
> [3] https://www.openstreetmap.org/changeset/81642925


At a minimum, some (openGeoDB:lat=*, openGeoDB:lon=*) tags are completely
useless, and nothing will be lost by discarding them.
Regards,
Illia.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging type of ownership of a road

[Illia Marchenko]

Jens Glad Balchen via Tagging :

> Thank you Timeo.
>
> It seems the designation tag was meant for something else, and only used
> for this purpose in the Philippines. Do you think this usage would be
> beneficial in other countries?
>

If the owner of the road can be inferred from its classification, then
designation=* or even ref=* is sufficient. If not, use ownership=*.
Regards,
Illia.

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

[Tagging] Status of clothes=motorcycle

[Illia Marchenko]

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] key covered=* applied to storage tanks

[Illia Marchenko]

António Madeira :

> IlMy problem with storage_tank=open is that it still has ambiguity. Open
> where? On the top, on the side? Which side? This is very important in the
> case of storage tanks destined to firefighters.
> My question is: how to convey the critical information that a storage_tank
> (or whatever element we consider) is open on the top?
>

I think that water tank opened on the top may not hold liquid because of
the gravity.

Regards,
Illia.

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

Re: [Tagging] Deprecate sport=cricket_nets

[Illia Marchenko]

чт, 2 февр. 2023 г., 14:51 Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

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

Or even *club=sports. *
 Regards,
Illia.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecate sport=cricket_nets

[Illia Marchenko]

Warin <61sundow...@gmail.com>:

> What do you mean by 'a sport'?
>
> The sport soccer, for example, could be taken as referring to the
> physical infrastructure - goads at either end, a rectangular playing
> field. Similar can be said of many OSM 'sports'. So I don't see that as
> being a good argument.
>

For example, *sport=soccer* does not imply a specific physical
infrastructure - this tag can be used with fields (*leisure=pitch*) and
stadiums (*leisure=stadium*). Many tags under the key *sport=** follow this
logic. *sport=cricket_nets* is a notable exception.

Regards,
Illia.

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

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

[Illia Marchenko]

Marc_marc :

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

See https://wiki.openstreetmap.org/wiki/Proposed_features/Practice_pitch

leisure=practice_pitch is intended for pitches that are physically
unsuitable for normal game - for example, small basketball pitch with one
basket.

Regards,
Illia.

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

Re: [Tagging] Deprecate sport=cricket_nets

[Illia Marchenko]

пн, 30 янв. 2023 г., 18:23 Marc_marc :

> Le 30.01.23 à 14:54, Illia Marchenko a écrit :
> > recommend leisure=practice_pitch
>
> what's the diff with a leisure=pitch ?
>

leisure=practice_pitch is not suitable for full game.
Regards,
Illia.

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

[Tagging] Deprecate sport=cricket_nets

[Illia Marchenko]

Hello everyone,
I suggest deprecating sport=cricket_nets on the wiki and recommend
leisure=practice_pitch & sport=cricket as a replacement, since sport=*
generally refers to a sport, not a physical infrastructure.
Regards,
Illia.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Illia Marchenko]

António Madeira :

> The main issue is not closed water tanks. That can be a default in OSM.
> The issue here is how to inform that a storage_tank is open.
> Mind you that there is an infinitude of storage tanks types, but for
> firefighting, those are almost exclusively made in concrete and are open
> for the reasons I stated before.
>
> In my opinion, the cover=* key is the most adequate in these situations,
> because there's no way to define what the roof/coverage of these storage
> tanks would be if they had one.
> Stating that a an emergency storage tank is covered=no informs that it can
> be accessible from above.
> If, for example, we state that it has a roof=no, you're defining a
> specific kind of covering, when it has none and you have no way to know if
> that would be a roof, a tarp, a shed, etc
>

Maybe *storage_tank=open *or similar.
Regards,
Illia.

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

Re: [Tagging] Private ambulance / patient transport service

[Illia Marchenko]

Graeme Fitzpatrick :

> A suggestion on the forum of amenity=training for the first-air training
> side of things + a description of everything else.
>

Note that the proposal for  amenity
=training was rejected.
wiki.openstreetmap.org/wiki/Proposed_features/training
Regards,
Illia.

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

Re: [Tagging] Feature Proposal - RFC - Gender

[Illia Marchenko]

Thanks for the review!
I replaced unisex=yes with unisex=only and unisex=separate, except for
hairdressers, where unisex=yes is not a problem.
Regards,
Illia.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Gender

[Illia Marchenko]

Thanks for feedback!

Marc_marc :

> Le 17.12.22 à 21:58, Illia Marchenko a écrit :
> > Gender proposal is ready for voting. After the previous vote, this
> > proposal has been reworked. I plan to start voting in a few days.
> >
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Gender
> <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] Feature Proposal - RFC - Gender

[Illia Marchenko]

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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Illia Marchenko]

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?

[Illia Marchenko]

One tag is enough. I prefer emergency=lifeboat_station  because "emergency"
is a narrower key.

вс, 6 нояб. 2022 г., 9:17 Graeme Fitzpatrick :

> Some time ago, I raised a proposal for Marine Rescue stations:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Marine_rescue.
> After a few weeks, I returned it to draft status, pending the resolution of
> the Military Bases proposal which was also going through at that time, but
> despite that, it’s now in use ~250 times!
>
>
> One of the concerns that were raised at the time was the existence of two
> other, similar tags: emergency=lifeboat_station 
> https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dlifeboat_station
> &
> 
> also amenity=lifeboat_station
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dlifeboat_station, both
> of which were created by the same mapper on the same day, & neither of
> which were apparently ever discussed?
>
>
> These two tags have been used a similar number of times (400 – 450), but
> when I’ve looked at a number of them at random, both tags have been used
> together on a lot of locations e.g
> https://www.openstreetmap.org/way/260096274,
> https://www.openstreetmap.org/way/894864797, &
> https://www.openstreetmap.org/way/444884651.
>
>
> It would seem somewhat ridiculous to have three virtually identical tags
> describing the same thing, as well as two tags on the same POI, so I am
> suggesting that they all be consolidated into one tag, with the other two
> being deprecated.
>
>
> Before proceeding with that discussion though, is there any reason to tag
> something as both an amenity= & also emergency=?
>
>
> Thanks
>
> Graeme
> ___
> 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] Feature Proposal - Rejected - Gender

[Illia Marchenko]

Voting for Gender proposal has been stopped. During the voting process,
some issues were raised, and the proposal needs to be improved.
wiki.openstreetmap.org/wiki/Proposed_features/Gender
Ideas are welcome.
Regards,
Illia.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - Voting - Gender

[Illia Marchenko]

Voting has been started for Gender proposal.
https://wiki.openstreetmap.org/wiki/Proposed_features/Gender
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - Rejected - Training

[Illia Marchenko]

Training proposal has been rejected. Thanks to everyone who participated
and voted.
Regards,
Illia.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging standards [moved from osmf-talk]

[Illia Marchenko]

вт, 25 окт. 2022 г., 0:59 Illia Marchenko :

> Then so:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
P. S. After
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging standards [moved from osmf-talk]

[Illia Marchenko]

вт, 25 окт. 2022 г., 0:30 Asa Hundert :

> Am Mo., 24. Okt. 2022 um 01:05 Uhr schrieb Illia Marchenko
> :
> >
> > I suggest alternative solution: some machine readable spec, which
> defines mapping between stable identifier and tags. For example (XML):
> > 
> > 
> > 
> […]
>
> In XML, ids must be unique.

Then so:
















> Did you mean "my personal notion of what
> this stands for ID"? After reading
> https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua
> consumers are doing that already.
>
This is example only. Of course, another options is possible, including
Lua, JSON or even binary.
Regards,
Illia.

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

Re: [Tagging] Tagging standards [moved from osmf-talk]

[Illia Marchenko]

вс, 23 окт. 2022 г., 22:56 Tomas Straupis :

>
>   As there have been incidents where widespread and basic tags have
> been known and widely understood and still some inexperienced people
> after several months of "practice" in OSM managed to push changes to
> those with devastating effects still visible today it is still a very
> good idea to clearly state such "standard" tags and "freeze" them.
>
>   I strongly believe that freezing "main" tags for main landuse,
> roads, waterways, buildings, places, MAIN amenities (classes used in
> 99% of map/gis products) would allow data consumers to spend less time
> on running after changes, reading thousands of letters to identify
> possible changes to important tags etc. Very few people care how
> colour of a bench is tagged but all care how a lake is tagged.
>

I suggest alternative solution: some machine readable spec, which defines
mapping between stable identifier and tags. For example (XML):






In this example, "healthcare.hospital", "shop.supermarket" and
"landform.peak" is stable identifiers. If tag has been replaced, config
must be updated. Config may be applied on conversion stage.
Regards,
Illia.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - Rejected - Privacy

[Illia Marchenko]

Privacy proposal has been rejected. Thanks to everyone who participated and
voted.
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Privacy
Regards,
Illia.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] improve the proposal procedure

[Illia Marchenko]

пт, 21 окт. 2022 г., 2:37 Frederik Ramm :

> These people could use their free time to make one successful proposals
> instead of five unsuccessful ones that waste everyone's time because
> they are half-hearted.
>

Most of the rejected proposals are good written, but fundamentally broken.

The OSMF should not be involved but the OSMF's definition of an "active
> contributor" could nonetheless be used. It would make it less likely to
> get proposals from people who don't map and therefore are unlikely to be
> able to make a good proposal.
>

I am has been an active contributor in the past, but currently do not map,
and not an "active contributor" in formal sense. I am unlikely to be able
to make a good proposal?

Keep in mind that the proposal process isn't a one-way street. It can
> only work as long as for every one proposal there are dozens of people
> who can read and constructively participate in the development of the
> proposal. The capacity for new proposals is limited.
>

I am agree with clause that capacity is limited, but limit are known? For
example, minimal RFC stage may be raised to 30 days, if it is necessary.

"As do I, but I get a bit concerned when RFCs / proposals are raised for
discussions that are still going on e.g. the recent very involved
discussions re fountains / drinking-water / water-taps, when in-depth
conversations were still proceeding over multiple threads, but there are
actual proposals being raised"

My apologies. This proposal has been withdrawn very quickly.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] improve the proposal procedure

[Illia Marchenko]

чт, 20 окт. 2022 г., 23:07 Marc_marc :

> I wasn't talking about asking for control by the osmf, I was just
> talking about using the same criteria of active contributors
> to avoiding sock-people like last week : if you never map, if you
> aren't an active contributor to the osm project, your proposal
> I find it hard to believe that this can lead to a sensible proposal.
>

http://hdyc.neis-one.org/?Something%20B
I am sock-people?

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

Re: [Tagging] Feature Proposal - Voting - man made=evaporation tower

[Illia Marchenko]

https://wiki.openstreetmap.org/wiki/Proposed_features/man_made%3Devaporation_tower

чт, 20 окт. 2022 г., 22:25 Illia Marchenko :

> Please give link :-)
>
> чт, 20 окт. 2022 г., 20:57 Kamil Kulawik :
>
>> Hi!
>>
>> Voting has started for evaporation towers tagging -
>> man_made=evaporation_tower.
>>
>> Please vote on the Wiki!
>> <https://wiki.openstreetmap.org/wiki/Proposal_process>
>> - Coolawik
>>
>> https://wiki.openstreetmap.org/wiki/Proposal_process
>> ___
>> 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] Window tinting?

[Illia Marchenko]

Maybe craft=window_construction?
wiki.openstreetmap.org/wiki/Tag:craft=window_construction

чт, 20 окт. 2022 г., 8:35 Graeme Fitzpatrick :

> How do you tag businesses doing window tinting for either cars or building
> windows?
> https://en.wikipedia.org/wiki/Window_film
>
> Some of the options seem to be shop=window_blind or craft=sun_protection
> but neither of them excite me!
> https://wiki.openstreetmap.org/wiki/Tag:shop%3Dwindow_blind
> https://wiki.openstreetmap.org/wiki/Tag:craft%3Dsun_protection
>
> Thanks
>
> Graeme
> ___
> 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 - Voting - man made=evaporation tower

[Illia Marchenko]

Please give link :-)

чт, 20 окт. 2022 г., 20:57 Kamil Kulawik :

> Hi!
>
> Voting has started for evaporation towers tagging -
> man_made=evaporation_tower.
>
> Please vote on the Wiki!
> 
> - Coolawik
>
> https://wiki.openstreetmap.org/wiki/Proposal_process
> ___
> 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] improve the proposal procedure

[Illia Marchenko]

чт, 20 окт. 2022 г., 15:44 Peter Elderson :

> Proposing and voting should not be hard, so you always get some lesser
> quality stuff.
>
For example, I will accept any constructive feedback for my proposal. But
"it is lesser quality stuff" is very subjective. Any proposal are either
good or bad. If some proposal are bad, simply write about it - here, on its
Wiki talk page, somewhere.
Regards,
Illia.

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

Re: [Tagging] improve the proposal procedure

[Illia Marchenko]

I think that additional restrictions are unnecessary, unless proper reason.

чт, 20 окт. 2022 г., 15:44 Peter Elderson :

> I agree that it got a little out of hand, but there were some good
> proposals and votes as well.
> Proposing and voting should not be hard, so you always get some lesser
> quality stuff.
>
> Let's not throw away the baby with the wash water.
>
>  Peter Elderson
>
>
> Op do 20 okt. 2022 om 14:28 schreef Marc_marc :
>
>> Hello,
>>
>> the past few weeks have been stormy for proposals:
>> - people opening 4 or more RFCs to collect opinions
>> - RFCs or votes that open and close in less than 12 hours
>> - Proposals that go to vote on the 14th day, even though
>> this is the minimum time limit and the problems in progress
>> have sometimes not been resolved.
>> - nominees to make even more simultaneous proposals
>> without showing that it is just one person
>>
>> How could we improve this ?
>> - limit to 1 simultaneous proposal per person?
>> - limit this to active contributor status in the osmf sense?
>> - encourage the use of the "resolved" tag in the talk page
>> to see visually if the points have been addressed or not?
>> - improve the wording for the 14 day minimum time limit which
>> is too often understood lately as "pfff 14 days to wait" ?
>> - limit the scope of proposal ?
>> - any other ideas?
>>
>> Regards,
>> Marc
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - Rejected - Gender

[Illia Marchenko]

Voting has been stopped for Gender proposal. This proposal needs some
rework.
wiki.openstreetmap.org/wiki/Proposed_features/Gender
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - Voting - Gender

[Illia Marchenko]

Voting has started for Gender proposal.
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Gender
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - pickup

[Illia Marchenko]

сб, 15 окт. 2022 г., 18:36 Volker Schmidt :

> amenity=parcel_locker is used 26k times.
> amenity=vending_machine + vending_machine=pickup is use 16 k times and
> deprecated
> So why should we abandon  amenity=parcel_locker and create a new key with
> duplicate meaning .
>
I agree. amenity=parcel_locker & parcel_pickup=* is perfectly suitable for
self-service pickup points.

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

Re: [Tagging] Feature Proposal - RFC - pickup

[Illia Marchenko]

сб, 15 окт. 2022 г., 11:41 Volker Schmidt :

> Around here we have many instances of self-service parcel-locker inside a
> shop that is inside a building. The shop does not occupy the entire
> building, the locker is only accessible during shop opening times.
>
> There are also pick-up points in shops where a human being handles the
> operation (I know of a prinhong shop and a petrol station). So there is a
> case for distinguishing between self-service and human-handled pick-up
> points.
>
I suggest office=pickup for human-handled and amenity=pickup_locker for
self-service points.

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

Re: [Tagging] camp sites in Haiti

[Illia Marchenko]

I think that amenity=refugee_site & fixme=Review may be solution, it isn't
the ideal, but are better then leave "as is".

ср, 12 окт. 2022 г., 11:54 Warin <61sundow...@gmail.com>:

>
> On 12/10/22 02:05, Joseph Eisenberg wrote:
>
> > Would it be possible to re-tag those refugee camps in an automated
> edit? … I'm not even sure if they all still exist 12 years later.
>
> It would not be possible, because we do not know if they still exist.
>
>
> So you leave them with an incorrect tag?
>
> I'd re-tag them.. but only after looking at imagery to see if they are
> refugee sites.
>
> And I'd try to find the most upto date imagery to confirm there existence
> ..
>
>
>
>
> However a local mapper or someone who has visited the area could re-tag
> them, after confirming that they still exist and are in fact refugee sites
>
>
> A local mapper or visitor can also confirm or delete them after they have
> been retagged by a remote mapper.
>
> And after 212 years of inactivity the change may prompt a local to think
> about these sites.
>
>
> -Joseph Eisenberg
>
> On Tue, Oct 11, 2022 at 4:20 AM Anne-Karoline Distel 
> wrote:
>
>> Hello,
>>
>> I noticed that many of the refugee camps in Haiti are tagged as
>> tourism=camp_site which made me uneasy. Turns out there is the tag
>> amenity=refugee_site. Would it be possible to re-tag those refugee camps
>> in an automated edit? There are about 60 or 70 mapped. I'm not even sure
>> if they all still exist 12 years later.
>>
>> Anne
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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] Feature Proposal - RFC - Water outlet

[Illia Marchenko]

вт, 11 окт. 2022 г., 11:48 Martin Koppenhoefer :

> On the other hand, if you are looking for places to do sports, it is not
> sufficient to look at leisure=pitch if you want to find all of them.
>

Of course. Hierarchical tagging. leisure = pitch & sport = *.

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

Re: [Tagging] Better term for unisex

[Illia Marchenko]

пн, 10 окт. 2022 г., 22:31 Marc_marc :

> when a =yes tag has different characteristics,
> it is easy to add values for the different characteristics
> unisexx=segregated unisexx=not-segregated
> and given the existence of 2 meanings according to the contributors,
> the yes value will have to be double-checked if we wish to specify
> the meaning the contributor had in mind
>
This is first reasons for proposal. Second reason is usage female=yes and
male=yes for both toilets and hairdresser, where meaning are different.
wiki.openstreetmap.org/wiki/Proposed_features/Gender

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

Re: [Tagging] Better term for unisex

[Illia Marchenko]

Term "unisex" is obvious for me (I am not a native English speaker), but in
JOSM validator historically has been rule "replace female=yes & male=yes to
unisex=yes".

пн, 10 окт. 2022 г., 21:56 martianfreeloader :

> Hi Amanda,
>
> No.
>
> What puzzles non-native speakers (including myself) is that English has
> a clear distinction between sex and gender (other than, for example,
> German). Yet, the term "unisex" (contains the word "sex") is used to
> designate a situation in the "gender" category, not sex.
>
> Can you help?
>
>
> On 10/10/2022 19:37, Amanda McCann wrote:
> > On Thu, 06 Oct 2022 20:05 +02:00, Zeke Farwell 
> wrote:
> >> The proposal currently states:
> >>> Meaning of the unisex =yes
> is currently unclear:
> >>>
> >>>   * gender neutral facility (as the "unisex" term in English); or
> >>>   * facility that accessible for men and women, either segregated or
> not.
> >> I do not understand what is unclear.  The term unisex is well
> >> understood among English speakers to mean "gender neutral".
> >
> > I'm a native English speaker, and I agree! I also wrote that part of the
> wiki (years ago). I think some non-native speakers treated `unisex=yes` as
> meaning “gender segregated but male & female are available”, i.e. read that
> paragraph as “some OSMers might have been wrong, and we don't know how many
> unisex=yes/no tags in OSM were affected by the misunderstanding”
> >
>
> ___
> 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 - Water outlet

[Illia Marchenko]

Unification of tags allows more simple usage source data, e.g leisure =
pitch allows rendering of all pitches, but lots of tags as
leisure=tennis_court, leisure = baseball_playground, leisure =
football_ground is more difficult to use.

пн, 10 окт. 2022 г., 18:15 Marc_marc :

> Le 09.10.22 à 09:37, Martin Koppenhoefer a écrit :
> > Why do people have to “deprecate” other people’s tags when they
> > introduce new ones with different semantics?
>
> to avoid 42 schemas https://imgs.xkcd.com/comics/standards.png
>
> Standardization is a good thing for quality but it is often a difficult
> exercise, especially when the previous tags mix several pieces of
> information into one, as is the case here or for tag with several
> meaning (see forest saga)
>
>
>
> ___
> 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 - Water outlet

[Illia Marchenko]

вс, 9 окт. 2022 г., 9:50 Warin <61sundow...@gmail.com>:

> On 8/10/22 20:49, Illia Marchenko wrote:
> > Water outlets for public or customer use (generic tagging).
> >
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Water_outlet
> > Please discuss this proposal on its Wiki Talk page.
> >
>
> Discussions can take place here, part of the tagging list.
>

Of course, but "Please discuss this proposal on its Wiki Talk page."
mentioned on wiki.openstreetmap.org/Proposal_process
<http://wiki.openstreetmap.org/Proposal_Process>

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

[Tagging] Feature Proposal - Voting - Training

[Illia Marchenko]

Voting has started for Training.
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/training
Voting has started for Training
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/training
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - Voting - Training

[Illia Marchenko]

Voting has started for Training.
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/training
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Water outlet

[Illia Marchenko]

I withdrew this proposal. Thanks for your feedback!
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] not:brand:wikidata?

[Illia Marchenko]

Prefix not:*=* used for prevention mistakes. In this context, wikidata
entry from not:brand:wikidata=* in irrelevant.

сб, 8 окт. 2022 г., 16:43 Dave F via Tagging :

> Hi
>
> What is 'not:brand:wikidata'?
>
> There are 5000+ in the database. Can't see any wiki details.
> I'm struggling to comprehend the logic.
>
> Cheers
> DaveF
>
> ___
> 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 - Water outlet

[Illia Marchenko]

This proposal is response to long discussion about deprecation of
man_made=drinking_fountain.
This is unrelated to other proposals, either my own or resubmitted.

сб, 8 окт. 2022 г., 14:05 Marc_marc :

> Le 08.10.22 à 11:49, Illia Marchenko a écrit :
> > Water outlets for public or customer use (generic tagging).
> >
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Water_outlet
> > <
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Water_outlet
> >
>
> I am afraid that creating a proposal per week or more, strongly
> degrades the quality of it
>
> e.g. you created your proposal on water in a sub-thread of the one
> on swimwear, itself in a sub-thread of the one on gender
>
>
>
> ___
> 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] Feature Proposal - Voting - Privacy

[Illia Marchenko]

Voting has started for Privacy.

https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Privacy
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - Water outlet

[Illia Marchenko]

Water outlets for public or customer use (generic tagging).
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Water_outlet
Please discuss this proposal on its Wiki Talk page.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecation proposal: man_made=drinking_fountain

[Illia Marchenko]

Alternative to the sport=soccer is sport=british_football because
"football" is context specific, and "American football", "Australian
football", "Canadian football", "Gaelic football" exists.

ср, 5 окт. 2022 г., 13:52 martianfreeloader :

> There is a broad consensus that the language for OSM tags is British
> English. Using a non-BE word for a tag because it is used in Australia
> while a synonymous BE word exists, would be the same using a Xhosa,
> Portuguese or Korean word, just because it exists.
>
> I know there are a few exceptions like sport=soccer, footway=sidewalk
> and sidewalk=*, but I think this kind of exceptions shouldn't be made
> without a very good reason.
>
>
>
> On 05/10/2022 12:04, Warin wrote:
> >
> > On 5/10/22 08:25, Minh Nguyen wrote:
> >> Vào lúc 11:54 2022-10-04, Jass Kurn đã viết:
> >>> I've just noticed there is a bubbler tag being promoted? Which
> >>> appears to be an American English term for a British English drinking
> >>> fountain. Why promote another term, and use an American English term.
> >>> What was wrong with calling a drinking fountain a drinking fountain?
> >>
> >> To clarify, "bubbler" is a distinctively regional term in Boston,
> >> Rhode Island, and Wisconsin. Elsewhere, it's either "drinking
> >> fountain" or "water fountain". [1]
> >
> >
> > No. 'Bubbler' is also used in Australia. And possibly elsewhere is the
> > world.
> >
> > -
> >
> > In England it looks like a "Drinker Water Fountain" spurts water
> > upwards. There are some with elevated outlets described as water bottle
> > filler, but are at a height that is convenient to drink from with flow
> > rates to suit direct human consumption.
> >
> >
> > Things that direct water downwards? And have flow rates greater than
> > convenient for human consumption? To me, these are 'taps'.
> >
> >
> > The problem?
> >
> >
> > 1) identify feature that provided drinkable water - fairly basic. At the
> > moment the common amenity=drinking_water does this .. or the secondary
> > tag of drinking_water=yes.
> >
> >
> > 2) identify the physical properties and easy usability of the feature
> for;
> >
> > 2a) humans to directly drink from. Consider a small child, the elderly.
> >
> https://upload.wikimedia.org/wikipedia/commons/thumb/e/e2/Drinking_Fountain_-_The_Noun_Project.svg/278px-Drinking_Fountain_-_The_Noun_Project.svg.png
> >
> >
> > 2b) refilling glasses/cup/mugs/bottle from. In most instances there
> > would be some form of tap?
> >
> https://upload.wikimedia.org/wikipedia/commons/thumb/6/6d/France_road_sign_ID29.svg/337px-France_road_sign_ID29.svg.png
> >
> >
> > 2c) refiling large vessels from e.g. caravans, boats? A little google
> > searching for caravans leads me to believe that they use 'normal' taps,
> > probably because they are 'everywhere' and more likely to be 'free'.
> >
> >
> > This leaves out wells, streams.. and other things?
> >
> >
> > Possibly there is a need to avoid the words presently in use - tap,
> > bubbler, fountain, drinking_fountain?
> >
> > So? A sub tag for amenity=drinking_water?
> >
> > water_direction=upwards/downwards ? Humm should consider stationary
> > sources, and streams and pools  - a bowel etc? Humm any ideas
> >
> >
> > It would be nice to indicate the flow rate too .. but that will cause
> > too many arguments .. so lets just work on the above?
> >
> >
> >
> >
> > ___
> > 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] Feature Proposal - RFC - Swimwear

[Illia Marchenko]

>
> Swimwear policy of the facility.
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Swimwear
Please discuss this proposal on its Wiki Talk page.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Terminology primary feature, main tag, etc..

[Illia Marchenko]

1) Yes,  it is.
2) I don't know.
Regards, Illia.

вс, 2 окт. 2022 г., 20:40 martianfreeloader :

> Hi,
>
> I'm unsure if I'm using correct terminology. I have come across these
> terms in the OSM ecosystem:
>
> - primary feature [1]
> - main key [2]
> - primary key [3]
> - feature tag [4]
>
> 1) Are these synonyms (except for the key/tag distinction)?
>
> 2) Is *one* of these terms "official" OSM speek with a clear definition?
> (as is the case for things like "node", "way", "relation", "key",
> "value", "tag", "changeset")
>
>
> [1] https://wiki.openstreetmap.org/wiki/Map_features
> [2] https://wiki.openstreetmap.org/wiki/Key:highway
> [3] https://wiki.openstreetmap.org/wiki/Homonymous_keys
> [4]
>
> https://tools.geofabrik.de/osmi/?view=tagging=14.46052=46.23038=15=Geofabrik%20Standard=no_feature_tag_nodes%2Cno_feature_tag_wayshttps://tools.geofabrik.de/osmi/?view=tagging=14.46052=46.23038=15=Geofabrik%20Standard=no_feature_tag_nodes%2Cno_feature_tag_ways
>
> ___
> 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] Feature Proposal - RFC - Clothing

[Illia Marchenko]

Clothing policy of the facility (old proposal, but renewed).
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Clothing
Please discuss this proposal on its Wiki Talk page.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Gender

[Illia Marchenko]

My apologies, unisex=segregated

ср, 28 сент. 2022 г., 12:50 Illia Marchenko :

> The normal meaning of the term unisex is "gender neutral", so unisex=mixed
> sounds weird.
>
> ср, 28 сент. 2022 г., 10:39 Marc_marc :
>
>> Le 28.09.22 à 01:34, Illia Marchenko a écrit :
>> > gender=mixed/segregated has clear semantics.
>>
>> this shows that there is a need for 2 new values,
>> not necessarily for a new key
>>
>> unisex=mixed/segregated has clear semantics too
>>
>>
>>
>> ___
>> 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 - Gender

[Illia Marchenko]

The normal meaning of the term unisex is "gender neutral", so unisex=mixed
sounds weird.

ср, 28 сент. 2022 г., 10:39 Marc_marc :

> Le 28.09.22 à 01:34, Illia Marchenko a écrit :
> > gender=mixed/segregated has clear semantics.
>
> this shows that there is a need for 2 new values,
> not necessarily for a new key
>
> unisex=mixed/segregated has clear semantics too
>
>
>
> ___
> 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 - Gender

[Illia Marchenko]

For example, gender segregated toilets: gender=segregated instead of
female=yes & male=yes. Or unisex toilet: gender=mixed instead of
unisex=yes.

ср, 28 сент. 2022 г., 2:52 Sebastian Martin Dicke <
sebastianmartindi...@gmx.de>:

> It could be useful to give examples in which cases which tagging schema
> is feasible. That could help to avoid such a situation as existing with
> phone/fax/email versus contact:*.
>
>
> Regards
>
>
> Sebastian
>
>
>
>
> ___
> 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 - Gender

[Illia Marchenko]

This key can be used together with or instead of female=*, male=*, unisex=*
or combinations thereof. The motivation is that the meaning of unisex=yes
remains undefined, but gender=mixed/segregated has clear semantics.

ср, 28 сент. 2022 г., 2:24 Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

> How it relates to
> https://wiki.openstreetmap.org/wiki/Key:male
> https://wiki.openstreetmap.org/wiki/Key:female
> 
> https://wiki.openstreetmap.org/wiki/Key:unisex
> ?
>
> Sep 28, 2022, 00:52 by illiamarchenk...@gmail.com:
>
> Gender destination of the facility.
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Gender
> Please discuss this proposal on its Wiki Talk page.
>
>
> ___
> 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 - Gender

[Illia Marchenko]

Gender destination of the facility.
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Gender
Please discuss this proposal on its Wiki Talk page.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Training

[Illia Marchenko]

Maybe also amenity=university, but this out of scope of this proposal.

вт, 27 сент. 2022 г., 1:27 Graeme Fitzpatrick :

>
> On Tue, 27 Sept 2022 at 02:10, Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>> What about universities where future sailors/pilots are training
>> (often these are military schools).
>>
>
> They should then be under military=base + base_function=training
>
> Thanks
>
> Graeme
>
> ___
> 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] Feature Proposal - RFC - Training

[Illia Marchenko]

Training centers (reactivated proposal).
https://wiki.openstreetmap.org/wiki/Proposed_features/training
Please discuss this proposal on its Wiki Talk page.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - Privacy

[Illia Marchenko]

Property key privacy=stalls/partitions/communal_room/no that indicates
whether shower or other feature offers a privacy or not.
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Privacy
Please discuss this proposal on its Wiki Talk page.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging