All posts by Neil

Create GTFS data feeds / GTFS Software

Creating GTFS data feeds can mean a couple of things.  It can mean creating the the static General Transit File Specification file which contains the basic information about the schedule, stops, routes with optional information such a fares and maps.  But it can also mean creating realtime status updates (GTFS Realtime) and providing data that shows your vehicles current positions.

Although you can use text editors to create GTFS files or excel templates, the reality is that these are not inherently designed to ensure that the interdependencies between files are maintained and the risk of human error overriding the basic checks remains high.  Additionally, they are not fully integrated with mapping and timetable functions so that there is a lot of switching between software.  If you are an extremely well funded transportation company then you may get GTFS functionality as part of or an add-on to your existing enterprise transportation software package.  But for the majority of other companies, GTFS Software such as AddTransit.com that is specifically designed to create GTFS files and realtime data is the ideal solution.

GTFS software should be simple and easy enough to deliver the basic schedule for a small shuttle bus company while at the same time robust enough to handle complex scheduling and real-time solutions for citywide public transport and interstate/multi-country transit, ferry and airline companies.

This is our aim every day at AddTransit…. to make transportation easier.

Have a great day.

How Real Time Transit Information works

Today, we thought we’d have a quick look at how real time transit vehicle tracking works…

Real time transit information
How Real time transit information works

The diagram above provides a simplistic representation on how vehicles positions are determined and then combined to provide real time transit information on a mobile phone.

Firstly the vehicle typically has an on-board Global Positioning System (GPS) device.  The GPS device uses signals from satellites, telecommunication towers and even local wifi to determine where the vehicle is physically located.  The amount of signals available will depend on the vehicle, it’s location and the specifications of the GPS device.  The greater number of signals that the device has access to, the more accurate it can be.

The GPS device will determine its position in terms of latitude, longitude and also provide a level of accuracy.  The vehicle will then transit the GPS location and some identifying information (e.g. a vehicle id, route id, etc.) via the internet to a computer.

The computer then combines a variety of vehicle’s GPS positions to produce the data in the form of a GTFS real time (GTFS-RT) data feed.  This data feed’s standardized GTFS realtime format makes it easy for Google and the various transit apps developers to display many bus, ferry, train and public transport companies information in a consistent way.  The position can be displayed on laptops, PC’s or tablets.  As the vehicle moves along, the updated position is passed through this process, allowing the end-user to identify the location of the vehicle and make informed decisions about their travel journey.

Well… that’s the simple explanation. We’ll delve into the detail in future posts.

Have a good weekend.

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 track a vehicles location 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!