Four connections?

Shop deals on ebay
Advertise with us
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.
PennsyFan said:
How about this one?
CWH-PHL-CHI-LAX-SAN

OR

CWH-PHL-CHI-POR-EUG

OR

CWH-PHL-CHI-EMY-EUG

With the help of the NEC, all things are possible

By the way, Amtrak won't allow you to book any of these connections unless you use the multi-city-trips page
Click to expand...
Unfortunately, there are only three connections in these routes: Philadelphia, Chicago, and Los Angeles/Portland/Emeryville. I think what Anthony is looking for is four connecting cities, not four connecting trains. It would actually end up being five connecting trains.
 
EmpireBuilderFan said:
Unfortunately, there are only three connections in these routes: Philadelphia, Chicago, and Los Angeles/Portland/Emeryville. I think what Anthony is looking for is four connecting cities, not four connecting trains. It would actually end up being five connecting trains.
Click to expand...
EmpireBuilderFan is correct, and even then, it would have to be for two cities that _cannot_ be connected using any less than four. ;)
 
It's entirely possible to create connections of four if you go about it in a roundabout way. You could even do that within the NEC (RTE-WAS-NHV-SPG-BOS), but the key is to to do it with as few connections as possible.
 
OK, Anthony, I think I have one possibility, with a caveat. Here's my possible routing:

WND (Winsor, CT) -> NHV -> WAS -> CHI -> PDX -> EUG

Now, here's the caveat: There is one train that runs between Springfield, MA, and Washington, DC directly, but it runs early in the morning. For a passenger who is going to travel across the country, I don't think they'd take the early morning train, but would wait for a later train that will get them to WAS with as little layover time as possible. The later trains out of Winsor require a connection at New Haven, CT. As far as I know, they don't go all the way through. (One of our NEC experts can confirm or deny this information.)

While this isn't the simplest routing, as far as number of trains, this is the most likely routing.
 
Very interesting information about the scheduling and such... but that caveat is the killer :(

I'm showing just under two hundred possible three-connection itineraries, and though the schedules may not be all that convenient, the fact that the trip can be made in three connections is unfortunately what matters.

Looks like this trip can be made in 3,323 miles:

EUG-PDX (123 miles)

PDX-CHI (2,262 miles)

CHI-SPG (919 miles)

SPG-WND (19 miles)

thanks very much for the info, though!
 
So close. But there's a way around it. Shuttle from Windsor to Springfield, hook up with the LSL Boston side. So you'd have: Windsor, SPG, CHI, PDX, EUG. That's only four trains, so only three connections. Nice shot though. Kudos!
 
Looks like I didn't catch the fact that three connection itineraries haven't worked since the new database went in. :unsure: :huh: :huh:

I just attempted a SAB-SAN or a RUD-SAN and got No connections found! LOL :)

Unfortunately, in my developer-friendly way of prioritizing, this is a bigger problem than the trip counter thing that you all have been begging me to fix. I have learned one useful lesson through all of this, though, and that is to read the log of changes for each version of something that I install. I didn't realize that the jump to a new database version in the same 4.1.x tree would have so much revised syntax. :angry:

I'll get back to y'all on this item this weekend, or maybe sooner. :)
 
Anthony said:
Looks like I didn't catch the fact that three connection itineraries haven't worked since the new database went in.   :unsure:   :huh:   :huh:
I just attempted a SAB-SAN or a RUD-SAN and got No connections found! LOL :)

Unfortunately, in my developer-friendly way of prioritizing, this is a bigger problem than the trip counter thing that you all have been begging me to fix. I have learned one useful lesson through all of this, though, and that is to read the log of changes for each version of something that I install. I didn't realize that the jump to a new database version in the same 4.1.x tree would have so much revised syntax.   :angry:

I'll get back to y'all on this item this weekend, or maybe sooner. :)
Click to expand...
Before you guys bash me for taking an interest in this problem sooner than that of the trip counter being closed, :lol: :lol:

The issue with the trip counter lies in the paging feature that lets you hit "Previous" and "Next" when you display your personal trips. In order for the program to dice up your trips in like 10 or 25-entry blocks like that, it has to give the database a LIMIT number, to say, "start at X trip and end at Y trip for this page". I was doing this using some negative numbers, and the new database upgrade apparently only supports using positive numbers for these values. It seems to be quite a task to look into how to fix this to use positive values, as all of that paging feature work was rather irritating and the code looks like Greek to me after a year. :)

The pathfinder, though, is much more interesting to me because it involved a lot more work, and it's my "baby" :D .... I like to see it working, because even despite some of the quirks that have been mentioned, it is still the most original feature on the site from a programming perspective. I think you all have come to realize that this is all a hobby for me, and as such, I tend to work on new projects faster than I will look into supporting existing ones (remember me talking about making the new MileTrak when the old one sorely needed new timetable data? :D ), simply because they're new and interesting, and things like this that are interesting tend to intrigue me.

I do know that the "classic" MileTrak app has always enjoyed a warmer reception by the users than has the pathfinder app, and despite my personal preferences, I try to keep the "classic" one in a serviceable state because I know you all use it and like it. You're all in luck, and that's that I recently took a train trip which I can't add to my database until it's fixed. ;) Well, some motivation is better than none, I suppose.

I will say that I'm doing two math classes (trig and calc I) this semester, as well as self-studying a chemistry book for a silly exam in five weeks. This stuff will have to take the back seat for a while, as much as I know you all are waiting for me to fix the site. ("This stuff" mainly includes getting things like discontinued routes and whatever else in the system, since that involves a bigger retrofit of the database schema :rolleyes: [are you bored yet :lol: ])

Happy rails, and I promise that in the end, this will all come together. :)
 
Anthony,

As a former computer programmer and major computer geek, I understand completely. It's amazing how any code that you write will completely rewrite itself to be unrecognizable as your work. ;)
 
Thanks Cory :)

After spending a few hours on that pathfinder code, I have to say I'm a bit stumped. I've got a machine running the old version of the db server, and the server running the current version, and the very same query runs just fine on the old one, but returns no matches on the new. I haven't found much in the changelogs with reference to any new feature or bug fix that would have disabled my stuff. I've examined some explanations of the processes it's using to return matches, and they look a bit different on each machine. Weird! :angry: :eek:
 
Aloha

Don'i know if you are still interested but I just read this thread. Would someone wanting to go from San Deigo, CA to Albany NY be a required four connection route?

Gould luck to all of us with your Miletrack fixes.

Mahalo

Eric
 
Hi, nope. SAN-LAX-CHI-Albany = two connections :)

MileTrak is shelved for a bit as I try to dig my way to the top of this ongoing schoolwork I'm doing.
 
Anthony said:
Thanks Cory :)
After spending a few hours on that pathfinder code, I have to say I'm a bit stumped. I've got a machine running the old version of the db server, and the server running the current version, and the very same query runs just fine on the old one, but returns no matches on the new. I haven't found much in the changelogs with reference to any new feature or bug fix that would have disabled my stuff. I've examined some explanations of the processes it's using to return matches, and they look a bit different on each machine. Weird! :angry: :eek:
Click to expand...
(this was fixed, by the way - I mentioned it in another thread)
 
Guest said:
San Diego CA. - Anywhere on the downeaster
Click to expand...
The Downeaster doesn't connect to San Diego without alternative transport from Boston North to Boston South. That's outside the domain of this application. Sorry. :)
 

Latest posts

Back
Top