Amtrak partners with Google

Advertise with us
Shop deals on ebay
shop deals on amazon
Amtrak Unlimited Discussion Forum

Help Support Amtrak Unlimited Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
The change from Daylight Saving to Standard Time takes place at 3 am (3 becomes 2). So the departure and arrival times for that train leaving New York at 12:20 am would be correct; the train would arrive in Philly before the time change. But the computer seems to be subtracting an hour from the running time even before the time change, giving the trip time of 25 min. And for only $10. I know what I'll be doing on Nov. 3: riding Amtrak from New York to Philly and looking at SpeedView on my phone. ;-)
 
jis said:
GTFS Fare is under development. Current V2 does not support dynamic fares and is not suitable for Amtrak. It is currently designed for representing transit fares and is used by several agencies.

In any case as you correctly point out, for dynamic fare like used by Amtrak the only truly useful fare is the one provided in a specific offer from the CRS as I indirectly alluded to earlier. All that can be provided statically is a range info and that currently cannot be represented in the GTFS Fare documents.
Click to expand...

Correct, as someone who maintains GTFS fares professionally for two transit agencies GTFS only has the ability to display a single fare for a trip (their is a way to program different fare zones, between different areas or stations), so if Amtrak wanted to i guess they could program the highest bucket fare for each segment but I think that would turn passengers away by seeing sky high prices.
 
IMHO, the issue is that the bones of Amtrak's technology infrastructure are more obsolete than what airlines use. One example is that the system needs to be reprogrammed city pair by city pair for each potential system-wide city pair when a change is made to the schedules, such as with the Floridian. This led to the inability for passengers to book Alexandria to points west of Washington, D.C. Another example is the number of steps agents need to use to accommodate a passenger asking for a different room in a sleeping car. It takes an experienced agent to prevent the price from increasing.
 
Steve4031 said:
IMHO, the issue is that the bones of Amtrak's technology infrastructure are more obsolete than what airlines use. One example is that the system needs to be reprogrammed city pair by city pair for each potential system-wide city pair when a change is made to the schedules, such as with the Floridian. This led to the inability for passengers to book Alexandria to points west of Washington, D.C. Another example is the number of steps agents need to use to accommodate a passenger asking for a different room in a sleeping car. It takes an experienced agent to prevent the price from increasing.
Click to expand...
The core system, ARROW, is a one-off based on a mid/late-1970s iteration of Sabre. It hasn't been modified much, just wrapped. Now they've pretty much lost anyone who had any real knowledge of it. To really improve things they need to do a rip and replace, which would be incredibly expensive. I wouldn't trust Amtrak IT to do it any more than I could throw a 1970s IBM mainframe. It would be a dream for an outfit such as Cognizant to do, though. They could run amok since Amtrak IT probably couldn't competently supervise and control them.
 
Yes, Amtrak does need a new reservations system. Our computer gurus can tell us how expensive that it is going to be. Personal experience of more than one medical facility having changed systems give only a thumb nail observation. They had 2 complete computer displays and key boards. Trying to get info from old system to new was awkward for clerks.
Cannot imagine a trip starting on theee old system and ending on the new. + how to handle delays cancellations over that implementation date.
 
west point said:
Yes, Amtrak does need a new reservations system. Our computer gurus can tell us how expensive that it is going to be. Personal experience of more than one medical facility having changed systems give only a thumb nail observation. They had 2 complete computer displays and key boards. Trying to get info from old system to new was awkward for clerks.
Cannot imagine a trip starting on theee old system and ending on the new. + how to handle delays cancellations over that implementation date.
Click to expand...
Ask United. They did such a migration.
 
jis said:
Ask United. They did such a migration.
Click to expand...
Or VIA, they recently replaced their core reservations system with a modern one, though they also call the new one ReserVIA. It was very late and at one point they pulled an already late implementation less than 60 days before the publicly announced implementation date. But they finally got it implemented earlier this year. Even then it wasn't smooth, but it's up.

From what I've been given to understand it is a somewhat customized version of a European rail reservations system. It wasn't built in house, which is seldom done in any type of industry or organization today.

I've been involved in a few core system replacements in my career and they are huge endeavors, are extremely fraught and difficult, take a lot of time and money, and are usually late. The easiest, which wasn't easy, the actual migration was done by a gradual "sell over" to the new system, with both the old and new system running side by side. It took five years after production implementation to complete the sell over. Far more difficult is a straight up conversion, converting all current operations and recent data in a big bang (you convert and load as much data as you can beforehand). Usually over a weekend with all IT staff on deck and biting their fingernails. That's what has to be done with a common carrier's reservations system. You cannot run two reservations systems at once for one carrier.

I am happy I was able to wait to reserve this year's VIA trip until after the new system was implemented, so my reservation didn't have to undergo conversion. I know something of how that sausage would be made, and didn't want to eat it.
 
Last edited:
Yes large migrations are tedious, challenging, and expensive. But that's why tech departments, enterprise vendors, and transition consultants exist. Is a few days of reduced service over a low volume weekend worse than watching the production scheduling system crash and burn, suffering extensive reputational damage, and a massive financial loss over the holidays? Ask Southwest Airlines. Although to be fair to Amtrak what crashed Southwest was adding so much new service it completely overwhelmed their software. It's becoming increasingly difficult to imagine Amtrak ever having to worry about something like that.
 
Last edited:
Devil's Advocate said:
Yes large migrations are tedious, challenging, and expensive. But that's why tech departments, enterprise vendors, and transition consultants exist. Is a few days of reduced service over a low volume weekend worse than watching the production scheduling system crash and burn, suffering extensive reputational damage, and a massive financial loss over the holidays? Ask Southwest Airlines. Although to be fair to Amtrak what killed Southwest was adding so much new service it completely overwhelmed their software. It's becoming increasingly difficult to imagine Amtrak having to worry about something like that.
Click to expand...
I agree with all of that. The system migrations I've been involved with were necessary and justified from both a business need and a technical standpoint. Risk was mitigated to the extent possible within financial, technical and time constraints. All were successful, though some had more issues downstream from implementation than others.

My main point is it's extremely expensive. Still, Amtrak should have replaced ARROW years ago. The ReserVIA system that VIA just replaced was actually of more recent vintage than ARROW.

Despite the expense, I think Amtrak is riding for a very bad fall. In general, systems just age. They accumulate patches, some of which may not be of the greatest quality and perhaps with little or no comprehensible documentation. They are dependent on technologies that become obsolete and unsupported. In Amtrak’s case, all that has to be true, plus Amtrak has lost most if not all technical staff that actually understands ARROW's innards. Amtrak is sitting on a mountain of technical debt that has to be mind-boggling.

"Nice to haves" like displaying multiple dates or improving the way connections are set up aside, IMHO, ARROW is likely increasingly vulnerable to a major crash that Amtrak is probably going to find difficult or even impossible to recover from. It is a hidden problem that is much less visible than the short supply of Superliners or inoperable wash racks, but it is a time bomb of nuclear proportions.

I hope that Amtrak IT management recognizes the risk they are running and has at least some workable plan to mitigate it. But I have very little faith that they do.
 
It looks like Google's train integration is still pretty lacking, for now. It only shows a single train that corresponds to your initial search. Maybe in the future Railforless can pull data from a public API if Amtrak provides one...
 
Mr.Technician said:
It looks like Google's train integration is still pretty lacking, for now. It only shows a single train that corresponds to your initial search. Maybe in the future Railforless can pull data from a public API if Amtrak provides one...
Click to expand...
Amtrak does provide one. It can be accessed through Transitland (among others) at:

https://www.transit.land/feeds/f-9-amtrak~amtrakcalifornia~amtrakcharteredvehicle

It is only schedule data. For reasons described above Amtrak's fare data cannot be shared via GTFS since GTFS does not provide the features necessary to represent dynamic fares even as a static range.

I found this interesting article which gives an overview of available APIs through third party providers that expose data from select railroads, some even including Amtrak:

https://www.altexsoft.com/blog/rail-booking-apis/

Essentially any outfit that interfaces with GDS needs to provide at least an API to make that happen somehow. And Amtrak does interface with GDS.

Anyway, that is all the digging I did in an hour or so,
 

Latest posts

Back
Top