-
-
Notifications
You must be signed in to change notification settings - Fork 12
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
improve /stops, /locations & /journeys documentation #40
Comments
Thanks for reporting this! The developer experience & documentation on
This is a bug, fixed in the underlying library
This is a documentation issue, let's fix it! At some point, I messed up
Can you give a specific URL? I will add an example with an address as the destination:
All three have "required" next to them. How would you change it to be more understandable? |
Hi there thanks for the quick reply! So:
gives a response now. I have to check in detail but overall it looks like the structure I remember
Many thanks! |
It does.
|
I tried to add fuzzy just in case that there was a different spelling of the street, but even without fuzzy I get a missing origin error. I wanted journeys from Weserstr. 37 to alexanderplatz. Re the json, hmm, good, my browser doesn't format it, maybe the size of response exceeds its ability to prettify |
also for instance, this link: |
I just tried it, and saw that I need to specify all three parameters indeed, but that seems redundant and overkill given that lat/lon <==> address. Was it always like this? my old code has calls like this and worked. the new method requires to make a query just to have the right lat/lon from the address or vice versa before calling the API.
having just lat/lon was sufficient (please note the domain part of the url, these URLs are those I used back in sept 2017, I have not used this code since then). Maybe I am missing something? |
I tried this: and it DOES work (i.e. results are corresponding to closest station), even though from.address is clearly a fake place which gets replicated in the response. I don't know if it is in your power to address this (i.e. use just either one of lat+lon OR address), for the time being I'll just use a placeholder, for my use case is good enough but I'll need to remove a "check by address" |
Yes, the
Because of the aforementioned HAFAS limitation, you need to pass The developer experience is bad – I'm aware of that –, but right now, you need to use
It may have worked that way with the old |
Re-reading our discussion here, I can see that the
Unfortunately, improving I'd be happy to review & merge a PR that improves documentation though! |
I might try that, I am a little bit under deadline for my main project at the moment but yes it'll help also me to improve my understanding of the api. Let me underpromise and who knows hopefully overdeliver! Cookbook might be a little too much above my capabilities atm. New api looks quite cool, is it an aggregator / proxy for different local infomobility services? Also re /locations : just did 1 quick test, I can work with that in case I need to start from an address. As long as I have a chain of calls I can make to get where I need, it works :-) thanks. |
Yes, in a way. From #41 (comment) :
|
FYI I have set up |
Hi,
I wanted to reactivate some old code using your API which has been decommissioned, and it seems there may be some things not working.
For instance, I have been trying these links from your documentation
https://3.vbb.transport.rest/journeys?from=900000023201&to.id=900980720&to.name=ATZE%20Musiktheater&to.latitude=52.543333&to.longitude=13.351686 { "error": true, "msg": "invalid to.type: location" }
https://3.vbb.transport.rest/stops Cannot GET /stops
I discovered that when trying to do a /journeys request passing an origin in address form. Then I tried some of the listed examples and got errors too.
Also, could you please clarify in docs e.g. for address format if address AND latitude AND longitude are all three required? I suppose either of the three as long as to and from are univocally determined, but may be mistaken. Thanks for looking into it!
The text was updated successfully, but these errors were encountered: