Open ghost opened 11 months ago
I fairly quick seems to indicate it's working with that file:
HKI_7 -> LR_1 today at 6am shows:
06:55:00, 09:07:00, HKI_7-LR_1
What inputs are you using and what output are you getting?
Then it is my fault, I wasn't even able to find where to put inputs. I am quite inexperienced with js.
I pasted the first readme example, and it seems to run, but with no output. Putting a console.log after the line with loadGTFS doesn't log anything.
it seems that I absolutely just don't know what I am doing.
I am having the same problem. Combing through the code and adding comments at key points, I seem to have narrowed down the issue to something with the gtfs-stream
library not sending an end
.
Image 1: My index.js
Image 2: Top of GTFSLoader.js
Image 3: Bottom of GTFSLoader.js
Whoops, forgot to add this. The loader gets initialized, but never seems to resolve the promise.
With even more testing, this is definitely a bug with gtfs-stream
. Tried doing a test with this script:
const fs = require('fs');
const gtfs = require('gtfs-stream')
fs.createReadStream("gtfs.zip")
.pipe(gtfs())
.on('data', (entity) => {
//console.log(entity)
})
.on('end', () => {
console.log('end')
})
And the program is exited without 'end' ever being logged. Heading over to that repo to file an issue now.
I have the same issue on https://github.com/planarnetwork/gtfsmerge/issues/11 - can you raise a reproducible error on gtfs-stream?
Doing some more poking around, it seems like gtfs-stream
sends a finish
event instead of an end
event (what raptor is expecting). Doing this allowed the gtfs to load, but then immediately popped up another bug for me 🙃.
There is a difference between finish and end but I can never remember what it is :)
It was definitely working with "end" so I wonder if there is an error that's not being surfaced and then it's closing with "finish".
Yeah that's true. Lemme add in a listener for errors really quick then.
Hmmmm, no errors seem to be passed down. Something is going wrong somewhere but nothing is logging that.
Submitted an issue to gtfs-stream https://github.com/staeco/gtfs-stream/issues/7
Now, there might be further issues with this, as poking through the code, it seems like the 4th item passed to RaptorAlgorithmFactory.create()
is meant to be a Date()
object, not the calendars
.
Any clue what's wrong in RaptorAlgorithmFactory.create()? I'm coming to same conclusion as @piemadd, any tips how to fix this?
Due to my observations calendars are not correctly processed, all calendar data is parsed into dates, hence broken matching for services, which results in further abominations. I will submit PR soon.
Submitted an issue to gtfs-stream staeco/gtfs-stream#7
Now, there might be further issues with this, as poking through the code, it seems like the 4th item passed to
RaptorAlgorithmFactory.create()
is meant to be aDate()
object, not thecalendars
.
It is mainly optional, which I assume, meant to accelerate search speed.
Wow nice @matjamr thank you, want to collaborate on fork/pr to resolve this issue?
Me and @kishieel are currently working on this maybe you want to join?
So I've tried the readme examples, but it gets stuck on loadGTFS. The gtfs file I am using is this one from https://www.digitraffic.fi/en/railway-traffic/#gtfs.