planarnetwork / raptor

Implementation of the Route Based Public Transit Algorithm (Raptor)
81 stars 13 forks source link

loadGTFS doesn't work. #17

Open ghost opened 11 months ago

ghost commented 11 months ago

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.

linusnorton commented 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?

ghost commented 11 months ago

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.

piemadd commented 9 months ago

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

Image 2: Top of GTFSLoader.js image

Image 3: Bottom of GTFSLoader.js image

piemadd commented 9 months ago

Whoops, forgot to add this. The loader gets initialized, but never seems to resolve the promise.

image

piemadd commented 9 months ago

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.

linusnorton commented 9 months ago

I have the same issue on https://github.com/planarnetwork/gtfsmerge/issues/11 - can you raise a reproducible error on gtfs-stream?

piemadd commented 9 months ago

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 🙃.

linusnorton commented 9 months ago

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".

piemadd commented 9 months ago

Yeah that's true. Lemme add in a listener for errors really quick then.

piemadd commented 9 months ago

Hmmmm, no errors seem to be passed down. Something is going wrong somewhere but nothing is logging that.

piemadd commented 9 months ago

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.

kostnerek commented 2 weeks ago

Any clue what's wrong in RaptorAlgorithmFactory.create()? I'm coming to same conclusion as @piemadd, any tips how to fix this?

matjamr commented 2 weeks ago

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.

matjamr commented 2 weeks ago

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 a Date() object, not the calendars.

It is mainly optional, which I assume, meant to accelerate search speed.

kostnerek commented 1 week ago

Wow nice @matjamr thank you, want to collaborate on fork/pr to resolve this issue?

kostnerek commented 1 week ago

Me and @kishieel are currently working on this maybe you want to join?