Re: [Tagging] Feature Proposal - RFC - Rideshare Access

[nathan case]

Clare: this is a good discussion to have.

It seems as though the emergence of rideshare services is still being addressed 
at various legal levels but, at least in the UK, rideshare vehicles are not 
classed taxis and so are not ordinarily entitled to use bus/taxi lanes. If 
situations exist where rideshares are specifically allowed (or not), and that 
access is distinct from taxi or a regular motor_vehicle, then a key should 
exist to denote that. I note that the proposal has been updated to reflect such 
cases.

> Joseph Eisenberg: But you will also need to add a definition of a "rideshare 
> vehicle", since this will need to be translated for places where Lyft and 
> Uber do not operate, and where English is not used (e.g. Indonesia). 
> Unfortunately I don't see a good online source for a definition.

Perhaps such definitions are dependent upon local/national legislation. In your 
follow on examples, do those services enjoy the same access rights as PSVs? If 
yes, then perhaps they should simply be covered by that tag? If they do not, do 
they have any additional or fewer access rights than simply 
motor_vehicle/cycle? If not, then perhaps they should simply be covered by 
those respective tags?

So a definition could be something along the lines of: “A private hire vehicle, 
often booked through an online service or a mobile application, that does not 
enjoy the same legal standing as a taxi service. Exact definition may depend on 
local law but usually denotes services such as Uber and Lyft.”

A taxi that also takes bookings/collects fares via an app is still a taxi, in 
my opinion.

Regards,

Nathan


From: Joseph Eisenberg 
Sent: Thursday, October 15, 2020 12:32 AM
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Feature Proposal - RFC - Rideshare Access

Clare,

The "proposal" section currently fails to include the actual proposal: that is, 
what new key and tags are you proposing to use?

It looks like the proposal is: "approve the use of the new key "rideshare=" 
with values "yes" and "no" to specify legal access for rideshare vehicles."
But you will also need to add a definition of a "rideshare vehicle", since this 
will need to be translated for places where Lyft and Uber do not operate, and 
where English is not used (e.g. Indonesia). Unfortunately I don't see a good 
online source for a definition.

Is a Gojek motorcycle a rideshare vehicle? See 
https://en.wikipedia.org/wiki/Gojek
What about pedicabs (tricycles) which are hailed with a smartphone app?
Or should only passenger cars be included?
What about taxis which also get fares via an app?

- Joseph Eisenberg

On Wed, Oct 14, 2020 at 1:44 PM Clare Corthell via Tagging 
mailto:tagging@openstreetmap.org>> wrote:

Hi Tagging List,


Here is the RFC for the proposal for rideshare vehicle access:


Proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/Rideshare_Access

Discussion: 
https://wiki.openstreetmap.org/w/index.php?title=Talk:Proposed_features/Rideshare_Access


This proposes the addition of rideshare as a use-based access mode for 
land-based transportation. This would enable mapping restriction or permission 
of rideshare vehicles to nodes and ways. As mentioned in the proposal example 
cases,
 this typically arises in dense traffic patterns such as airport pickup zones.


This proposal originated from the experience of the Lyft mapping team seeking 
to improve the accuracy of routes we build from an OSM-based map. Because our 
rideshare operations are North America based, we bring a perspective that 
centers the policy for right-of-way in this context. We would especially 
appreciate feedback on the applicability of this tagging to other parts of the 
world.


Looking forward to your commentary and feedback.


Clare

--
Clare Corthell
Product Manager, Lyft Mapping
How Lyft Creates Hyper-Accurate Maps from Open-Source Maps and Real-Time 
Data
[Image removed by sender.]

___
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 to change key:man_made to key:human_made

[nathan case]

Pros and cons aside, “human-made” is not a term that is in current widespread 
usage. As a native English GB speaker, I find it clunky and somewhat 
distracting.

A better gender neutral term might be “artificial”, which is already a synonym 
for “man-made” and is already widely used. 

Indeed, the Handbook of Nonsexist Writing suggests: "artificial, handmade, 
hand-built, synthetic, manufactured, fabricated, machine-made, and constructed" 
as options instead of man-made. Presumably the majority (if not all) of OSM 
"man-made" tags relate to objects which are not naturally occurring. Therefore 
"artificial" seems to hold.

Other sources: 
https://writingcenter.unc.edu/tips-and-tools/gender-inclusive-language/ 
https://www.chicagomanualofstyle.org/qanda/data/faq/topics/Usage/faq0053.html
https://dictionary.cambridge.org/dictionary/english/man-made

An issue may arise if artificial is already being used as a tag however.

Best,

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

Re: [Tagging] Deprecate water=pond?

[nathan case]

Agreed: it is often not possible to tell  if a pond/lake is artificial or not. 
Some lakes are hundreds of years old and the environment has adapted to now 
appear as though it were a natural feature.

Reservoir does not seem appropriate for an artificial pond. In my experience, 
reservoirs are large and tend to store water for either consumption or to 
generate power. Ponds can range from something in one’s back garden, to 
substantial bodies of water in parks and nature reserves. Basin doesn’t seem to 
fit with these either (they appear to be more for temporary storage of water?).

It seems that requiring “lake” to be natural is the issue. Lakes can be both 
natural and artificially made. If we could tag “ponds” as “lakes” and then add 
a tag “lake=pond” that would allow some freedom for the mapper. However, it 
appears that there is a willingness to separate “natural” and “artificial”/”man 
made” features.

Best.

From: Peter Elderson 
Sent: Tuesday, November 10, 2020 7:49 AM
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Deprecate water=pond?

The problem is that natural and artificial are not neatly separated IRL. In 
Nederland, nature is neatly cut, shaven and shaped. Currently, natural style is 
preferred. "New nature" is the hype, where heavy machinery creates new 
landscapes including ponds, lakes, streams and wetlands. Sea dykes are shaped 
like dunes. Etc. So every pond is made to look natural, and every lake is 
reshaped and maintained.

We have words for pond ("vijver") and lake ("meer") but very loosely defined, 
and many more terms for other bodies of water.

I think a clearcut definition would not help at all in this case.

Peter Elderson


Op 10 nov. 2020 om 06:30 heeft Joseph Eisenberg 
mailto:joseph.eisenb...@gmail.com>> het volgende 
geschreven:

The tag water=pond was added with a large number of other types of "water=*" in 
2011, but it has a poorly defined description.

"A pond: a body of standing water, man-made 
in most cases, that is usually smaller than a lake. Salt evaporation ponds 
should be tagged with 
landuse=salt_pond,
 open-air swimming pools — with 
leisure=swimming_pool."

So it might be artificial, like a landuse=reservoir or water=reservoir, but 
smallish. Or it might be natural like a water=lake, but smallish. However, 
nothing on the water=lake page defines a lower limit for the size of a lake.

This is a shame, because all the other values of water=* are clearly defined as 
only natural, or only artificial, and waterway=* features are also clearly 
divided. Furthermore, the original lags landuse=reservoir and landuse=basin 
were also clearly artificial, while lakes were natural.

But the biggest problem is that there is no way to define a lower size for a 
lake or reservoir, or an upper size for a pond. And the size of the area is 
easier available from the geometry of the feature, so it doesn't need to be 
mentioned in the tag.

I think the best option is to deprecate water=pond and suggest using water=lake 
for natural lakes, even small ones, and use water=reservoir or water=basin (or 
landuse=reservoir or =basin if you prefer) for the artificial ones.

-- Joseph Eisenberg
___
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] Deprecate water=pond?

[nathan case]

I strongly disagree with the notion of splitting ponds and lakes by natural or 
artificial/man-made.

Not only is this often incredibly difficult to verify, it also leads to this 
complex situation of needing multiple tags for what are, essentially, the same 
features.

The current notion of an artificial/man-made lake being a reservoir is 
non-sense. Artificial lakes are still lakes. Additionally, not all reservoirs 
are artificial – some are natural.

Best.

From: Joseph Eisenberg 
Sent: Thursday, November 12, 2020 1:30 AM
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Deprecate water=pond?

Ok, it looks like enough people feel that a very small artificial water body, 
like a decorative pond in a residential garden, shouldn't be tagged as 
water=reservoir or water=basin, so we need a replacement.

I can see the logic behind that, if a reservoir is thought to be larger and 
must have a dam on one side, and a basin is artificially graded. A small koi 
pond or decorative pool isn't exactly the same.

The current problem with water=pond is that many are completely natural 
features, but almost all other values of water=* are clearly natural (or 
semi-natural), or clearly artificial, so water=pond is losing this information 
which otherwise should be conveyed by the key water=*. Since it is unlikely 
that we could check 1 million water=pond features quickly, it's not reasonable 
to redefine the meaning of this tag, but we can create a new tag or several 
replacement tags which are more specific, and encourage use of those instead.

But we need to have a clear description which will translate into other 
languages and cultures. For example, in Papua Indonesia, most Trans-New Guinea 
languages use 1 word for all types of "water", including rivers, streams, 
lakes, and the sea, so they won't see a difference between a "lake" and a 
"pond" unless you clearly describe it.

There are already several other more specific tags for small artificial water 
bodies, in use:
(https://taginfo.openstreetmap.org/keys/?key=water#values)
- water=reflecting_pool - "A reflecting pool: a water feature found in gardens, 
parks, and at memorial sites. It usually consists of a shallow pool of water, 
undisturbed by fountain jets, for a calm reflective surface."
- water=moat - A deep, wide defensive ditch, normally filled with water, 
surrounding a fortified habitation.
- water=wastewater - A clarifier/settling basin of a wastewater treatment plant.
- water=fountain
- water=fishpond

And as mentioned before, there are water=reservoir (A 
reservoir or an artificial lake is 
used to store water. ) and water=basin (An area of land artificially graded to 
hold water.)

So perhaps we could create a new tag water=natural_pond for small, natural or 
semi-natural lakes which are currently tagged as water=pond, and 
water=artificial_pond or water=man_made_pond for the majority of water=pond 
features which are clearly not natural, such as ponds in gardens.

-- Joseph Eisenberg


On Tue, Nov 10, 2020 at 1:59 AM Andy Mabbett 
mailto:a...@pigsonthewing.org.uk>> wrote:
>
> On Tue, 10 Nov 2020 at 05:26, Joseph Eisenberg
> mailto:joseph.eisenb...@gmail.com>> wrote:
>
> > I think the best option is to deprecate water=pond and suggest using 
> > water=lake for
> > natural lakes, even small ones, and use water=reservoir or water=basin (or
> > landuse=reservoir or =basin if you prefer) for the artificial ones.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] feature Proposal - Voting - settlement_type=crannog

[Nathan Case]

Hi Anne,

I don't have any objections about the tag specifically. But proposals 
like this do raise an interesting question.


Your proposal is for a specific value. However, the key itself 
"settlement_type" (https://wiki.openstreetmap.org/wiki/Key:site_type) is 
only "in use". Further, the parent tag to this is "site_type=settlement" 
and both key and value are only "in use". The parent tag to that 
"historic=archaeological_site" is de facto.


If this particular (and likely quite low usage, by your own admission) 
tag is approved, what does that do to the complete tag hierarchy? Does 
everything in the hierarchy become approved too?


Is that appropriate - to set an approved status of a much more widely 
used hierarchy based on one (assumed to be) low-usage tag proposal? Do 
voters read up on the whole hierarchy when voting on a specific tag (if 
that hierarchy hasn't previously been approved)? Should they?


If it's not appropriate then we end up in the situation where parent 
keys aren't approved but child keys/values are - which seems a little 
odd. I note this situation has arisen previously (e.g. 
https://wiki.openstreetmap.org/wiki/Proposed_features/holy_well but 
place_of_worship=* as a key is still just "in use") but I'm not sure 
we've ever decided the ramifications of them.


Best,

Nathan






On 07/10/2022 08:11, Anne-Karoline Distel wrote:

Voting has started on the crannog proposal:

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

There was only one comment during the fortnight of discussion, so it
should be fairly forward. I know there are a lot of discussions about
more important tags going on at the moment, but maybe you can find a 
minute.


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

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

[Nathan Case]

On 24/11/2022 09:07, Warin wrote:

Some ships and boats don't move much... as they are part of museums ...


Something that is part of a museum, and is genuinely permanently 
secured, seems very different to an emergency response vehicle (which a 
lifeboat is for all intents and purposes). I'd map planes at an air and 
space museum but not ones at an airport terminal.


I guess the trouble with lifeboats is that they can be stored on land or 
they can be kept moored in the water. So it isn't quite as easy as 
saying "map the building" as sometimes there won't be a building (for 
the lifeboat, there normally is a building for the crew to change in etc).



On 24/11/2022 09:00, Jez Nicholson wrote:
When the lifeboat is permanently moored at a particular location it is 
less transitory than a busso people can and do tag them. Not me 
necessarily, but other mappers.


Being a little pedantic, a lifeboat that is "permanently moored" won't 
serve much use as a lifeboat. Being less pedantic, mapping the reserved 
mooring location could work, however, in that case, we should be tagging 
it as a mooring spot rather than as a lifeboat itself. The mooring 
location will remain even if the lifeboat is at sea.



Nathan


On 24/11/2022 09:07, Warin wrote:



On 24/11/22 11:25, Graeme Fitzpatrick wrote:



On Thu, 24 Nov 2022 at 09:29, Andy Townsend  wrote:


Why not both?

Because a boat is a mobile feature, that we don't / can't map?

e.g 
https://www.openstreetmap.org/edit?way=349559642#map=19/-27.42815/153.08582 
- we don't try to map the last bus in the middle row as #632



Some ships and boats don't move much... as they are part of museums ...

Way: HMAS Onslow (166230547) - mapped as a 'ship' but it is a 
submarine and they are boats.


Way: HMAS Vampire (166230548)

 Tags:
    "historic"="ship"
    "name"="HMAS Vampire"
    "ref"="D11"
    "seamark:name"="HMAS Vampire"
    "ship:type"="destroyer"
    "start_date"="1956"
    "tourism"="attraction"
    "wikidata"="Q721087"
    "wikipedia"="en:HMAS Vampire (D11)"

___
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] craft vs office for service enterprises/establishments.

[Nathan Case]

For me:

office=electrician

should be used for mapping the location of larger electricians company, 
e.g., as Daniel says, where they employ office staff and, likely, more 
than one electrician works at the company. The primary function of the 
tag is that this location acts as an office with primarily 
administrative tasks, rather than electrical tasks, being carried out there.


craft=electrician

should be used for either: the registered address of an electrician 
(usually their residential address but maybe a shared office space or 
workshop) who is not part of a larger company (in the UK we'd call that 
"self-employed").


Cheers.


On 26/01/2023 21:06, Daniel Bégin wrote:


I recently asked for a clarification and did not get any answer. So 
here is my question again (with some context):


Using the workplace of an electrician as an example, it was made clear 
that I should use craft=electrician instead of office=electrician. But 
what if this electrician sees its business get bigger (in a North 
American context)?


The electrician eventually hires secretaries, accountants, many other 
electricians and create a company (if not already incorporated). 
Should that workplace being tagged as office=company and 
company=electrician? Or if only the final output of the company should 
be taken into account (whatever its size) and then still be tagged 
craft=electrician?


Thank you for your patience :-)

Sent from Mail  for 
Windows



*From:* Daniel Bégin 
*Sent:* Thursday, January 26, 2023 12:00:44 PM
*To:* Tag discussion, strategy and related tools 

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

+1

Get Outlook for Android 



*From:* Graeme Fitzpatrick 
*Sent:* Wednesday, January 25, 2023 5:00:59 PM
*To:* Tag discussion, strategy and related tools 

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




On Thu, 26 Jan 2023 at 02:51, Daniel Bégin  wrote:

and office=psychologist because they provide services.


I would usually use healthcare=psychotherapist for them.

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] Railway tagging: detail key

[Nathan Case]

Hi all,

I've noticed substantial use (99,297 instances) of the "detail" key, but 
it is undocumented on the Wiki.


Nearly all uses (99.96%) of this key are detail=track [1], which is 
associated with railways [2]. The key is predominantly used in France 
(77.6% of uses [3]) but also elsewhere across central Europe.


I have concerns about this key (it's ambiguous and perhaps redundant if 
all "correct" uses are for the same value) but, nevertheless, it would 
be good to document its usage if possible. I haven't found anything in 
the railway=*, railways, or OpenRailwayMap/Tagging documentation [4,5,6].


Does anybody know the background to this key, or what its intended 
values might be?


Many thanks,

Nathan


[1] https://taginfo.openstreetmap.org/keys/detail#values

[2] https://taginfo.openstreetmap.org/keys/detail#combinations

[3] https://overpass-turbo.eu/s/1nzc

[4] https://wiki.openstreetmap.org/wiki/Key:railway

[5] https://wiki.openstreetmap.org/wiki/Railways

[6] https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging



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

Re: [Tagging] Railway tagging: detail key

[Nathan Case]

Thanks (merci!) for your response and for looking into this Marc.

Since it seems a large part of the usage of this key will be reverted, 
I'll leave it as undocumented for now.


Nathan


On 10/11/2022 15:32, Marc_marc wrote:

Le 09.11.22 à 15:20, Marc_marc a écrit :

Hello,

Le 09.11.22 à 10:59, Nathan Case a écrit :

The key is predominantly used in France (77.6% of uses [3])


no idea.
forwarded/translated to talk-fr + 2 changeset comment


feedback from the main (if not the only) contributor of this tag in 
France : old stuff before the (now de-facto in France) tracks=1 ,

to be deleted
https://www.openstreetmap.org/changeset/111203619

mecanical edit annoncement was made on talk-fr for France
Others values in France 'll be checkec/fixed by hand (I see some 
missuse for description)


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] [RFC] Barbers (hairdresser=barber)

[Nathan Case]

Hi all,

RFC for the proposal to introduce "hairdresser"="barber" as the approved way of 
tagging barbershops: https://wiki.openstreetmap.org/wiki/Proposal:Barbers

Please also see previous discussion on the Community Forum: 
https://community.openstreetmap.org/t/tagging-of-barbers-barbershops/107657

Thanks,

Nathan


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

[Tagging] [Voting] Feature Proposal - Barbers (hairdresser=barber)

[Nathan Case]

Hi all,

Voting has started for Barbers (hairdresser=barber): 
https://wiki.openstreetmap.org/wiki/Proposal:Barbers



 * [RFC] Barbers (hairdresser=barber) 

 * Previous community discussion 


As noted in the Community Forum 
 
voting announcement, the main objections raised in the RFC were:

 *

   *We don’t have barbers in X location:*
   It is clear that in some locations, the concept of a barbers does not exist 
or is not well understood. Whilst I do think we should try to make tags as 
understandable as possible to mappers, it seems that if the concept of a 
barbers doesn’t exist in X location, then it simply doesn’t need to be used in 
that location.

 *

   *male=yes is good enough*
   Although documented as an access restriction, it is clear that |male=*| is 
not always used as such and is instead sometimes used as a more generic 
descriptor. However, I still believe explicit tagging is better than relying on 
gender tags.

 *

   *Use a different tagging scheme*
   Some suggest using a different tagging scheme (e.g., |barbers=yes/no/only|). 
I understand the rationale and I don’t think there is a right or wrong way, 
however, we should chose one. I’ve kept with |hairdresser=barber| as this was 
the majority vote in the original discussion.

One (non-minor) change was made during the RFC:

 * *Semi-colon delimiter lists*
   Although not strictly part of the proposal, tagging businesses that are both 
a hairdresser’s salon and a barbers was raised. The suggestion from the 
community discussion was to use semi-colon delimiter lists (e.g., 
|hairdresser=salon, barber|). I added this to the tagging section of the 
proposal.

Many thanks to all who contributed to the discussion!
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging