News and commentary about transit and online information from Trillium
Don’t get stranded! See how late transit runs in Google Maps.
By Seth Churnside on February 2, 2016. No Comments.
Last week a new option was added for public transit directions in Google Maps. You can now choose the last possible trip for the day to get you where you want to go (probably home?). This is a convenient option to check before heading out for the evening, if, for example, you are trying to see if transit will be available when a concert ends. Now you’ll know.
This has been tested on Desktop and iOS version of Google Maps.
Go to post
Apple Maps Expands to Los Angeles
By Chris Perry on January 19, 2016. No Comments.
In December, Apple Maps added transit-directions coverage for the greater Los Angeles region, after adding transit directions for several other regions in summer 2015. I tested the trip planner with several queries and received consistently accurate and descriptive public transportation directions. The range of transit coverage extends well beyond Los Angeles County and into Ventura, Santa Barbara, San Bernardino, Orange, Riverside, and Ventura counties— up the coast as far as Santa Barbara, to the northeast as far as Lancaster, east to Indio, and south to Oceanside. This inclusion of transit systems throughout the greater LA region adds another layer of relevancy to Apple’s incorporation of transit data, allowing riders in the city to reach rural areas, and vice versa, allowing rural communities access to services not available locally.
Go to post
GTFS Today, and Tomorrow
By Aaron Antrim on December 10, 2015. 1 Comment.
Trillium started because of GTFS (the General Transit Feed Specification). Since then, a primary mission of this company has been to facilitate the development and adoption of open GTFS and other transportation data. Today, GTFS adoption has far exceeded critical mass. The Specification has transformed the transit software marketplace. In conversations with GTFS stakeholders, I hear variants on the question, “Where do we go from here?” I have attempted to articulate a vision that answers this question and contributes to the conversation.
First, a bit of background. In 2005, TriMet sent selected elements from of its schedule database to Google, which then used that database schema as the basis for the Google Transit Feed Specification (GTFS). Today, GTFS datasets are publicly available for at least 1,000 transit agencies. The GTFS datasets that are public may just be the tip of the iceberg. Google shows about 6,200 cities around the world covered with transit information, though routing is not offered for all these cities, nor is it publicly known what data formats sit behind this transit coverage.
In 2010, the Google Transit Feed Specification was renamed the General Transit Feed Specification to accurately represent its use in many different applications outside of Google products. In 2011, a companion specification, GTFS-realtime, was introduced.
After its start with a single consuming application, GTFS now is used in hundreds of applications. As the use of the GTFS has spread and needs for transportation information have grown, the collaborative structure and tools around the specification have not kept pace with its phenomenal success. These are some of the needs that come up:
- A directory to help to disseminate, discuss, and annotate GTFS/-realtime datasets
- Best practices or style guide for GTFS/-realtime
- A neutral, and inclusive home for GTFS & GTFS-realtime, including reference, documentation, training, and tools
A response to each of these needs is outlined below.
A directory to help to disseminate, discuss, and annotate GTFS datasets
3rd party application developers need tools to find GTFS datasets efficiently (say, based on region), and to determine if the dataset is available under a license that is compatible with their intended use. Making it easy to find GTFS and GTFS-realtime data is crucial to support abundance in the application market.
Also, a catalog of GTFS and GTFS-realtime data will make it easy to observe practices and support high-quality communication around Spec use. Early on in the life of GTFS, GTFS Data Exchange, developed and managed by volunteers, emerged as the world’s directory of transit data. Today, the site has become unreliable, in part because it depends on busy volunteers and lacks a dedicated funding stream.
There seem to be a few options emerging that might replace GTFS Data Exchange. One such tool is Transitfeeds created by Quentin Zervaas. Its data inspection features are useful to quickly point to an element in a public GTFS dataset in conversation with other developers. The site also includes features for GTFS-realtime, and links to App Centers. transitland created by Mapzen provides a feed registry which is in its early stages. Its datastore API promises a powerful way of accessing parts of GTFS data feeds via machine-readable JSON.
A data directory is a crucial part of the GTFS ecosystem. We need a directory that is geographically comprehensive, covers both static and realtime data, and includes tools to quickly inspect and share data elements. GTFS Data Exchange shows us that volunteers make amazing contributions, but the community can only lean on their largesse for so long. It’s important for the GTFS community to have a site with institutional funding or a revenue model that can sustain operations over the long-term.
Best practices guide for GTFS (and GTFS-realtime)
The Specification provides a lot of freedom: many fields are optional, and it often allows multiple approaches for describing a given transit service. Mere conformance with the Specification does not equate to good data and a high-quality experience in transit applications. A comprehensive best practices guide would help data publishers to improve the quality of their feeds and the outcomes in 3rd party consuming applications. Armed with best practices, transit agencies can be more confident in the data they publish, and hold their vendors accountable for producing quality data.
Google published the first such guide, Google Transit Data Provider Best Practices, which is organized around the particular needs of trip planning in Google Maps. Arrival estimation systems and timetable generation systems, for example, also consume GTFS and have particular needs for that GTFS data (e.g. vehicle blocks, trip directions). A central compendium of requirements and recommendations, both universal and application-specific, would be very useful for the feed publisher that is trying to publish versatile, useful data. A preliminary documentation effort for best practices has begun in a Google Doc (see GTFS-changes).
Agreement on universal practices would help to eliminate an inefficient workaround that Trillium has observed — some agencies publish a few variations of GTFS datasets in order to satisfy requirements of different systems.
A neutral and inclusive home for GTFS & GTFS-realtime, including reference, documentation, training, and tools
Currently, the GTFS reference, best practices, feed directory, and training materials are distributed across many websites. A certain amount of decentralization is inevitable and even desirable in a vibrant and diverse environment. However, the current highly fragmented information turns away confusion-adverse newcomers. Consolidating resources in one online home, managed by the same organization that governs the Spec, will facilitate wider adoption and more rapid evolution of GTFS and GTFS-realtime.
This central home needs to be a neutral space that allows competing companies to collaborate on an equal level. Google has done a fantastic job as a manager and steward of the GTFS from its beginning. Today, there is an abundance of other applications that use GTFS, and rival companies Apple, Microsoft, and Nokia also utilize GTFS. I have begun to wonder if google.com as the home for official GTFS documentation poses an impediment to some other stakeholders feeling welcome and empowered in the group. It may be largely an issue of optics; nonetheless those perceptions do matter.
What neutral group could offer a home for the GTFS if not Google? Some options include the W3C, International Organization for Standardization (ISO), European Committee for Standardization (CEN), Open Geospatial Consortium (OGC), or a different or entirely new organization. This route would shift GTFS away from Google’s concentrated (and benevolent) leadership. We then open the question and problem of governance. We do not need a whole new governance approach as it has worked well on the whole; instead I advocate it should be amended, not massively overhauled, to preserve the practical elements that have made it work. The organizational structure must continue to allow major stakeholders — organizations and individuals actively working with GTFS — to maintain control over the Specification.
The community of people and organizations using GTFS and GTFS-realtime needs to come agreement about an organizational structure to support these outlined needs, how to pay for and support its activities, and how to govern the specifications.
Go to post
By Aaron Antrim on December 8, 2015. No Comments.
This is a long-overdue congratulations and acknowledgement of Apple’s addition of transit directions in the iOS 9 software that runs on iPhones, iPads, and iPods. In September, this iOS upgrade added public transit directions to Apple’s default maps application.
See more on the iOS Maps page on apple.com or this June 8 article on theverge.com. As of December 2015, Apple Maps supports the following regions (you can see updates to supported regions on apple.com):
- Baltimore, MD
- Berlin, Germany
- Boston, MA
- Chicago, IL
- London, England
- Mexico City, Mexico
- New York City, NY
- Philadelphia, PA
- San Francisco, CA
- Sydney, Australia
- Toronto, Canada
- Washington, DC
I was able to use Apple Maps earlier this year during visits to the SF Bay Area. The coverage of transit networks in Apple Maps is very complete in the area, and my understanding is that Apple has aimed to comprehensively describe the public transportation network in every region that is covered.
There are some really nice touches to the transit directions feature; for example, cartography shows the pedestrian and transit network, and transit station entrance and exit locations are consistently shown (see screenshot below). Through using the app and comparing to the publicly available source GTFS datasets, it quickly becomes apparent that Apple cleaned and augmented the data used for trip planning.
The advent of another major contender in the transit directions space means that riders have more options. We have a new source of design innovation and competition. And, this means that we will have new and important voices and stakeholders in the GTFS community.
Quality transit applications require quality data. And, to scale, this will require abundant data from all over the world. I am looking forward to Apple’s engagement in the open transit data effort.
Go to post