HAFAS endpoint
derhuerst opened this issue · 11 comments
Hi! I'm working with the VBB public transport API, which is based on HAFAS. I wrote a JavaScript API client for it.
Deutsche Bahn uses HAFAS as well, so consider using the API instead of parsing a "steaming pile" of HTML. ;)
Hi! Does HAFAS include realtime information on delays etc.?
@akloeckner Proceeeding from
#14 (comment):
Assuming DB's API will stay around
It will for a while; It's being used by the DB Navigator app.
your JS implementation of the API is quite sophisticated
Indeed, I spent ~2 years on and off writing it. There are just many edge cases and little details when talking to HAFAS, which is why I suggested porting from JS to Python, instead of developing from scratch without prior knowledge.
So, I wonder wouldn't it be possible to simply wrap it in Python (instead of porting it)?
This would indeed be possible:
hafas-client is built on top of the Node built-ins. It needs a Node-compatible runtime to work.
But: hafas-client can also be transformed not to use Node built-in modules and work in the browser instead. Thus, any JS runtime that supports the basic Web APIs (ArrayBuffer, fetch, optionally the crypto API) should be able to run hafas-client.
A quick look around pointed me to JS2PY. It is said to interpret virtually any JS code. What do you think? Schiene3 is coming? ;-)
Nope, sorry, it looks like that neither supports the Node built-ins, nor Web APIs.
Is there a Python binding for Node? That would work. Another way would be to use stdin/stdout or IPC, via e.g. JSON-RPC calls.
I've only found this Node binding: https://github.com/markfinger/python-nodejs/blob/master/README.md
Why not simply include the (Java) implementation of transport-enabler, which you mentioned? We could simply plug into an (apparently?) proven open-source backend...
Because a) hafas-client covers quite a few more features of HAFAS and b) has more thorough tests. The proven-ness argument is true though: While I use hafas-client in a non-hobby scale, public-transport-enabler has been around for a longer time.
I appreciate the effort, but arguably it's lacking quite a few features. If you want, we can make this a fully featured client.
While I'd love to help, I don't think I'm the right person for the job. It was literally the first time I used python and this would negatively impact the quality of the code which is quite important in larger project.
Yeah I've just seen that while playing around a little. One connection that was canceled was not marked so in the output for example. Let's see what further investigations will show.
If you can pinpoint the issue I could try to fix that.
I just skimmed through the hafas-client and maybe it has something to do with cancelled stopovers, since I just use it for short connections I might have missed it.
Anyways if you can use the JS client or the web version of it I would definitively recommend you to do that.
If you don't want to rely on the publicly deployed 2.db.transport.rest endpoint, you can deploy db-rest or db-hafas-rpc-server locally.
@derhuerst, what about this library? https://pypi.org/project/python-bond/1.4/
Using built-ins will always require a separate JS process, though, right? Will the same be true for the Web API?
Using built-ins will always require a separate JS process, though, right? Will the same be true for the Web API?
Depends on what you mean by "built-ins". I was talking to Node built-ins, which exist in addition to ECMAScript, the standardised language behind JS.
We would have to a) use Node bindings for Python, or b) build a WebSocket/TPC/sockets-based wrapper, or c) port hafas-client to Python.
Sounds like the simplest way would be the binding. I'm not so sure though, what that means. But as I understand it, it will mean quite some dependencies on a binary Node runtime. That might become a nightmare to maintain on different systems. But still less fragile than some homebrew socket interface or maintaining (and writing in the first place) two hafas clients.
I'm not sure how much I can do about this in the nearest future. But sometimes I have creative moments and I might find a working python library to include your code. If I do, I'll put the result on GitHub and link it here, so you can all comment. And there will be a lot to comment, as Im also no Python expert yet...
Last thing to note: I'd really like the short and clean interface of Schiene to remain. Station IDs and the like don't seem too user-friendly to me.
Sounds like the simplest way would be the binding. I'm not so sure though, what that means. But as I understand it, it will mean quite some dependencies on a binary Node runtime. That might become a nightmare to maintain on different systems. But still less fragile than some homebrew socket interface or maintaining (and writing in the first place) two hafas clients.
From what I can tell, Python Node bindings would be quite complex and prone to breaking if one of the two changes.
I had already written the WebSockets-based RPC interface for hafas-client anyways, and have just written an stdio-based one. Both accept generic JSON-RPC 2.0.
Last thing to note: I'd really like the short and clean interface of Schiene to remain. Station IDs and the like don't seem too user-friendly to me.
I obviously won't tell you how to design the API of schiene. The reason hafas-client is so low-level is because it is basically a 1-to-1 mapping of HAFAS calls into JS. It leaves convenience & abstraction up to libraries on top.
I have published hafas-client-rpc@3.0.0, which contains the RPC interface via stdio.