Bus Stop IDs on Google Maps

[Devin Braun]

San Diego MTS is exploring the option of using the Stop ID numbers to
provide faster access to real time bus arrival and departure
information via the regional 511 transit information system.
Currently, passengers can call and tell the 511 system what stop they
are at by saying the intersection name or point of interest. As one
can imagine, this can be difficult if the computer doesn't recognize
the name of the street from one's voice. If MTS posted the stop
numbers on each bus stop, passengers can input the stop number instead
of saying the intersection name, saving a lot of time.

Currently, Google Maps gives the Stop ID number in the public
transportation directions (if it has been specified in the feed),
however, would it be possible to also include the Stop ID Number in
the bus stop info windows on Google Maps? This would make it easy for
a current or prospective passenger to find the Stop ID number near
their origin or destination in order to get real time arrival
information via cell phone.

Thanks,

Devin Braun
San Diego MTS

[Joachim Pfeiffer]

Devin,
Looking at the problem, my opinion is that the best configuration for covering stop data for real-time passenger information is to provide queries for route and stop data along with queries for estimated arrival/departure times of transit vehicles approaching a stop. As you will need to build a web service to provide the real time feeds on estimated arrival/departure times, it is not a great extra effort to also cover routes and stops with separate queries from clients such as mobile phones. In this configuration, you would also avoid discrepancies in the stop baseline data in Google Maps vs. your currently valid schedule. Google Maps and your web service will be hard to keep synchronized, due to the turn-around time of updates to Google Maps when a new schedule with changes to the stops baseline data might be in effect. I recommend a visit to TriMet's web service and how they built their real-time passenger information feed, at http://developer.trimet.org/ws_docs
JP

[Devin Braun]

Hi Joachim,

I agree with you that we could create a feed as part of a developer
API of estimated arrival times and bus stops. But this is a different
issue much smaller in scope. Our local regional planning agency
already has a system in place where one can call and get bus arrival
and departure times for buses equipped with AVL. These times are only
available through voice prompts by calling 511 (not available on a
website). We are going to place stop numbers on each bus stop sign so
that passengers can call the 511 system and simply type in the stop
number to find the next bus arrival times to that stop. I have seen a
similar system in use in Montréal and San Diego Transit tried this
several years ago on some limited corridors with success.

The Public Transit trip plans that Google Maps returns already include
these stop numbers, so it wouldn't be much of a stretch to include
stop numbers in the info window that opens when clicking on a stop on
the map. Plus, these stop numbers don't change from one service
change to another, so having a static layer that isn't updated
frequently isn't a major downfall.

We have created our own stop finding application for this purpose
(http://www.mtsotp.com/mts/stop_finder/stop_finder.cfm) - but to make
Google Maps more transit friendly than it already is, I am requesting
a slight modification to the UI.

Thanks!

Devin Braun
San Diego MTS

On Feb 28, 6:24 pm, "Joachim Pfeiffer" <joachim.pfeif...@gmail.com>
wrote:

> Devin,
> Looking at the problem, my opinion is that the best configuration for
> covering stop data for real-time passenger information is to provide queries
> for route and stop data along with queries for estimated arrival/departure
> times of transit vehicles approaching a stop. As you will need to build a
> web service to provide the real time feeds on estimated arrival/departure
> times, it is not a great extra effort to also cover routes and stops with
> separate queries from clients such as mobile phones. In this configuration,
> you would also avoid discrepancies in the stop baseline data in Google Maps
> vs. your currently valid schedule. Google Maps and your web service will be
> hard to keep synchronized, due to the turn-around time of updates to Google
> Maps when a new schedule with changes to the stops baseline data might be in
> effect. I recommend a visit to TriMet's web service and how they built their
> real-time passenger information feed, athttp://developer.trimet.org/ws_docs

[Joe Hughes]

Don't worry, Devin, it's coming. :]

Joe