Agencies Managing Transit Data

[Jerry J]

Just curious if there are any people here working for transit
agencies, and if so, what software/webapp do you use to manage your
data?

Would you use something as simple and general as phpMyAdmin or
something very specific to managing your schedule/route data if you
were managing this data?

[KC Metro]

King County Metro, in Washington State is a mid – sized Transit agency
of roughly 1500 vehicles. Schedule data creation is performed via
Giro’s Hastus package. Stop and route sequence data is created via in
house applications. Street network data is created and maintained
with ESRI GIS products. All data streams are stored in an Oracle
database, which also provides data for downstream users inside and
outside of King County Metro. Although phpMyAdmin could conceivably be
used for some aspects of transit data management, our IT department is
able to leverage existing enterprise – level assets, which currently
are not open source oriented tools.

[Joe Hughes]

I too am interested in hearing from agency folks on this list.
There's a pretty big range of practices for generating GTFS--here are
some that I know about (roughly in order of increasing agency size):

* Bob Heitzman's Excel macros
* Hosted, web-based tools offered by Trillium Solutions and NextInsight
* Export functionality built into Trapeze and GIRO software, often
supplemented by custom tweaks (for instance, at the MassDOTdev
conference the guy from the MBTA said that they use GIRO HASTUS, with
an additional MS Access (?) database for post-processing)

I know less about practices in agencies that aren't exporting GTFS,
because they seem to talk to developers less. :]

Joe

> --
>
> You received this message because you are subscribed to the Google Groups "Transit Developers" group.
> To post to this group, send email to transit-d...@googlegroups.com.
> To unsubscribe from this group, send email to transit-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/transit-developers?hl=en.
>
>
>

[Roger Slevin]

Don't forget open-source converters as used in the UK, New Zealand and
elsewhere
- there's the TransXChange to GTFS converter that Joachim Pfeiffer has
developed and is freely available, and a bespoke converter for the UK's
ATCO.CIF format that Mike Ness has created and can be made available to
others if it is relevant.

Roger

[Capital District]

At CDTA, in Albany, NY. We export the data from Giro's Hastus directly
to the gtfs format.
We then import it into sql server and add a few other data items from
other sources.
We then run it through a few scripts to add data, edit some data and
create a few new files for out iPhone application.
We then just export it from there.
The lay over step allows us to make the data a bit more google/
developer friendly and keep the data in Hastus the way it is for our
planners/schedulers.
For example we just recently went through and added new customer
friendly headsigns to the sql server database, but we did not want to
update Hastus with this same information.

Overall though when a schedule change happens we can generate a new
feed in about an hour.
An if we can take some of the manual steps out of the process, I'm
sure it coule be even faster.

Hope this helps.
-rich

[David Turner]

On Wed, 2009-12-23 at 16:41 -0800, Joe Hughes wrote:
> I too am interested in hearing from agency folks on this list.
> There's a pretty big range of practices for generating GTFS--here are
> some that I know about (roughly in order of increasing agency size):
>
> * Bob Heitzman's Excel macros
> * Hosted, web-based tools offered by Trillium Solutions and NextInsight
> * Export functionality built into Trapeze and GIRO software, often
> supplemented by custom tweaks (for instance, at the MassDOTdev
> conference the guy from the MBTA said that they use GIRO HASTUS, with
> an additional MS Access (?) database for post-processing)

Here in New York, I use custom Python scripts (on my github, if you like
to parse the undocumented STIF and RTIF format that the MTA gives us
data in.

We used to import the shapefiles for route shapes into postgresql, and
then use them to generate shapes.txt. We don't do this anymore because
there are shapefiles only for full bus routes, and sometimes buses run
short routes. We could use shape_distance_traveled to fix this up, but
for some reason I thought it would be better to do it manually, and it
totally didn't work. I may revisit this decision.

The scripts take several hours to run.

[Devin Braun]

San Diego MTS wrote custom scripts (written in OIG/d) to export from
HASTUS v2004 (the automatic export option is not available in this
version of the software). There is also a custom Java app which takes
the exported text files and does some post-processing on the
stop_times.txt and shapes.txt files in order to match the spec's
requirements for distances and shapes.

North County Transit District shares our HASTUS installation and uses
the same methods.