Biking directions added to Google Maps

Google added biking directions to maps.google.com on Wednesday.  The route planner considers bicycle facilities, topography, intersection quality, and traffic to plan directions.  Detailed bicycle infrastructure information (bike lanes, boulevards, etc.) is available for about 150 cities in the U.S.  I am already finding the feature enjoyable and useful for navigating Portland’s streets on my bike.

This will be tremendous for making biking infrastructure more visible.  Maps and online information are an important, and often overlooked component of the transportation system.

I’ve already received one phone call from a client asking how they can integrate their region’s bike lane data in Google Maps.  Google’s public announcements don’t offer a lot right now.  Near as I can read their answer is to say “stay tuned.”  Maybe a U.S. version of Map Maker will allow more data to be included down the line.

Here’s a screenshot of my bike route to work.

biking-directions

Around the web:

Simplifying the Open Transit Debate: White Paper

Mentor Engineering released a white paper “Simplifying the Open Transit Debate.”  For the curious, you can download a PDF, or read an HTML version.

The paper summarizes many of the benefits of open data — time saved, agency image benefits, improved customer service, ridership increase, and free application development.

It misses some important points though.  One is that open data facilitates greater and more successful innovation because it provides opportunity for low-cost (or free) failure.  Think of it this way: more developers = more projects/experiments/innovation = competition between them = successes and failures.  This idea is further developed in Thoughts on ‘Here Comes Everybody: The Power of organizing without organizations’.

Also, I wish the paper provided a more thorough and direct discussion of what they offer as an often cited disadvantage of open data:

The only negative some agencies see in providing their data to the public is the elimination of potential revenue from selling the data to developers. However, because the data is generated by taxpayer-funded agencies, the general consensus is that agencies should not profit from this data. Agencies that kept their data closed in hopes of selling it, such as New York City’s MTA—who recently released their data—have experienced extensive backlash from both the developer community and transit passengers.

Are there agencies that profit from selling their data?  I think a few may generate revenue from advertising on their websites.  However, this revenue is usually insignificant, and should be weighed against the benefits of open data.  3rd party applications and information sources may lead a few eyeballs away from the agency website and compromise ad revenue, but they are likely to support ridership and fare revenue growth.

Oh, and I was pleased an interview I conducted with TriMet’s CTO and IT Manager for GIS and Location Based Services was cited in a few places in the paper.

SF Streestblog nerds out on open transit data

Excuse the late post, but in case you missed it, SF Streetsblog ran a pice on “How Google and Portland’s TriMet Set the Standard for Open Transit Data” in early January.

They interview some key players who give a window into the evolving practice of opening transit data.  Check it out if you haven’t already.

One guide for many agencies and many modes

Today, Trillium Solutions finished creating the Humboldt County Transportation Guide [Download PDF].  It’s headed for the printer and bound for buses, transit centers, businesses, and social services locations next week.

Humboldt-County-Transportation-Guide-FINAL-cover

Before this guide, printed schedule information and maps for each agency were available separately.  That made it more difficult for passengers to plan inter-agency trips.  It also meant that passengers weren’t always aware of all the services available.  Imagine, if you will, if you had to consult a different map or road atlas for roads maintained by each city, county, and the State DOT-maintained highways — in short, use a different information source according to the agency responsible for maintaining the roads you are driving on. Probably, if this was reality, driving would not be nearly as popular as it is today!  Or, imagine if you had to go to every individual airline’s website to search for available flights and their prices instead of using Travelocity.com or something similar.

The twenty-eight page guide includes timetables for five fixed-route transit services in the Humboldt Bay Area.  The overview map also shows connecting regional services, including the local transportation service in adjacent counties, and Greyhound and Amtrak service.  Multiple agenies’ services are shown in many of the detail maps that highlight particular cities.

county-overview

In addition, the service guide responds to findings from the Humboldt County Coordinated Human Services Transportation — Public Transit Plan by showing flexible and on-demand human services transportation services in the same guide.  Below is an overview map.  It is accompanied by tables of transportation services that show eligibility requirements, service area and hours, accessibility features, contact, and other pertinent information for each service.

human-service-transpo-map

OpenTripPlanner project

TriMet, The Open Planning Project, and developers of FivePoints, OneBusAway, Graphserver, and byCycle are working on an ambitious open-source multi-modal trip planner (the project name is OpenTripPlanner).

When finished, the multi-modal trip planner software will plan journeys by a combination of biking, walking, and transit in the areas where it has been implemented.  For regions that wish to implement the trip planner, they will need to use in-house resources or hire a firm to install, host, and manage the software.  Information on transit service, walking routes, and biking routes in the necessary formats will be one of the most important prerequisites for implementing the open-source multi-modal trip planner.

Check out the OpenTripPlanner site or join the developer discussion list to learn more and follow along with the effort.

Trillium clients launch on Google Transit

In the last eight weeks or so, several Trillium clients have launched on Google Transit.

As you can see, a busy season.  There are more to come soon.  Note that most of these agencies have chosen to make their data available at gtfs-data-exchange.com and the PublicFeeds page for developers to access it and build applications that help people use transportation services.

Google Maps feature watch: nearby transit stops in search results

Check it out… now, when you search for a location at google.com, if the location is found in Google Maps, and transit data is available for nearby service (read: on Google Transit and publishing Google Transit Feed Spec data), the search results also return the nearest transit stop.  It’s harder to imagine a more subtle but promisingly effective way of marketing transit.

roadside-attraction

Via the Official Google Blog: “This week in search 12/11/2009.”

CityGoRound.org, a new transportation application directory

The folks at Front Seat, who’ve brought us WalkScore, among other great projects, have done it again.  Today, Front Seat launched CityGoRound.org

citygoround-screenshot

When public transportation information was added to WalkScore, FrontSeat realized they needed more open Google Transit feed data to make the feature useful in more markets.  CityGoRound makes it easier for people to find transportation applications for their area (see example of the localized search for Portland).  The website also highlights the need for open data to make these applications possible.  They recognizes and thank the agencies that provide open data (pulling this information from GTFS Data Exchange).

The project team were several hard-working transit and open data advocates: Brandon Martin-Anderson, Jehiah Czebotar, Dave Peck, Josh Livni, and Joe Hughes, who put this together in a few weeks.  The site is open source to facilitate its implementation in international markets.

Transit agencies with open data: Put a link to your localized City-Go-Round page on your agency website.  One of our clients is already planning to do this, and we’re planning to reach out to more clients to encourage them to refer their online customers to this useful resource.

You can also read about CityGoRound.com at the Headway Blog.  And there’s the Front Seat press release.

Rural areas and Google Transit: some findings and opportunities for improvement (Part 2, Intercity service)

This post continues a series of posts on Google Transit and issues that arise for agencies and passengers in rural service areas.  The first post explains the goals and origins of this discussion.  This post addresses that affect longer-distance inter-city transportation services in Google Maps in particular.  Modoc Sage Stage, Trinity Transit, Metrolink and select Amtrak services are a few examples of intercity services that are live in Google Transit.

ISSUE: Queries for travel times more than 48 hours in advance of scheduled service return no results

Some inter-city routes within the project study area operate once or twice each week.  Currently, for these services to be returned in the trip planner, the end-user must query for a departure time and date near to the scheduled time of service.  If the query is for a desired travel time 48 hours or more in advance of the scheduled service, no results will be returned; to someone who doesn’t already know there is service on that corridor, it looks like there is no service available.

We suggested the Google Transit trip planner should search for and return services that are up to 7 days in the future of the desired travel time.

ISSUE: Maximum walking distance threshold prevents display of available transit service

When the origin or destination entered into the trip planner is farther than four miles from the nearest transit stop, no trip options are returned.  We contacted Google Transit Partner Support about the possibility of modifying walking distance thresholds in rural areas.

The recommendation developed with stakeholder input is for the travel to transit stop distance to be increased to 25 miles (that’s a pretty long distance; don’t know if it’s technically feasible). This travel distance to transit can be expected in areas where transit passengers travel over 100 miles to a regional airport in service areas with density of less than 5 persons per square mile, for example. In order to avoid trip planner results where travel-to-transit distance is greater than travel-by-transit distance, the travel-to-transit threshold should be increased for long-distance transit routes.

This issue presents a particular problem in instances where end users query for transit destinations and origins by the name of a city. In Google Maps, the discrete points that indicate the location of rural cities may be a significant distance from actual town centers and transit stop locations (see example below).

weaverville-point

In rural areas, friends, family, and neighbors sometimes drive transit passengers to bus stops if walking distances are significant.  For some commuter rail services, Google has incorporated drive-to-transit directions. This feature may also be useful in rural areas.

Rural areas and Google Transit: some findings and opportunities for improvement (Part 1, Walking)

Earlier, I posted on the availability of the Northern California Google Transit Feasibility Study which Trillium prepared for Shasta County Regional Planning Agency.

Since Google Transit has most been often implemented in larger metropolitan regions, and has more users in those metropolitan regions, trip planner features are (naturally) often geared more towards metropolitan use cases.  One of the purposes of the Shasta County/NorCal Google Study was to catalog issues with the Google Transit trip planner in rural areas and with rural system features — using real data with Plumas, Shasta, Siskiyou, Trinity, and Tehama counties.

You can read the details of issues beginning on page 35 of the Feasibility Study.  For those who would prefer not to download the PDF, I thought I would share some some highlights on this blog.

Originally, my plan was to put the entire discussion of issues in one post.  When I started that project, I realized there was way too much text for one post, so I’m going to spread out discussion into a series of posts.  That will help focus comments and discussion around particular interests and issues.

I don’t want to seem like I’m picking on Google Maps and the transit team.  Sometimes people will zero in on problems and flaws with Google Maps and Transit, and I find myself defending the mapping application and approach behind it, which is to launch early and learn through testing with real users and data.  Building an application of the scale of Google Maps seems a bit like building an airplane in mid-flight (the analogy isn’t originally mine; I borrowed it from an EDS television advertisement) — there are millions of users, at least 40 languages, and lots of complicated data.  It’s hard to build a platform that serves every transit system and user equally well on a global scale.

I hope this feedback helps to improve Google Maps transit directions.  Mostly, I hope that by posting on this blog and inviting comments here and around the web, it will at least improve the overall quality of discussion and feedback for Google Maps improvements.

So, without further ado, the theme of the day is walking as part of Google Maps transit directions in rural areas.

ISSUE: Trip planner returns walking directions instead of available transit option for complete trip or segment

Some travel itineraries on loop routes may involve indirect travel paths and correspondingly long on-vehicle passenger travel times.  Travel times can be longer in rural systems because transit networks are designed for coverage (serving dispersed needs in the area) rather than productivity (building ridership by serving choice riders and commuters).  In cases where the trip planner calculates walking is a faster alternative to transit over all or part of a transit route, the trip planner does display options that minimize travel time, but may add unnecessary walking.

For an example, below: A more ideal display of a trip on TRAX Route 1 (Photoshop mockup, left) and TRAX Route 1 trip as it currently displays (right).

Northern-California-Feasability-Study-final-38

This software decision produces optimal travel itineraries for individuals that do not mind and are able to walk distances of, for example, 0.5 or more miles.  However, the result does not serve the needs of mobility-limited customers, customers with heavy bags, or people in rainy, cold, or wet places would want to avoid exposure to nasty weather.

This is a tricky issue because some passengers (like me) usually want the fastest possible itinerary even if it requires extra walking.  Others do not.  Some ideas that have been discussed with Google and on the various discussion groups with agencies, consultants, and Google are: (1.) including a checkbox to “minimize walking distance” in the Google Transit trip planner UI, or (2.) including a field to specify maximum walking distance.

This issue seems especially tricky.  When I use Google Maps, I see some cases where I wish it suggested less walking and others where it suggested more walking.  Here’s an example where Google Maps should suggest a little more walking and less transit.  It would make more sense to walk directly from the SF Muni F Line to the SF Ferry Building and board the ferry service to Sausalito.  But instead, Google Maps suggests a more round-about tour.  And in other cases, like above, Google Maps suggests walking a fair bit of walking when transit is available almost to the doorstep of the destination.  So I appreciate the challenge of building a system that gives intelligent itineraries when there may be a many factors and considerations at play.

What do you think is the best way to address walking as part of transit directions?

Blog Widget by LinkWithin

Next Page »