Skip to content

Aarschot Meiser gives error 500 #325

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ChristopheVersieux opened this issue Oct 25, 2017 · 5 comments
Closed

Aarschot Meiser gives error 500 #325

ChristopheVersieux opened this issue Oct 25, 2017 · 5 comments
Assignees
Labels
Bug Confirmed This behaviour has been reproduced

Comments

@ChristopheVersieux
Copy link
Member

ChristopheVersieux commented Oct 25, 2017

Sorry,I am on mobile, so I cannot give more information, but I got this report and I can confirm.
Irail.be also show an error.

Link: https://api.irail.be/connections/?from=aarschot&to=meiser and also happening with &format=json

There seems to be some results concatenated with the error 500 message.

@Bertware Bertware self-assigned this Oct 26, 2017
@Bertware Bertware added Bug Confirmed This behaviour has been reproduced labels Oct 26, 2017
Bertware added a commit that referenced this issue Oct 26, 2017
…emarks, urls for alerts, fix error message causing incorrect json #319 #325
@Bertware
Copy link
Member

Bertware commented Oct 26, 2017

This was caused by a small walking section in the route. This is a walking section between Haren and Haren-zuid, 2 stations at a few hundred meters from each other, it would be one station if the tracks were a bit closer together. However, this means it's a valid route, and we can't drop it just because it has a walking part.

I fixed the API to support this, however, in the via's this registers as a train with direction 'WALK' and an id of 'WALK'. I don't know how applications are going to respond to this, and this not definitive. However since it didn't work before anyway, this might be a good temporary fix, and this needs more discussion with other team members like @pietercolpaert who's not available this week.

I added a walking flag to via arrivals and departures. This flag could be used to distinguish a short walk like this from a train. While not definitive, I'm pretty sure the flag's going to stay for things like this. If you already want to support this, I suggest to do the following for now:

  • Check for presence of this flag. Use a try-catch or validate the presence, but don't rely on it being there.
  • If present and set, treat as walking
  • If not present or not set, treat as train

Edit: just tested, BeTrains works fine already with the current fix. I suggest you keep it like this until we have a definitive implementation for walking support.
screenshot_20171026-130435

@ChristopheVersieux
Copy link
Member Author

This as awesome and way better than before!
Thank a lot

1 similar comment
@ChristopheVersieux
Copy link
Member Author

This as awesome and way better than before!
Thank a lot

@ChristopheVersieux
Copy link
Member Author

ChristopheVersieux commented Oct 27, 2017

Houps my fingers slipped and I "comment and close" before I finished my message.

I guess you want it open before finishing to discuss with other team members, but the fix you made is great.

I wanted to really thank you for your hard work.

@Bertware
Copy link
Member

Bertware commented Nov 9, 2017

The definitive fix for this is the walking flag, which has been added to every arrival and departure. This flag is the only reliable way to detect if the part after this departure or before this arrival is a walking part. Any other fields, like the direction and id of the train should be ignored (do not try to parse or read these fields in this case). Future updates might add the walking time in this field. Therefore I recommend you use the following test:
walking == 0 means it's a train (non-walking). walking > 0 means it's a walking part.

The documentation will be updated with new fields and information once everything is final.

@Bertware Bertware closed this as completed Nov 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Confirmed This behaviour has been reproduced
Projects
None yet
Development

No branches or pull requests

2 participants