Updates and fixes for 2025 - #3
Conversation
jonanderson10
commented
Dec 24, 2025
jonanderson10
commented
- Fix CSV parsing error
- Add support for parsing station name from ORCA readers at bus stops
|
Hey @jonanderson10 thanks for opening this PR. I'll take a proper look in the next few days. One other fix I had in mind for 2025 was the fact that the Link Light Rail only requires a single tap when boarding. Honestly haven't looked at this code in a while nor do I remember if I had an exception for this, but might just be something to update for reports where Thanks again for your contribution! |
|
Yeah, my only disclaimer is this was vibe coded with Opus 4.5 so my contributions are "having the initiative" and "supervising the junior engineer". That said, I tested this against my 2025 data locally which includes bus, light rail, and ferry trips and things seemed to check out. I had used this last year and enjoyed it so I wanted to do it again this year. |
| route = (locationArray[1]) | ||
| } else { // Water taxi | ||
|
|
||
| if (route === 'One City Center') { |
There was a problem hiding this comment.
This line probably needs to be changed or just removed?
- It seems limiting to only check for one route
- I can't seem to find any line that is called "One City Center"? Do you have more information on what this route might be?
There was a problem hiding this comment.
So this "One City Center" was a platform reader for the G Line based on looking back through my old data here. So to some extent this was me being selfish and wanting the code to generate a report that made to sense to me. So yeah, along with your issues you brought up around platform readers having different IDs this could perhaps be removed. It's been a hot minute since I looked over this so I am little fuzzy on remembering. I am attaching some data I used to test out all my changes that includes One City Center so you can check it out too.
sample-card-data.csv
There was a problem hiding this comment.
Yeah, strange. Thanks for providing the sample CSV.
I guess we'll have to see if this is a recurring issue with G Line trips. Perhaps there is a data issue with the G Line that King County Metro will fix. If not, perhaps they can be notified of the problem.
Ideally, we would get a second case of someone running into this issue, but I'd be open to adding this workaround with the context that this is just for the G Line.
An additional data point that might be helpful: Do you recall if you tend to tap your ORCA card using one of the onboard readers, or on the platform? My intuition is that tapping on the platform might be one of the reasons that the bus line doesn't get assigned to the tap.
There was a problem hiding this comment.
Often times it was a platform tap, which is likely the source for these entries.
| const deviceMatch = activity.match(/Device number:\s*(\d+)/i) | ||
| if (deviceMatch) { | ||
| const deviceNumber = deviceMatch[1] | ||
| const stationName = stopsLookup[deviceNumber] |
There was a problem hiding this comment.
So, taking a look at my own ORCA taps, it appears that the deviceNumber variable only appears when the tap happens on a platform. So trips on the light rail or street car, but not the bus or WSF.
However, it looks like the data in stops.js is a dictionary/map of stop_id: stop_name for bus stops only. This seems to suggest to me that this code will never run. The transaction will contain a Device number string, but that device number will never appear in the stops.js file.
Additionally, it seems that each ORCA tapper-post (idk if thats the official name) has its own deviceNumber (I see different numbers for the different times I tapped at Westlake and CID stations).
Is there a particular route you found didn't get counted in your summary? Do you have an example file that I could take a look at and compare against?
There was a problem hiding this comment.
This is related to the "One City Center" aka G Line and in the case I found the stop number and device number were the same. I only had that data I attached to work with so this very likely means this needs more investigation if its worth keeping in at all. Perhaps only the G Line suffers from weirdness.
| let stop = null | ||
| let date = null | ||
| const split_array = row[locationIndex].split(', Stop: ') | ||
| if (split_array.length === 2) { // Bus Route or Light Rail |
There was a problem hiding this comment.
nit: I think it would be helpful to keep these comments about how routes are getting identified, though looking back at the code this could certainly be done more elegantly.
There was a problem hiding this comment.
Totally fair, I usually lean towards no comments and make sure the code does the talking in a clear enough way too. But in this case this was probably a casualty from me removing a couple other LLM comments at the same time.
There was a problem hiding this comment.
I'm a bit wary of having such a static file in this project. Besides the fact that I'm not sure if this is even the correct data that we want, it has the chance to get stale fast.
Any chance you have a public source that this could get pulled from? Perhaps the Sound Transit / King County Metro GTFS file has this data (I think it should in the stops.txt file), and there could be a complimentary utility script to help update this list ad-hoc?
There was a problem hiding this comment.
IIRC pulling from GTFS required an API key so I wanted to keep this dumb and simple. I pulled the data from stops.txt and filtered it down to bus only since that was related to the fix for my One City Center issue. And while a static file is dumb I figured it fails in a very predictable way (stale data). And that would be easy to solve for with something like a helper script to update it. Also I am no JS expert so I think I did it as a JS file purely out of convenience of avoiding having to load from a file, it came preloaded as a var I could reference.
There was a problem hiding this comment.
For posterity, Sound Transit hosts GTFS files for the region on their website. I think the API key is only needed if you want to poll the GTFS-RT feed (which is real-time locations of vehicles).
https://www.soundtransit.org/help-contacts/business-information/open-transit-data-otd/otd-downloads
|
@jonanderson10 hey, just wanted to see if you were still thinking of working on this PR? I think the first commit fix: csv parsing for 2025 is a great fix, and could maybe be merged in now. Perhaps that commit can be split to a separate PR? I'd like to give you credit for the fix instead of making a new PR myself. |
|
Hey there, I have been busier at work lately so not as much brain power to spare for coding things on the side. So for now I probably won't have the bandwidth to dedicate to this. I will make a separate PR for that one commit though. And hopefully my other comments and sample data can help you see how I arrived at my other janky solutions. Again, my very weak defense is that "I wanted my data to look right" |
2 participants
