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

2020-11-11 Thread Martin Koppenhoefer
Am Mi., 11. Nov. 2020 um 16:16 Uhr schrieb Ilya Zverev :

> My point is that anywhere except UK, “ride-sharing” is the term for Uber,
> Lyft, Bolt, and such. While researching, I’ve found road signs and articles
> using “Ride Share” or “ride-sharing” in the US, Australia, and Russia.
>


I am not convinced. In Germany, there clearly is a distinction between ride
sharing ("Mitfahrzentrale" and others, "I am going somewhere anyway and
share petrol costs with other people I can take on the free seats in my
car") and companies like Uber etc. which are considered
"Personenbeförderung" ("I sort of work informally for a company which
weasels around taxi and employment legislation by trying to make their
business look as if it was about ride sharing").



> Even in UK, "ride-sharing" is a common term when addressing these
> companies, e.g. on the BBC and Evening Standard websites. It can be found
> much more often than "private hire”.
>


It is a term that these companies use themselves because it has a positive
image, and someone picks it up. I do not say it cannot be understood, my
point is we should not use it, because it devaluates the term.



>
> On the other hand, in London drivers of these cars need to have “private
> hire” licenses. We’re discussing access restriction, and these are for
> cars/drivers, not for companies. In London specifically this term might be
> more correct. In any other place the probability of finding a “ride share
> vehicles” restriction is higher than for “private hire vehicles”.
>


there are no restrictions for true ride sharing. These are cars like any
other cars, and ordinary drivers who can go anywhere where any other driver
can go (almost, actually they will have an advantage von heavy occupancy
lanes).



>
> https://en.wikipedia.org/wiki/Ridesharing_company
>


yeah, the English wikipedia is quite dominated by the North American point
of view. I am a bit astonished that the page is only available in 6
languages. which could hint that there is some problem with it, for example
there is also: https://en.wikipedia.org/wiki/Carpool which is available in
32 languages.

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


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

2020-11-11 Thread Ilya Zverev
Regarding the private_hire, I’m not so sure. We indeed you English spelling for 
tags (colour, neighbourhood), and that’s okay since it’s consistent. But when 
instead of just spelling we use a UK-specific legal term, it might be not 
understood. For example, see village_green.

My point is that anywhere except UK, “ride-sharing” is the term for Uber, Lyft, 
Bolt, and such. While researching, I’ve found road signs and articles using 
“Ride Share” or “ride-sharing” in the US, Australia, and Russia.

Even in UK, "ride-sharing" is a common term when addressing these companies, 
e.g. on the BBC and Evening Standard websites. It can be found much more often 
than "private hire”.

On the other hand, in London drivers of these cars need to have “private hire” 
licenses. We’re discussing access restriction, and these are for cars/drivers, 
not for companies. In London specifically this term might be more correct. In 
any other place the probability of finding a “ride share vehicles” restriction 
is higher than for “private hire vehicles”.

So when I see rideshare=designated, as a person living outside England, I can 
immediately understand what that means. For private_hire I would need to refer 
to wikipedia or google the term. Wikipedia, of course, uses “Ride-sharing” for 
these companies as well, and not once mentions “private hire” in the article.

https://en.wikipedia.org/wiki/Ridesharing_company 


My vote is for “rideshare”, although I’m not invested in any of the terms, 
provided we agree on something and then can map access restrictions that have 
been on the ground for years.

Ilya

> On 31 Oct 2020, at 20:57, Joseph Eisenberg  wrote:
> 
> It's almost never standard to use access=bus or access=taxi, it's 
> bus=yes/no/designated + taxi=yes/no/designated added to another feature like 
> a highway=* or amenity=parking
> 
> I agree with the idea of using private_hire=* instead of rideshare=* because 
> this appears to be a proper British English term for any non-taxi, privately 
> arranged transport vehicle, and it's not as misleading as "rideshare" when 
> used on services like Uber and Lyft. Though I would like to see more British 
> folks weigh in on the correct terminology.
> 
> See 
> https://en.wikipedia.org/wiki/Taxicabs_of_the_United_Kingdom#Private_hire_(minicabs)
>  
> 
> 
> -- Joseph EIsenberg
> 
> On Sat, Oct 31, 2020 at 10:51 AM Brian M. Sperlongano  > wrote:
> Actually I quite like "private_hire" as an access value.
> 
> Are you suggesting access=private_hire as a tag?  That would not be 
> consistent with how taxi services are tagged.  We don't use access=taxi, we 
> use amenity=taxi + taxi=*.  By that logic, the access tagging should use 
> private_hire=*, and probably with some value of amenity=.
> ___
> 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 - Rideshare Access

2020-11-06 Thread Clare Corthell via Tagging
Hi all,

Thanks for the discussion. Lately the open questions center on formulating
tags for pickup/dropoff points or areas as opposed to roads. Some of the
latest:
- How should a designated curb location be indicated for rideshare access?
How might this apply to a point or area (eg parking lot

)?
- How might designations for specific companies be indicated? (eg Uber
pickup location differing from Lyft pickup location)
- How might access for pickup only, dropoff only, or both be indicated? Do
existing access values satisfy these? Is a tag indicating pickup/dropoff
zone/point needed?
- How would an exclusive road for rideshare be tagged,
"rideshare=yes"+"access=no" or "rideshare=designated"+"access=no"?
- Is there a more common term for uber/grab/lyft/yandex/etc than
"rideshare"?

Please add to this summary or join in. Open to starting the voting process
~Nov 12, we could push back again if this begs further discussion.

Clare

On Wed, Nov 4, 2020 at 3:38 PM Andrew Harvey 
wrote:

> I wouldn't do that because then logically you have two features, but in
> this case they are one in the same, it's a rideshare pickup parking lot, as
> opposed to a on-street section designated for rideshare pickup/dropoff.
>
> On Thu, 5 Nov 2020 at 09:38, Simon Poole  wrote:
>
>> While I would try to avoid it, you can naturally simply duplicate the
>> geometry (and you don't even need to duplicate the nodes to do that).
>> Am 04.11.2020 um 22:26 schrieb Andrew Harvey:
>>
>>
>> On Wed, 4 Nov 2020 at 20:10, Philip Barnes  wrote:
>>
>>> On Wed, 2020-11-04 at 07:26 +1100, Andrew Harvey wrote:
>>>
>>>
>>>
>>> On Tue, 3 Nov 2020 at 23:14, Simon Poole  wrote:
>>>
>>> We don't seem to have a tagging currently for dedicated pickup locations
>>> in this kind of context, bus stops etc are naturally taggable), if
>>> considered really useful I don't see why we couldn't introduce a
>>> amenity=...pickup... tag.
>>>
>>>
>>> But if such a dedicated pickup location is a carpark then it needs
>>> amenity=parking, so it can't fit into the amenity key.
>>>
>>>
>>> A pickup point will be a node within a car park area.
>>>
>>> Its is already common to add amenity=bicycle_parking nodes within
>>> amenity=car_park areas.
>>>
>>
>> Why would it be a node within a car park? For example
>> https://www.openstreetmap.org/way/366754575 is the designated airport
>> Uber, etc. pickup location, not some point inside the car park, but the
>> whole car park itself.
>>
>> ___
>> 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
>


-- 
Clare Corthell
Product Manager, Lyft Mapping
*How Lyft Creates Hyper-Accurate Maps from Open-Source Maps and Real-Time
Data
*
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-11-04 Thread Andrew Harvey
I wouldn't do that because then logically you have two features, but in
this case they are one in the same, it's a rideshare pickup parking lot, as
opposed to a on-street section designated for rideshare pickup/dropoff.

On Thu, 5 Nov 2020 at 09:38, Simon Poole  wrote:

> While I would try to avoid it, you can naturally simply duplicate the
> geometry (and you don't even need to duplicate the nodes to do that).
> Am 04.11.2020 um 22:26 schrieb Andrew Harvey:
>
>
> On Wed, 4 Nov 2020 at 20:10, Philip Barnes  wrote:
>
>> On Wed, 2020-11-04 at 07:26 +1100, Andrew Harvey wrote:
>>
>>
>>
>> On Tue, 3 Nov 2020 at 23:14, Simon Poole  wrote:
>>
>> We don't seem to have a tagging currently for dedicated pickup locations
>> in this kind of context, bus stops etc are naturally taggable), if
>> considered really useful I don't see why we couldn't introduce a
>> amenity=...pickup... tag.
>>
>>
>> But if such a dedicated pickup location is a carpark then it needs
>> amenity=parking, so it can't fit into the amenity key.
>>
>>
>> A pickup point will be a node within a car park area.
>>
>> Its is already common to add amenity=bicycle_parking nodes within
>> amenity=car_park areas.
>>
>
> Why would it be a node within a car park? For example
> https://www.openstreetmap.org/way/366754575 is the designated airport
> Uber, etc. pickup location, not some point inside the car park, but the
> whole car park itself.
>
> ___
> 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 - Rideshare Access

2020-11-04 Thread Simon Poole
While I would try to avoid it, you can naturally simply duplicate the 
geometry (and you don't even need to duplicate the nodes to do that).


Am 04.11.2020 um 22:26 schrieb Andrew Harvey:


On Wed, 4 Nov 2020 at 20:10, Philip Barnes > wrote:


On Wed, 2020-11-04 at 07:26 +1100, Andrew Harvey wrote:



On Tue, 3 Nov 2020 at 23:14, Simon Poole mailto:si...@poole.ch>> wrote:


We don't seem to have a tagging currently for dedicated pickup
locations in this kind of context, bus stops etc are naturally
taggable), if considered really useful I don't see why we
couldn't introduce a amenity=...pickup... tag.




But if such a dedicated pickup location is a carpark then it
needs amenity=parking, so it can't fit into the amenity key.


A pickup point will be a node within a car park area.

Its is already common to add amenity=bicycle_parking nodes within
amenity=car_park areas.


Why would it be a node within a car park? For example 
https://www.openstreetmap.org/way/366754575 
 is the designated 
airport Uber, etc. pickup location, not some point inside the car 
park, but the whole car park itself.


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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-11-04 Thread Andrew Harvey
On Wed, 4 Nov 2020 at 20:10, Philip Barnes  wrote:

> On Wed, 2020-11-04 at 07:26 +1100, Andrew Harvey wrote:
>
>
>
> On Tue, 3 Nov 2020 at 23:14, Simon Poole  wrote:
>
> We don't seem to have a tagging currently for dedicated pickup locations
> in this kind of context, bus stops etc are naturally taggable), if
> considered really useful I don't see why we couldn't introduce a
> amenity=...pickup... tag.
>
>
> But if such a dedicated pickup location is a carpark then it needs
> amenity=parking, so it can't fit into the amenity key.
>
>
> A pickup point will be a node within a car park area.
>
> Its is already common to add amenity=bicycle_parking nodes within
> amenity=car_park areas.
>

Why would it be a node within a car park? For example
https://www.openstreetmap.org/way/366754575 is the designated airport Uber,
etc. pickup location, not some point inside the car park, but the whole car
park itself.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-11-04 Thread Philip Barnes
On Wed, 2020-11-04 at 07:26 +1100, Andrew Harvey wrote:
> On Tue, 3 Nov 2020 at 23:14, Simon Poole  wrote:
> >   
> > 
> >   
> >   
> > We don't seem to have a tagging currently for dedicated pickup
> >   locations in this kind of context, bus stops etc are
> > naturally
> >   taggable), if considered really useful I don't see why we
> > couldn't
> >   introduce a amenity=...pickup... tag.
> 
> But if such a dedicated pickup location is a carpark then it needs
> amenity=parking, so it can't fit into the amenity key.  

A pickup point will be a node within a car park area.

Its is already common to add amenity=bicycle_parking nodes within
amenity=car_park areas.

Phil (trigpoint)


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


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

2020-11-03 Thread Andrew Harvey
On Tue, 3 Nov 2020 at 23:14, Simon Poole  wrote:

> We don't seem to have a tagging currently for dedicated pickup locations
> in this kind of context, bus stops etc are naturally taggable), if
> considered really useful I don't see why we couldn't introduce a
> amenity=...pickup... tag.
>

But if such a dedicated pickup location is a carpark then it needs
amenity=parking, so it can't fit into the amenity key.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-11-03 Thread Simon Poole
We don't seem to have a tagging currently for dedicated pickup locations 
in this kind of context, bus stops etc are naturally taggable), if 
considered really useful I don't see why we couldn't introduce a 
amenity=...pickup... tag.


Am 31.10.2020 um 23:50 schrieb Brian M. Sperlongano:
The use of the proposed access tagging on roads to indicate whether or 
not a private hire/rideshare can drive on them I think we can all 
agree is straightforward, but it gets muddy when talking about other 
types of infrastructure that this might apply to.


I would like to better understand how such access tagging would work 
in practice for an example at my local airport.  In that instance, the 
designated Uber pickup/dropoff location is a particular spot within a 
specific parking garage (tagged with amenity=parking + building=yes).  
Do I add private_hire=designated to the building?  Okay, that can 
work.  But then, adding operator=Uber doesn't work -- after all, Uber 
isn't operating the parking garage, they just have permission to make 
pickups at a particular signed location. This tells me that a POI 
that's separate from the parking garage object is needed to indicate 
the precise pickup location within the garage.  Are we saying that's 
amenity=taxi + private_hire=designated?  That doesn't work because a 
taxi stand implies on-demand transportation.  I would just ask that we 
consider the full picture of how designated private hire/rideshare 
tagging should be done at airports and other transportation hubs; 
without that "big picture", merely focusing very narrowly on the 
access attribute feels incomplete.


On Sat, Oct 31, 2020 at 4:03 PM Simon Poole > wrote:


I think there is a bit of a misunderstanding here.

This is not about taxi stands or anything similar, but about
access for Lyfts, Ubers, Grabs employees to streets and
infrastructure that they would not be able to utilize if they were
driving for themselves (including actual ride sharing :-)).
Example pick up and drop off access at airports and similar, this
might include access to taxi dedicated infrastructure too. This is
quite legit and no beef with the companies wanting to be able to
model this to improve routing for their drivers and customers.

Simon

Am 31.10.2020 um 15:23 schrieb Brian M. Sperlongano:

In the United States at least, there is a very real difference in
meaning between "rideshare" and "taxi" services when it comes
*specifically* to access at airports.  And I believe that is the
intent of this proposal: how do I tag the special area in the
airport where I must go in order to be picked up by XYZ rideshare
company?

At an airport, if you wish to take a taxi, you walk up to a taxi
stand (amenity=taxi), where the taxi cabs line up, and you take
the first taxi cab in line. This is an explicit area where only
taxis queue up.

Alternately, if you wish to take a "ride share", you are using an
app to make an arrangement with a specific vehicle and driver to
be picked up at a specific location.  In this case, airports
often (at this point, probably "usually") have a specified
location where such ride shares are allowed to pick up and/or
drop off passengers.

In some cases, the ride share pickup/drop-off locations have
specific areas that are different for different ride share
providers.  For example, at my local airport, due to
disagreements about how much these companies should pay the
airport for curb access (really), there is one location where you
can pick up a Lyft, and a separate location 100 meters away off
the airport property where you can pick up an Uber!

The point here is that in the US there is a very real distinction
between these two classes of objects, and the information someone
traveling through the airport looking for ground transportation
would want to know is:
1. Is it a ride share (pre-arranged pickup) or taxi stand
(on-demand pickup)
2. Is it limited to only specific ride share companies?
3. Is it pickup only, dropoff only, or both?



On Sat, Oct 31, 2020 at 6:36 AM Simon Poole mailto:si...@poole.ch>> wrote:

For starters I would oppose using the term "rideshare" for
what is a taxi/chauffeur service. It should be noted that
there are actual rideshare organisations and services out
there, but uber, grab, lyft etc. are not among them, they are
simply trying to co-opt a term with positive associations for
their operations.

Further, real rideshare services don't get special access
treatment anywhere I know of, outside of vehicle occupancy
regulations, which isn't surprising as real ride sharing
simply involves sharing costs and car on a trip that the
driver was going to make anyway.

If there are actual legal differences between taxi 

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

2020-10-31 Thread Brian M. Sperlongano
 The use of the proposed access tagging on roads to indicate whether or not
a private hire/rideshare can drive on them I think we can all agree is
straightforward, but it gets muddy when talking about other types of
infrastructure that this might apply to.

I would like to better understand how such access tagging would work in
practice for an example at my local airport.  In that instance, the
designated Uber pickup/dropoff location is a particular spot within a
specific parking garage (tagged with amenity=parking + building=yes).  Do I
add private_hire=designated to the building?  Okay, that can work.  But
then, adding operator=Uber doesn't work -- after all, Uber isn't operating
the parking garage, they just have permission to make pickups at a
particular signed location.  This tells me that a POI that's separate from
the parking garage object is needed to indicate the precise pickup location
within the garage.  Are we saying that's amenity=taxi +
private_hire=designated?  That doesn't work because a taxi stand implies
on-demand transportation.  I would just ask that we consider the full
picture of how designated private hire/rideshare tagging should be done at
airports and other transportation hubs; without that "big picture", merely
focusing very narrowly on the access attribute feels incomplete.

On Sat, Oct 31, 2020 at 4:03 PM Simon Poole  wrote:

> I think there is a bit of a misunderstanding here.
>
> This is not about taxi stands or anything similar, but about access for
> Lyfts, Ubers, Grabs employees to streets and infrastructure that they would
> not be able to utilize if they were driving for themselves (including
> actual ride sharing :-)). Example pick up and drop off access at airports
> and similar, this might include access to taxi dedicated infrastructure
> too. This is quite legit and no beef with the companies wanting to be able
> to model this to improve routing for their drivers and customers.
>
> Simon
> Am 31.10.2020 um 15:23 schrieb Brian M. Sperlongano:
>
> In the United States at least, there is a very real difference in meaning
> between "rideshare" and "taxi" services when it comes *specifically* to
> access at airports.  And I believe that is the intent of this proposal: how
> do I tag the special area in the airport where I must go in order to be
> picked up by XYZ rideshare company?
>
> At an airport, if you wish to take a taxi, you walk up to a taxi stand
> (amenity=taxi), where the taxi cabs line up, and you take the first taxi
> cab in line.  This is an explicit area where only taxis queue up.
>
> Alternately, if you wish to take a "ride share", you are using an app to
> make an arrangement with a specific vehicle and driver to be picked up at a
> specific location.  In this case, airports often (at this point, probably
> "usually") have a specified location where such ride shares are allowed to
> pick up and/or drop off passengers.
>
> In some cases, the ride share pickup/drop-off locations have specific
> areas that are different for different ride share providers.  For example,
> at my local airport, due to disagreements about how much these companies
> should pay the airport for curb access (really), there is one location
> where you can pick up a Lyft, and a separate location 100 meters away off
> the airport property where you can pick up an Uber!
>
> The point here is that in the US there is a very real distinction between
> these two classes of objects, and the information someone traveling through
> the airport looking for ground transportation would want to know is:
> 1. Is it a ride share (pre-arranged pickup) or taxi stand (on-demand
> pickup)
> 2. Is it limited to only specific ride share companies?
> 3. Is it pickup only, dropoff only, or both?
>
>
>
> On Sat, Oct 31, 2020 at 6:36 AM Simon Poole  wrote:
>
>> For starters I would oppose using the term "rideshare" for what is a
>> taxi/chauffeur service. It should be noted that there are actual rideshare
>> organisations and services out there, but uber, grab, lyft etc. are not
>> among them, they are simply trying to co-opt a term with positive
>> associations for their operations.
>>
>> Further, real rideshare services don't get special access treatment
>> anywhere I know of, outside of vehicle occupancy regulations, which isn't
>> surprising as real ride sharing simply involves sharing costs and car on a
>> trip that the driver was going to make anyway.
>>
>> If there are actual legal differences between taxi and chauffeur access
>> somewhere, we could use chauffeur or chauffeur-driven as an access tag
>> (better suggestions welcome).
>>
>> Simon
>>
>> ..
> ___
> 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 - Rideshare Access

2020-10-31 Thread Simon Poole

I think there is a bit of a misunderstanding here.

This is not about taxi stands or anything similar, but about access for 
Lyfts, Ubers, Grabs employees to streets and infrastructure that they 
would not be able to utilize if they were driving for themselves 
(including actual ride sharing :-)). Example pick up and drop off access 
at airports and similar, this might include access to taxi dedicated 
infrastructure too. This is quite legit and no beef with the companies 
wanting to be able to model this to improve routing for their drivers 
and customers.


Simon

Am 31.10.2020 um 15:23 schrieb Brian M. Sperlongano:
In the United States at least, there is a very real difference in 
meaning between "rideshare" and "taxi" services when it comes 
*specifically* to access at airports.  And I believe that is the 
intent of this proposal: how do I tag the special area in the airport 
where I must go in order to be picked up by XYZ rideshare company?


At an airport, if you wish to take a taxi, you walk up to a taxi stand 
(amenity=taxi), where the taxi cabs line up, and you take the first 
taxi cab in line.  This is an explicit area where only taxis queue up.


Alternately, if you wish to take a "ride share", you are using an app 
to make an arrangement with a specific vehicle and driver to be picked 
up at a specific location.  In this case, airports often (at this 
point, probably "usually") have a specified location where such ride 
shares are allowed to pick up and/or drop off passengers.


In some cases, the ride share pickup/drop-off locations have specific 
areas that are different for different ride share providers.  For 
example, at my local airport, due to disagreements about how much 
these companies should pay the airport for curb access (really), there 
is one location where you can pick up a Lyft, and a separate location 
100 meters away off the airport property where you can pick up an Uber!


The point here is that in the US there is a very real distinction 
between these two classes of objects, and the information someone 
traveling through the airport looking for ground transportation would 
want to know is:
1. Is it a ride share (pre-arranged pickup) or taxi stand (on-demand 
pickup)

2. Is it limited to only specific ride share companies?
3. Is it pickup only, dropoff only, or both?



On Sat, Oct 31, 2020 at 6:36 AM Simon Poole > wrote:


For starters I would oppose using the term "rideshare" for what is
a taxi/chauffeur service. It should be noted that there are actual
rideshare organisations and services out there, but uber, grab,
lyft etc. are not among them, they are simply trying to co-opt a
term with positive associations for their operations.

Further, real rideshare services don't get special access
treatment anywhere I know of, outside of vehicle occupancy
regulations, which isn't surprising as real ride sharing simply
involves sharing costs and car on a trip that the driver was going
to make anyway.

If there are actual legal differences between taxi and chauffeur
access somewhere, we could use chauffeur or chauffeur-driven as an
access tag (better suggestions welcome).

Simon



..


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-10-31 Thread Jez Nicholson
As a Brit, I would say, "private hire vehicle (PHV)" for a minicab, Uber
etc.

'vehicle' not meaning only motorised.


On Sat, 31 Oct 2020, 18:00 Joseph Eisenberg, 
wrote:

> It's almost never standard to use access=bus or access=taxi, it's
> bus=yes/no/designated + taxi=yes/no/designated added to another feature
> like a highway=* or amenity=parking
>
> I agree with the idea of using private_hire=* instead of rideshare=* because
> this appears to be a proper British English term for any non-taxi,
> privately arranged transport vehicle, and it's not as misleading as
> "rideshare" when used on services like Uber and Lyft. Though I would like
> to see more British folks weigh in on the correct terminology.
>
> See
> https://en.wikipedia.org/wiki/Taxicabs_of_the_United_Kingdom#Private_hire_(minicabs)
>
> -- Joseph EIsenberg
>
> On Sat, Oct 31, 2020 at 10:51 AM Brian M. Sperlongano <
> zelonew...@gmail.com> wrote:
>
>> Actually I quite like "private_hire" as an access value.
>>
>>
>> Are you suggesting access=private_hire as a tag?  That would not be
>> consistent with how taxi services are tagged.  We don't use access=taxi, we
>> use amenity=taxi + taxi=*.  By that logic, the access tagging should use
>> private_hire=*, and probably with some value of amenity=.
>> ___
>> 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 - Rideshare Access

2020-10-31 Thread Joseph Eisenberg
It's almost never standard to use access=bus or access=taxi, it's
bus=yes/no/designated + taxi=yes/no/designated added to another feature
like a highway=* or amenity=parking

I agree with the idea of using private_hire=* instead of rideshare=* because
this appears to be a proper British English term for any non-taxi,
privately arranged transport vehicle, and it's not as misleading as
"rideshare" when used on services like Uber and Lyft. Though I would like
to see more British folks weigh in on the correct terminology.

See
https://en.wikipedia.org/wiki/Taxicabs_of_the_United_Kingdom#Private_hire_(minicabs)

-- Joseph EIsenberg

On Sat, Oct 31, 2020 at 10:51 AM Brian M. Sperlongano 
wrote:

> Actually I quite like "private_hire" as an access value.
>
>
> Are you suggesting access=private_hire as a tag?  That would not be
> consistent with how taxi services are tagged.  We don't use access=taxi, we
> use amenity=taxi + taxi=*.  By that logic, the access tagging should use
> private_hire=*, and probably with some value of amenity=.
> ___
> 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 - Rideshare Access

2020-10-31 Thread Brian M. Sperlongano
>
> Actually I quite like "private_hire" as an access value.


Are you suggesting access=private_hire as a tag?  That would not be
consistent with how taxi services are tagged.  We don't use access=taxi, we
use amenity=taxi + taxi=*.  By that logic, the access tagging should use
private_hire=*, and probably with some value of amenity=.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-10-31 Thread Simon Poole


Am 31.10.2020 um 16:11 schrieb Philip Barnes:

...
Also private hire, which need to be booked in advance and have the 
same access rights/restrictions on the public highway as a private 
car. For some reason I cannot fathom, in London private hire are 
called minicabs.


Uber and Lyft are legally private hire so whilst there may be a case 
for access tags covering private hire there should not be a separate 
tag. If different companies use different points at an airport that 
can be covered by operator=*.


I would avoid the term chauffeur as it implies somebody who is part of 
the staff for somebody who also has a butler and a nanny.



Actually I quite like "private_hire" as an access value.


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-10-31 Thread Brian M. Sperlongano
> Also private hire, which need to be booked in advance and have the same
> access rights/restrictions on the public highway as a private car. For some
> reason I cannot fathom, in London private hire are called minicabs.
>
> Uber and Lyft are legally private hire so whilst there may be a case for
> access tags covering private hire there should not be a separate tag. If
> different companies use different points at an airport that can be covered
> by operator=*.
>

Whether such things are called "private hire", "ride share", "mini cabs",
or any other term, this class of transportation is distinctly different
from what is described in amenity=taxi, which is a place where taxis wait
for passengers.

What is being described here is a place where passengers wait for their
privately arranged transportation.  A new key rideshare= is probably not be
the right way to tag such places (and, it seems from your comments, not
even the right terminology in British English).  Perhaps this better fits
under the amenity key, perhaps as simply as:

amenity=private_hire
operator=Uber
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-10-31 Thread Philip Barnes
On Sat, 2020-10-31 at 12:08 +0100, Martin Koppenhoefer wrote:
> Am Sa., 31. Okt. 2020 um 11:36 Uhr schrieb Simon Poole <
> si...@poole.ch>:
> >   
> > 
> >   
> >   If there are actual legal differences between taxi and chauffeur
> >   access somewhere, we could use chauffeur or chauffeur-driven
> > as an
> >   access tag (better suggestions welcome).
> 
> 
> I can confirm that there are such differences, for example in Germany
> (Personenmietwagen vs. Taxi), in Italy (NCC vs. taxi),
> Legislation will probably vary across jurisdictions, e.g. in Germany,
> the Personenmietwagen is not part of the public transport, taxi is,
> in Italy, NCC is considered "servizio pubblico non di linea" (public
> service which is not line traffic).
> 

Much the same in the UK.

We have taxis (Hackneys) which are part of the public transport system,
can use bus lanes and do not need to be booked in advance.

Also private hire, which need to be booked in advance and have the same
access rights/restrictions on the public highway as a private car. For
some reason I cannot fathom, in London private hire are called
minicabs.

Uber and Lyft are legally private hire so whilst there may be a case
for access tags covering private hire there should not be a separate
tag. If different companies use different points at an airport that can
be covered by operator=*.

I would avoid the term chauffeur as it implies somebody who is part of
the staff for somebody who also has a butler and a nanny.

Phil (trigpoint)







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


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

2020-10-31 Thread Brian M. Sperlongano
aws that are required to fully
> contextualize map data but are not represented within it. I don't foresee
> rideshare being default prohibited, so perhaps the example is too extreme,
> but nevertheless the goal is to encode the specific implications of local
> law for a given rideshare vehicle rather than law generally.
>
>
>>
>>
>> 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 <
>> tagging@openstreetmap.org>
>> *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."
>>
> For the possible values, the expectation is that these include typical
> values
> <https://wiki.openstreetmap.org/wiki/Key:access#List_of_possible_values>
> for other vehicle access, such as {yes, no, designated, local,
> destination}. We typically encounter cases where the first two values are
> useful, as noted in the proposal. Cases of "designated" or "destination"
> access for rideshare vehicles are both plausible and possible. Possible
> keys are indicated in the existing Access page.
>
>
>> 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 <
>> 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
>> <https://wiki.openstreetmap.org/wiki/Proposed_features/Rideshare_Access#Case_.231:_Denver_Airport>,
>> 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
>>
>> ___
> 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 - Rideshare Access

2020-10-31 Thread Martin Koppenhoefer
Am Sa., 31. Okt. 2020 um 11:36 Uhr schrieb Simon Poole :

> If there are actual legal differences between taxi and chauffeur access
> somewhere, we could use chauffeur or chauffeur-driven as an access tag
> (better suggestions welcome).
>


I can confirm that there are such differences, for example in Germany
(Personenmietwagen vs. Taxi), in Italy (NCC vs. taxi),
Legislation will probably vary across jurisdictions, e.g. in Germany, the
Personenmietwagen is not part of the public transport, taxi is, in Italy,
NCC is considered "servizio pubblico non di linea" (public service which is
not line traffic).

We likely need both tags, access tags at least for some special situations
and a tag for a business that offers such services. I remember we have been
discussing this in the past on several occasions, but I do not recall what
was agreed. Generally, while this is a common feature/service in Italy,
there aren't probably tagged so many of them, because the cars may not park
on public property (they either drive, wait in/at the car for the client to
return, or return to their garage, at least that's the legal requirement),
and we are far from having mapped a significant part of businesses which
aren't shops. So from a customer point of view, you rather need a telephone
number than a location of their garage, unlike taxi ranks, which are a
spatially interesting feature (you can actually go there and get a cab).

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


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

2020-10-31 Thread Simon Poole
For starters I would oppose using the term "rideshare" for what is a 
taxi/chauffeur service. It should be noted that there are actual 
rideshare organisations and services out there, but uber, grab, lyft 
etc. are not among them, they are simply trying to co-opt a term with 
positive associations for their operations.


Further, real rideshare services don't get special access treatment 
anywhere I know of, outside of vehicle occupancy regulations, which 
isn't surprising as real ride sharing simply involves sharing costs and 
car on a trip that the driver was going to make anyway.


If there are actual legal differences between taxi and chauffeur access 
somewhere, we could use chauffeur or chauffeur-driven as an access tag 
(better suggestions welcome).


Simon

Am 30.10.2020 um 19:42 schrieb Clare Corthell via Tagging:

Hi Everyone,

Thank you for the input and feedback thus far, any outstanding 
commentary is welcome. Amendments to the proposal include a definition 
of rideshare, example companies, and comment responses on the 
Discussion page. In-line comments here.


Anyone who would like to comment or bring up outstanding questions, 
please do so for another week. At the end of next week, this proposal 
could move to voting.


Best,
Clare

On Thu, Oct 15, 2020 at 2:41 AM nathan case <mailto:nathanc...@outlook.com>> wrote:


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?


The legal designation could derive from venue/airport, local, county, 
state, or federal law. Just as u-turns are always technically legal in 
California unless prohibited, while in Washington they are prohibited 
unless permitted, there are local laws that are required to fully 
contextualize map data but are not represented within it. I don't 
foresee rideshare being default prohibited, so perhaps the example is 
too extreme, but nevertheless the goal is to encode the specific 
implications of local law for a given rideshare vehicle rather than 
law generally.


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 mailto:joseph.eisenb...@gmail.com>>
*Sent:* Thursday, October 15, 2020 12:32 AM
*To:* Tag discussion, strategy and related tools
mailto:tagging@openstreetmap.org>>
    *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."

For the possible values, the expectation is that these include typical 
values 
<https://wiki.openstreetmap.org/wiki/Key:access#List_of_possible_values> 
for other vehicle access, such as {yes, no, designated, local, 
destination}. We typically encounter cases where the first two values 
are useful, as noted in the proposal. Cases of "designated" or 
"destination" access for rideshare vehicles are both plausible and 
possible. Possible keys are indicated in the existing Access page.


But you will also need to add a definition of a "rideshare
vehicle", since this will need to be translated for places w

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

2020-10-30 Thread Clare Corthell via Tagging
Hi Everyone,

Thank you for the input and feedback thus far, any outstanding commentary
is welcome. Amendments to the proposal include a definition of rideshare,
example companies, and comment responses on the Discussion page. In-line
comments here.

Anyone who would like to comment or bring up outstanding questions, please
do so for another week. At the end of next week, this proposal could move
to voting.

Best,
Clare

On Thu, Oct 15, 2020 at 2:41 AM nathan case  wrote:

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

The legal designation could derive from venue/airport, local, county,
state, or federal law. Just as u-turns are always technically legal in
California unless prohibited, while in Washington they are prohibited
unless permitted, there are local laws that are required to fully
contextualize map data but are not represented within it. I don't foresee
rideshare being default prohibited, so perhaps the example is too extreme,
but nevertheless the goal is to encode the specific implications of local
law for a given rideshare vehicle rather than law generally.


>
>
> 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 <
> tagging@openstreetmap.org>
> *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."
>
For the possible values, the expectation is that these include typical
values
<https://wiki.openstreetmap.org/wiki/Key:access#List_of_possible_values>
for other vehicle access, such as {yes, no, designated, local,
destination}. We typically encounter cases where the first two values are
useful, as noted in the proposal. Cases of "designated" or "destination"
access for rideshare vehicles are both plausible and possible. Possible
keys are indicated in the existing Access page.


> 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 <
> tagging@openstreetmap.org> wrote:
>
> Hi Tagging List,
>
>
>
> Here is the RFC for the proposal for rideshare vehicle access:
>
>
>
> Prop

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

2020-10-15 Thread 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<https://wiki.openstreetmap.org/wiki/Proposed_features/Rideshare_Access#Case_.231:_Denver_Airport>,
 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<https://eng.lyft.com/how-lyft-creates-hyper-accurate-maps-from-open-source-maps-and-real-time-data-8dcf9abdd46a>
[Image removed by sender.]

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


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

2020-10-14 Thread Joseph Eisenberg
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 <
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
> *
>
>
> ___
> 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 - Rideshare Access

2020-10-14 Thread Clare Corthell via Tagging
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
*
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging