This is simply a pilot of a dynamic feature that is upcoming in the new system. This isn't really a new feature added to the board - rather, just a database call.
The issue of mileage comparison is more complex than you might imagine. I have to create a way for people to opt in to the comparison, as I wouldn't want to make it involuntary. That requires allowing the user to make options and choices on a user control panel or preference page.
To answer questions in PM and elsewhere, there is nothing inherent in this specific "mile count" other than the count itself. I wanted a few people to give me their MileTrak names so that I could see if this new way of calling the mileage was going to be stable (e.g., not crash the forum). It seems to be rather stable and I see no problem with it.
Maybe I've been negligent in not being a bit more clear as to how all of this works in the back end. Part of that is intentional... but basically here is the main issue:
a) The old [current] MileTrak - released April 2001. All data - including mileages, stations, trips, and routes - is stored in individual text files which are then read and processed by the MileTrak application. As one could imagine, manual file manipulation of that sort is extremely inefficient, and is the contributing factor to the sloth of getting trip database readouts. Every time you have a trip that is shown on the screen, several reading actions have to be done into individual text files to look up the city name from the city code, the route name from the route number, and so forth. This is all transparent to the end user, as route numbers are at times arbitrary and are used internally to track mileages and such. It is easy to understand why route numbers cannot be entered or displayed: while mileage between individual cities tends not to change, route numbers are often changed between schedule cycles. How would I then grandfather members' old trips with extinct route numbers into a new database of newly implemented route numbers? It's not worth the massive research hassle, so route numbers are not shown.
b ) The new MileTrak - yet to be released. This system uses a SQL database to perform the lookups and data manipulation that the previous program used flat files for. I had to create an extensive conversion application to bring old MileTrak data into the SQL database, as all of the files had to be read, line by line, all the while writing the findings into appropriate columns and rows in the database. I put together the converter so that folks won't have to re-enter all of their trips... though the converter also addresses cities, routes, and mileages, I think I'll omit all of that to start fresh. Data has certainly changed in two years, and I don't want to figure out where the discrepancies are. (The city, route, and mile conversions were simply to make my life easier during development, so that I could wait a while before entering all new timetable data, yet still have a viable coding environment)
Now, because the current MileTrak application still uses individual files to store trip data, I have to run that converter manually every time I want to get users' data into the new database. When the new system is in place, you will be able to simply add a trip, and have it globally update everywhere a mileage count may be displayed, since the Forums, the comparison chart, etc. etc. will all be reading from the very same place.
Entering all of those stations last week was a big enough chore in itself, but it's no match for the gigantic amount of routes and their respective stops and mileages. To answer the question about Metroliner.... yes, that, the NE routes and whatever else will all be in there. When I released the old version in 2001, I left a lot of things unfinished just to get it out there for folks to use. In retrospect, that was a very bad idea, as I never got around to finishing anything! Admittedly, the inefficient data format made my life very difficult when attempting to add in new routes. Regardless of whatever challenges I faced then, I am simply taking my time on this one to do it right. I'm hoping that by taking just a bit longer to get everything ready, people will be more pleased with the end result and outcome.
Essentially, the core app is done - I can log in there and enjoy the immediate benefits of the new system. Also, another significant add-on to the app is complete ... and that took long, long hours of brainstorming with pen and paper before I could even begin active development. I guess I just keep finding new things to take care of, or new features that may be of interest, and thus the release keeps getting pushed back. Oh well.
