Hi everyone, my name is Artsiom, and I am the OSM Curation Policy Lead at Lyft
“Beginning August 26, the San Francisco Municipal Transportation Agency (SFMTA) will kick off an evaluation with Waymo, and a limited number of commercial black cars that operate on the Uber and Lyft platforms, to provide passenger trips on Market Street, including pick-up and drop-off at up to seven specific locations on Market Street during designated hours” source (1,2)
We are trying to find the correct solution for implementing this in OSM data. We have made several attempts to adopt this update in OSM, but it seems we haven’t found the appropriate solution yet.
Currently, we tagged the ways as livery:conditional=yes @ (Mo-Su 19:00-06:00)(OSM link) because only drivers with a livery license, not all ride-share drivers, are allowed to bypass Market street restrictions.
If anyone could suggest a more appropriate scheme or share examples of how such specific restrictions could be applied, it would be greatly appreciated.
The earlier use of rideshare:livery:conditional=* seems less risky to me. “Livery” is a very overloaded word. It just means a fleet vehicle. Depending on the context, it can refer to taxis, limousines, canoes, airplanes, or horses.
Off the top of my head, do any airports have similar programs that allow only a certain subset of a ridesharing platform’s drivers to serve the airport? Could this be folded into the permit=* tagging scheme somehow?
Would the taxi schema be appropriate? Livery to me also means train car stock and such. I feel like the permit might also be appropriate. Just a few ideas here.
If the street is off-limits to cars otherwise (e.g. something like motor_vehicle=no), then I feel an exception from that rule would have to use the motor_vehicle:conditional tag in the form “yes @ something” - see examples here motor_vehicle:conditional | Keys | OpenStreetMap Taginfo
The earlier use of rideshare:livery:conditional=* seems less risky to me. “Livery” is a very overloaded word. It just means a fleet vehicle. Depending on the context, it can refer to taxis, limousines, canoes, airplanes, or horses.
Off the top of my head, do any airports have similar programs that allow only a certain subset of a ridesharing platform’s drivers to serve the airport? Could this be folded into the permit=* tagging scheme somehow?
I’m not sure if we have ever encountered such strict regulations from any facility before. Otherwise, we would have addressed the issue of marking these exclusive pathways much earlier.
Regarding the permit, the version that comes to mind is something like this:
This indicates that the rideshare permit is conditional and applies to black cars during the hours of 19:00 to 06:00 from Monday to Sunday
Would the taxi schema be appropriate? Livery to me also means train car stock and such. I feel like the permit might also be appropriate. Just a few ideas here.
Regarding the taxi schema, did you mean a schema similar to the one described in the approach outlined here?
If the street is off-limits to cars otherwise (e.g. something like motor_vehicle=no), then I feel an exception from that rule would have to use the motor_vehicle:conditional tag in the form “yes @ something” - see examples here motor_vehicle:conditional | Keys | OpenStreetMap Taginfo
Thanks for the reference. A scheme like below seems like could fit
motor_vehicle:conditional=yes @ (Mo-Su 19:00-06:00 AND rideshare_black_car)
Another question that arises is about the multiple turn restrictions across Market St (example), which have an except key. However, we don’t have an appropriate value to allow the movement of a special category. Do you think using an except value like black_car or rideshare_black_car would be appropriate if we proceed with one of the approaches mentioned above?
So not all taxis are allowed, only a very specific subset? Sounds like:
motor_vehicle=no - Because normally no motor vehicles are allowed, right?
motor_vehicle:conditional=private @ (Mo-Su 19:00-06:00) - Because during this time only a very specific subset of motor vehicles are allowed
private={the specific subset} - Sounds like this would need to be some very specific value like waymo_lyft_uber_black_car. Also if private is not be a clear enough subkey here, perhaps it would need to be motor_vehicle:private.
Ideally not. In OSM terms, access=permit means a permit that “is routinely granted to everyone requesting it”. That’s clearly not the case here. It sounds like only a very specific group of drivers are allowed and it is definitely not a permit that just anyone can obtain.
That was the original idea, but it immediately got diluted. It isn’t a good idea to hide nuances like that behind such a common word. The documentation is simply inaccurate at this point. Everything tagged permit=* is likely a permit that takes more than asking nicely to obtain, not to mention permit in the context of the street parking scheme. Even the photo that accompanies the article proves this point:
The trend only seems to be continuing, so I think it’s time to finally rework the documentation somehow.
private seems counterintuitive to me. San Francisco also has lots of fixed stops for private company shuttles, but these are vehicles that serve the public.
rideshare=* is already used all over the country. rideshare=permitpermit=black_car seems to capture the essence of this program.
Well it was never supposed to mean just asking nicely. It has always been for a permit that required some sort of registration process, it’s just that the process is open to anyone. Anyone can register two weeks ahead of time. But in this situation:
I don’t know what’s involved in getting a livery license (or what that even means), but I’m guessing it’s a fair bit more involved than just registering two weeks ahead of time?
Yeah maybe it is a bit weird. My thinking was that it’s the vehicles that are private, not the people getting rides, hence motor_vehicle:conditional=private not access:conditional=private.
Hmm. No mention on the access wiki page. What does it mean and how is it different from taxi=*?
A residential parking permit could even require buying a house!
To be clear, I’m not suggesting access=permit or motor_vehicle=permit or motorcar=permit. To satisfy rideshare=permit, you’d already have to count as a ride sharing vehicle. The permit is on top of that.
Hm, tourist buses are usually private livery vehicles too, but they serve customers, so we have a separate tourist_bus=* key for them.
rideshare=* is about ride sharing (ride hailing, app-based ride) services. Uber, Lyft, and Grab are the best known, but I’ve encountered dozens of smaller services at airports.
I don’t think we should conflate taxis with ride sharing services. Airports are notoriously strict about only taxis using taxi lanes and taxi stands, while ride hailing services are relegated to a spot off the side, an amenity=car_pooling at most. Downtown San Francisco is like that too: for years, Market Street has been explicitly open to taxis but not to ride sharing services. I’d think this is similar to all those airports, where the difference between a taxi and a ride sharing vehicle is more than a coat of paint or a permit type.
The taxi=* scheme came about because there are a number of other kinds of informal transportation services. I guess people were concerned about proliferating access keys, but that’s kind of a lost cause at this point.
Agree with you that’s the situation sounds more like private than permit. Permit would require in.my understanding that everyone who offers paid driving services can ask for a permit and would get it granted. Not only certain big players. Like “Uncle Bills Airport pickup” could get it as well.
I consider these basically taxi companies that are trying their best to convince us that they are somehow special and different. Back when these services were new and exciting I guess I’d say “I took an Uber” rather than “I took a cab”. These days I call them all cabs or taxis because the experience is functionally the same. I don’t think I’ve ever heard anyone say “I took a rideshare”. Wikipedia claims that “the vehicles used in ridesharing/ridehailing service are called app-taxis or e-taxis”, though I have no idea how reliable that is. I’ve never heard those terms used either.
This is a fair point. Given the different rules for traditional taxi companies vs Uber, Lyft, etc, I can see how a separate tag is needed. I guess if people really do call them rideshares then rideshare does the job. I’d have probably gone with something else like rideservice since there’s not really any sharing involved. Anyway I added a wiki page so at least it’s documented.
Huh, I’ve never heard anyone call these taxis before. Once recently in Colombia, I ordered a ride through one of these apps, only for a moonlighting cab driver to come pick me up. But it doesn’t work the other way around: a more typical Uber driver, lacking a taxi medallion, can’t act like a taxi without facing a steep fine or worse.
Indeed, the author of the access=permit proposal explained that the tag is meant to be an in-between state between a free-for-all and a restrictive regime where the property owner can arbitrarily grant or deny access:
I favor ‘access=permit’ since it is succinct and expresses the intention that a permit is required. ‘access=private’ does not convey the idea that permission is routinely granted. ‘access=permissive’ does not convey the fact that permission must be obtained. One alternative that was suggested was ‘access=no foot:conditional=permissive @ permit_holder’ - but that tagging is surely not widely accepted.
He was focused on mapping protected areas that require permits in order to manage the volume of foot traffic. Even if the permit is easily obtainable – a quirk specific to certain park operators but ironically not the common case accidentally highlighted in the documentation – the operator still reserves the right to refuse additional permits over a certain limit or rate, or outside a predesignated time of year.
SFMTA’s purpose is analogous: to manage the volume of vehicular traffic. However, reading the announcement more carefully, I agree that permit isn’t quite accurate. All they’re doing is opening up specific pickup/dropoff locations to all vehicles associated with these three services during certain times of day.
Presumably they still require any Waymo/Uber/Lyft driver to vacate Market Street as soon as possible after the pickup or dropoff. So that makes it something like rideshare:conditional=destination @ (…). Unfortunately, SFMTA has assigned different operating hours to Waymo than to Uber and Lyft. So the condition will need to indicate not only a time but also an operator, something like:
rideshare:conditional=
destination @ (operator=Waymo AND 09:00-16:00, 19:00-06:00);
destination @ (operator=Uber AND 19:00-06:00);
destination @ (operator=Lyft AND 19:00-06:00)
This also takes care of any concern about Uncle Bill’s.
Or if they’ll continue to post these restrictions only as turn restriction signs rather than selective restriction signs, then we’d simply tweak a bunch of existing turn restrictions, like this turn restriction that I tagged except:network=Muni;SamTransexcept:network:wikidata=Q1140138;Q7407040 based on this sign:[1]
Uber was originally called UberCab and their goal was to create a superior taxi service. The driverless variants are called robotaxis. It’s not exactly a stretch.
Anyways, for the purpose of this discussion, we still need to explicitly differentiate Waymo, Uber, and Lyft individually as operators. Meanwhile, what the city calls taxis can serve the street without any time or destination restriction. There’s over a dozen taxi companies that would have to be included in any tagging, and plenty more transportation companies to prohibit explicitly if we accept an expanded definition of taxis. Much simpler to distinguish “ride sharing” services, even with the euphemism.
No worries, you already convinced me that would be a bad tagging idea. I was just defending my use of the word taxi in everyday speech . Which is of course drifting off topic. Carry on.
Regulations can vary from state to state, but in the case of California, a separate license is required. This license allows you to work on your own vehicle within a specific subset of black car services related to ride-sharing or other carriage services
We need a separate tag because, in some places, there are exceptions for rideshare services that do not apply to taxis. For example, at Boston Logan Airport, there is a situation where the left turn restriction does not apply to buses and rideshare services (42.36926, -71.02863,
This is not ideal due to concerns: ‘private’ seems counterintuitive. San Francisco also has many fixed stops for private company shuttles, but these are vehicles that serve the public
4. rideshare:conditional= destination @ (operator=Waymo AND 09:00-16:00, 19:00-06:00); destination @ (operator=Uber AND 19:00-06:00); destination @ (operator=Lyft AND 19:00-06:00)
This suggested approach is clearer and more understandable, avoiding concerns and conflicts between the types of motor vehicle classifications, whether private or permitted.
However, the most significant issue is that not all Lyft and Uber cars are allowed during this specific period, only Lyft and Uber Black cars.
What do you think about the scheme suggested below?
rideshare:conditional= yes/destination @ (operator=Lyft AND 19:00-06:00 AND black_car); yes/destination @ (operator=Uber AND 19:00-06:00 AND black_car); yes/destination @ (operator=Waymo AND 09:00-16:00, 19:00-06:00)
For the specified turn restrictions, we will add
except:conditional= rideshare @ (operator=Lyft AND 19:00-06:00 AND black_car); rideshare @ (operator=Uber AND 19:00-06:00 AND black_car); rideshare @ (operator=Waymo AND 09:00-16:00, 19:00-06:00)
to allow rideshare vehicles to turn onto Market Street
I don’t think we should use black_car to mean Lyft Black and Uber Black, mainly because black car means different things in different cities – quite literally the opposite thing in New York City versus London.
TNCs already technically aren’t operators, let alone Lyft Black and Uber Black, which are a service class from a rider perspective and a certification program from a driver perspective. It isn’t quite enough to drive a qualifying car model. Can we model them as more specific networks or brands?
I have no idea what conditional syntax we should use for a network value that contains a space. I’m concerned that brand="Lyft Black" would get misinterpreted as a brand= condition followed by the comment "Lyft Black". Based on this discussion, I created Lyft Black (Q136550451) and Uber Black (Q136550335) items on Wikidata, so I suppose we could skirt that issue using @ (brand:wikidata=Q136550451 AND 19:00-06:00).
For some of the turn restrictions, like this no right turn restriction from northbound Van Ness, you’ll probably need to include all the other exceptions as well. Otherwise, I think it would technically mean that buses and bikes are prohibited during the times when ridesharing is permitted, or something like that.
I have no idea what conditional syntax we should use for a network value that contains a space. I’m concerned that brand="Lyft Black" would get misinterpreted as a brand= condition followed by the comment "Lyft Black". Based on this discussion, I created Lyft Black (Q136550451) and Uber Black (Q136550335) items on Wikidata, so I suppose we could skirt that issue using @ (brand:wikidata=Q136550451 AND 19:00-06:00).
To conclude this topic, we will implement changes as suggested by your scheme, using brand definitions based on Wikidata for such cases. In the future, if another consensus would be found - I’ll be glad to participate in the discussion and implement the changes. Thanks for your input
rideshare:conditional=yes @ (brand:wikidata=Q136550451 AND 19:00-06:00); yes @ (brand:wikidata=Q136550335 AND 19:00-06:00); yes @ (brand:wikidata=Q15330 AND 09:00-16:00,19:00-06:00)
except:conditional=bus; bicycle; rideshare @ (brand:wikidata=Q136550451 AND 19:00-06:00); rideshare @ (brand:wikidata=Q136550335 AND 19:00-06:00); rideshare @ (brand:wikidata=Q15330 AND 09:00-16:00,19:00-06:00)
Thanks. By the way, the colon in brand:wikidata inside the conditional is unusual, so be sure to test the behavior of mainstream routing engines/profiles after some time to make sure it doesn’t break any conditional restriction parsers out there.
. Which is of course drifting off topic. Carry on.