Why there’s no GTFS for curbs (yet)
Curbs can be hard for cities to manage. Here’s how Coord helps.
One of Coord’s flagship APIs is our Curbs API, which provides detailed regulations for loading, pickup/dropoff, and parking in cities across the US.
When we first tell people about this API, they often assume cities already know exactly what the regulations are that govern their curbs. In fact, that’s what we thought when we started Coord! Indeed, in other areas, cities do provide high-quality and standardized open data. For instance, when it comes to transit, most cities support GTFS. So why can’t we just make a standard for curbs (let’s call it “GCFS”) and get the cities to use it to provide the world with free curb data?
It turns out that curb data is more complicated to produce and maintain than you might think. In this post, we compare curbs to transit and other kinds of city data, and explain Coord’s efforts to synthesize our survey data and city-provided open data feeds to produce our Curbs API.
The Story of GTFS
GTFS is one of the biggest success stories in mobility data. In 2005, Chris Harrelson, a Google engineer, worked together with IT managers at TriMet, the transit agency for the Portland, Oregon metro area, to take an export of their schedule data and incorporate it into Google Maps to provide transit directions. The next step was adding transit in four more cities. Naturally, when Chris asked them to give him their transit data, he asked them to all provide it in the same format. In 2006, that format was enshrined as the Google Transit Feed Specification.
Google then put out a call to all public transit agencies to provide their data in this format. Because the format was easy-to-use and publicly specified, it was easy for the agencies to comply. And once they produced data in this format, many other systems started using it. This included other trip planners, like TriMet’s own OpenTripPlanner, but also other use cases. For instance, GTFS made it possible for researchers like David Levinson to analyze transit accessibility in cities across the entire country, which would have been nearly impossible before.
Eventually, users and transit operators continued to extend GTFS to make it more useful and comprehensive. And, since it had many more users than only Google, it was eventually renamed to the General Transit Feed Specification. Today, there are GTFS feeds for hundreds of transit systems around the world, making it the de facto standard for open transit data.
So why did GTFS work so well? A big part of this was the open standard, that was well-specified and available for anyone who wanted to implement it. It was also critical that adopting GTFS have tangible benefits for the data providers: in this case, it let their systems be included in Google Maps, which was already being used by many of their customers. GTFS additionally proved to be very extensible: there have been numerous additions to the standard since its initial launch, which have allowed it to become richer and more useful over time.
Importantly, though, for a transit agency to adopt GTFS, they often didn’t need to generate new data: they just needed to translate their existing data into a standardized form. Every transit agency (hopefully) knows their own schedules; after all, they have to dispatch the vehicles every day! And many of these agencies even made this data available publicly before GTFS existed. Yet having a standardized format made this data incalculably more useful, so much so that it’s hard to imagine how you could possibly share transit data without it.
Who is Responsible for the Curb?
So, let’s say that a city wants to provide open curb data. What part of the city government do we get it from? We could try walking up the steps of city hall, but it would help if we could be a little more specific. It turns out that what you can do at a curb isn’t the province of any one city agency: lots of different properties of the curb, controlled by different departments and even different branches of government, can go into producing curb regulations.
Let’s take Los Angeles as an example. The first things you look at when considering whether or not you can park is probably parking signs. Parking signs and curb paint are produced by the LA Department of Transportation. But you also have to make sure not to block driveways, and LADOT doesn’t control where the driveways are: that’s the responsibility of the Bureau of Engineering. And where are the fire hydrants? They’re maintained by the Department of Water and Power.
LADOT also operates the city of Los Angeles’ parking meters, but that isn’t the case everywhere. Chicago, for instance, infamously sold off its parking meter operations to a private company, which sets rates and provides data.
Finally, in LA (though not San Francisco), you are prohibited from parking at a bus stop. While LADOT does place some of the bus stops in the city, many others are for LA Metro, which is a county agency. Some bus stops in LA are even for buses from other cities — the buses that stop here at Westwood and Wilshire are operated by the City of Santa Monica and the Antelope Valley Transit Authority.
Unfortunately, it’s not enough to know the rules in LA proper: city boundaries can emerge in unexpected places. On this block of La Cienega Blvd, the city of LA owns the parking meters to the right while the city of West Hollywood owns the parking meters on the left. This means that you’d need parking data from two separate governments to cover one street.
This is all to say that there is no one place in the city where you can find the rules for the curb. The source of truth is on the curb itself. Unlike GTFS, where in many cases transit agencies already maintained the necessary data, producing comprehensive curb regulations means connecting to many data sources with different ownership, formats, and update cycles. (That’s not to say it’s impossible for the city to do so — Seattle gets pretty close — but it’s a pretty big task.)
Open Data to the Rescue
Given the number of different data sources, getting accurate curb regulations can be an intimidating task. But open data makes it much easier. When cities share their data with the public, that allows companies like Coord to work with it and make it even more useful. We do sometimes collect data ourselves (for instance, we surveyed curbs in San Francisco and Los Angeles to collect ground-truth data), but we much prefer working with city data when possible. We are big supporters of open data and open standards for that reason.
The thing that cities can provide that nobody else can is a source of truth. Because city agencies are the ones actually setting the rules, printing parking signs, approving new driveways, and putting in bus stops, fire hydrants, and parking meters, they know about what’s going to be on the curb before it gets there — and they have the legal authority to make sure that the curb looks like they want it to. These are things that no private company can replace. But once cities make public the data they already have, companies like Coord can take on the work of making it even easier and more convenient to use.
This is an important point. Coord doesn’t replace open data: we complement it. Just as we work with OpenTripPlanner to extend the open-source mobility ecosystem, we work together with municipal open data to make it more useful and relevant. As we grow our business, we are also extending the reach of city-provided data and helping cities to share relevant information quickly with the private sector.
Doing this isn’t just a matter of aggregating data feeds. We have to build curb maps, transcribe and parse parking signs, and then combine everything we know about a curb (as well as everything we know about each city’s parking bylaws) to produce our API. It’s work like this that adds value to our platform above and beyond what cities have the capacity to offer directly.
Open Standards and API Platforms
As we saw with GTFS, data standards are critical to open data and to building data ecosystems. It is very important that everyone who is interested in curb data is speaking the same language so that the data can be as useful as possible.
This isn’t just important for cities, it’s important for us, too. Coord can only succeed if we work in a mobility ecosystem which any city and any company can join freely, whether they use our platform or not. And so, just as Google choose to publish GTFS as a standard and make it available for anyone to use, we are committed to standardizing curb data as well. This is why we have been working closely with the Alliance for Parking Data Standards to define what data looks like for both curbs and off-street parking lots and garages.
Standardization in any industry takes time, and we are happy to see the first fruits of our and others’ efforts. And, because we built our API to ingest and transform data from so many different sources and formats, we can easily adapt our data and our APIs to standards as they arise and become adopted — -and provide standardized data in all our supported cities at once. This is another way that Coord’s APIs work to support and extend the reach of open data and open standards in mobility.
What’s Next for Curbs?
The story of curb data is only just beginning. A growing number of cities are recognizing the value of coding their curbs. And thanks to the rise in dockless bike and scooter sharing, the sidewalk side of the curb has started to become almost as contentious as the street side in many cities. This promises to make curb data even more complex and valuable.
At Coord, we’re always working to expand our curb coverage, and we are so excited to work together with cities to make their streets more legible to all types of vehicles, from cars to trucks to bikes to scooters. No matter where the data comes from, we love digging into it and making it as useful as we can to anyone and everyone who needs it.
