All posts by Neil

GTFS RealTime Status News

Today (Wed, 3 June 2015)there has been a flurry of news articles about GTFS Realtime Status.

Why? Well, because yesterday in the Google Map’s Blog,  Karen Grunberg the Technical Program Manager from Google Transit announced that they are adding 25+ new location for real-time transit info across six places: U.K., Netherlands, Budapest, Chicago, San Francisco, and Seattle.  She goes on to say “This real-time transit info will let you see live arrivals for buses, metros and subway systems—and even alert you to cancelled routes—so you can better navigate the intricate and unpredictable world of transit in major cities around the world.”

Here’s the link to her blog post (http://google-latlong.blogspot.com.au/2015/06/mind-gapp-for-real-time-transit.html).

Kelsey Campbell-Dollaghan follows on in an article on Gizmodo (http://gizmodo.com/google-just-made-it-easier-to-see-exactly-how-late-your-1708532452) with a couple of nice screen shots showing how a 4 minute delay for  bus trip would be displayed.

So in you’re not online yet, how do you get your cities real-time data online?  Well, in Seattle’s case it helped that Brian Ferris, the developer of the widely used OneBusAway app, was hired by Google (http://www.geekwire.com/2015/onebusaway-creator-brings-seattles-real-time-transit-data-to-google-maps/).  But for everyone else the best way is to create a GTFS real-time transit feed.  GTFS is the acronym for General Transit Feed Specification, the international standard for displaying schedule and other transit information.

If you want to know more about  how to create GTFS realtime status or how to display vehicles positions using GTFS, just contact us.

One final comment: It seems like forever to get to this many cities with realtime data, but in reality Google only launched their realtime transit status service in 2011, only four short years ago (http://googleblog.blogspot.com.au/2011/06/know-when-your-bus-is-late-with-live.html)

Have a great day!

Steam Train Ticket Software – 5 Key Things to Think About

When considering steam train ticket software for your heritage railway, there are many things to think about.  Here’s five that we think are key:

1) Does it do what you need it to?

You need to ensure that the software meets the needs of your business. You’ll need to check that the software handles your fare structure (i.e. Adult, Child, Family, Seniors, Special Trips, Discount Offers, etc.)  Do you need to have passenger manifests or historical reports?  Do you want to be aware when passengers with special needs might need support? Can passengers sit anywhere or travel on any trip during the day, or is there restrictions and does the software support this? You’ll need to identify what you have now, determine what you want in the future, and be aware that some things may need to change.

2) Who will be using it and what training is required?

Many heritage and steam railways are run primarily by volunteers.  This means that any new systems/software must be simple and require minimal training.  Determining who will need to be trained and their level of training, is directly related to the who will be using it and why.  Some users will provide customer service in the form of front desk or telephone operators, others may be managing boarding and seating, whereas others will be more concerned about the accounting or future projection of demand.  Be sure you know who will use the software, the type of training they require and understand that volunteers will have restricted and often, differing availabilities for training.

3) Where will the software be installed?

In the old days, software was created “bespoke” or individually built for each customer.  The software was then installed on personal computers, tills/cash registers and run either standalone or over a network.  This had significant upfront cost and with limited budgets meant that upgrades were often deferred indefinitely.   Today software is typically available via the internet with data stored in “the cloud”.  Access to the software is via WIFI or 3G/4G services meaning that you are no longer limited to specific locations.  This allows additional “ticket offices” up and down the line that only require a wireless connection and iPad, tablet or PC to operate.  It also allows passengers to purchase their tickets online and reservations to be checked while the train is moving.  The software is automatically upgraded for all users, meaning you always have the latest version.

4) Cost

Cost has been left until now (number #4), because although budgets are always limited, the first three reasons will determine the total cost.  The total cost must include the upfront, ongoing and organisational costs when choosing steam train ticket software.  The software costs can be structured a number of ways including the number of users, a periodic fee (e.g. monthly or annual) or a one-off cost with maintenance upgrades.  However, it is often the hidden costs of 1) the functionality that is available, 2) the users and time/effort and training, and 3) the way that the software is deployed, that will end up having a much greater impact on the day to day running of your railway.

5) Other factors

Of course, there are a variety of other factors that will affect how you choose which steam train ticket software is right for you.  They include the level of vendor software support and how passionate they are about steam/heritage vehicles, the current software you have and if it is truly “upgradeable” when the hidden costs are calculated,  and then more emotional factors such as “I like the way the screen does this”.  Be careful when considering other factors, as although they may seem important, the real consideration should always be passenger and team experience and the best return on your investment.

That’s all for today.  Have a great weekend.

Want to Create GTFS Data? What’s in GTFS feeds?

Create GTFS - General Transit Feed SpecificationHave you ever created a GTFS data feed and wondered what’s inside?  Well here’s a quick run down / lay persons guide….

A GTFS (General Transit File Specification) file is a group of files that have been “zipped”.  “Zipping” a file is a way of compressing a group of files or directories into a single file.  This makes the total file size smaller and quicker to copy around.  It also means the person who is transferring the zipped file only needs to think about the single zipped file, rather than having to remember all the files that have been compressed inside it.

The GTFS file will contain a number of required files and potentially some optional files.  The required files are enough to produce basic routes and schedules, whereas the optional files add supplemental information that enriches, supports and (sometimes) simplifies the required information.

The required GTFS files that must be created are:

  • Agency: Describes the company that provides the transit service
  • Stops: Describes where the vehicles pick up and/or drop off passengers
  • Routes: Contains summary information about a route detail (e.g. Jamestown Line, 452 Bus route, etc.)
  • Calendar: Specifies on which days a service runs
  • Trips: Contains information for each trip that occurs on a route for a particular service day
  • StopTimes: Contains the detailed information about the trip describing at what time the vehicle arrives and departs from a particular stop

You can also create GTFS files that are considered optional:

  • Calendar Dates: This file identifies which days have exceptions to the standard calendar (e.g. Altered services for holidays, additional services, no services, etc.).  Most GTFS feeds will include this file.
  • Fare Attributes & Fare Rules: These two files are used to describe the standard adult fare.  One of the limitations of the specification at the moment is that most transit operators have a variety of fares (e.g. Child, Seniors, Monthly tickets, etc.) and the file specification does not yet cater for these.  Rather than publish partial information, many agencies choose to not include fare information.
  •  Shapes: This file is used to draw the route on maps.  The majority of GTFS feeds will include this file.
  • Frequencies: This file is used to simplify schedules when a trip occurs at regular intervals (e.g. The bus runs every 30 minutes).  This file is typically included when you have a timetable that has a repeatable schedule for a number of hours, as it lessens the data keying effort, reduces the risk of errors.  It also enables the software that displays the information to better convey the schedule  e.g. “Every 30 minutes”, rather than “Next bus 30 minutes, then another in 1 hour”.
  • Transfers: This includes rules for making transfers between routes.  This file is typically included for major transit agencies (e.g. time between platforms or between bus bays), but is often not relevant for smaller agencies.
  • Feed Info: This describes who published the feed, what version of the feed it is and when it expires. The information inside this file is used by people who manage and manipulate the GTFS files. The inclusion of this file is a good idea (though of course, it is still optional).

We’ll discuss each of the files in detail in future posts.

If you can’t want and just need to know more now, the full specification is available here: https://developers.google.com/transit/gtfs/reference

And if you want to create GTFS data, you might way to try our GTFS Editor.  Here’s the link so you can get started: https://addtransit.com/sign_up.php

Have a great day!

GTFS Google vs General – What’s in a name?

For those who are only just finding out about GTFS, there is often a little confusion about what the acronym stands for.  Variations include:

  • General Transit Feed Specification (Correct)
  • General Transit File Specification
  • General Transport (or Transportation) Feed Specification
  • Google Transport File (or File) Specification
  • Google Transit Feed Specification (Historical)

According to Wikipedia, GTFS was first conceived by Bibiana McHugh, an IT Manager at the TriMet transit agency in the Portland metropolitan area (Oregon, USA) and was developed by Google and Portland TriMet.  It was originally known as the Google Transit Feed Specification.

In October 2009, it was proposed by Joe Hughes from Google to change the name from Google Transit Feed Specification to the General Transit Feed Specification.    Joe’s motivation for the change was that “when Google first worked with early transit partners to create the original GTFS spec they gave the document the descriptive title “Google Transit Feed Specification”, since it was simply the feed specification consumed by Google Transit. In the years since then, many more applications had started consuming data in this format, and many transit agencies had begun using GTFS to share their routes and schedules with all application developers, not just Google.”  He went on to say “It’s time to bring the name in line with the current state of affairs.”

Almost six years later and now GTFS is being used for large and small transit agencies, full website and mobile apps, on the majority of the global search engines and to support a variety of uses from accessible schedules to availability of public amenities.

It now truly is a “General Transit Feed Specification”.

 

 

How to get schedules on maps:GTFS-General Transit Feed Specification

Hi all,

Today we’ve published a new How To white paper.  It outlines at a high level what needs to be done to get your schedules on maps, journey planners and apps using the General Transit Feed Specification (GTFS).

GTFS - How to Get Schedules on Maps

Have a look and let us know what questions you have.  Here’s the link:  https://addtransit.com/tools/GTFS Display schedules on online maps.pdf

Have a great weekend!