stop()

[dabund24]

resolves #1.

Since parseLocation() does everything a parseStop() function would need to do, I deleted it. Let me know if I overlooked something here.

Only somewhat related, but I was wondering if adding a location() endpoint (or just expanding the stop() endpoint to also work on location ids) would make sense to implement some time in the future🤔. This could make downstream apis a little leaner, as passing the full location object would no longer be necessary in some places. For now, this is not possible of course, since /stoptimes only accepts station/stop ids.

[traines-source]

Sorry, completely forgot about this PR :/

The failing tests are probably toggling tests that might work again tomorrow, when Berlin Schwedter Str. has departures again (?). Nonetheless we should probably improve these at some point...

Apart from that, LGTM 👍

Regarding location(), you mean that the responses would only contain location ids and clients could then do additional requests? Don't think this is a good thing to do, every additional request slows down and the philosophy of FPTF explicitly is to trade efficiency for consumability. But maybe I misunderstood your intention.

[dabund24]

Sorry, completely forgot about this PR :/

no worries, it went out of my mind, too. Otherwise, I would've sent a quick reminder 👍

Regarding location(), you mean that the responses would only contain location ids and clients could then do additional requests? Don't think this is a good thing to do, every additional request slows down and the philosophy of FPTF explicitly is to trade efficiency for consumability. But maybe I misunderstood your intention.

The responses would remain the way they are.
Still, my use case of stop() may be somewhat against the philosophy of fptf. Precisely, I want to show the type, name and geoposition of stops immediately on page load (such that the user does not have to stare at a blank screen for multiple seconds) without including all details in the url. An example is [1], where the fptf location object of München Marienplatz is included in the url. This (still) uses db-vendo-client, but the same would apply here.
This is obviously nothing of great importance, so it wouldn't be an issue if everything stayed the way it is.

[1] https://vahrplan.de/de/dbnav/diagram?stops[]=8096009&stops[]=8011160&stops[]=8000207&stops[]=8000105&stops[]={"type":"location","id":"991665484","latitude":48.137135,"longitude":11.575068,"name":"München, Marienplatz (Tourismus)","poi":true}&time=2025-09-16T05:11:00.000Z&time-role=departure&long-distance-express=&long-distance=&regional-express=&regional=&suburban=&subway=&tram=&bus=&taxi=&ferry=&max-transfers=-1&min-transfer-time=0

[traines-source]

Ok there's still no departures at Schwedter Str. :( Need to look at that, but very likely unrelated to your PR.

Ah yes now I understand but I think for that we first would need to build a corresponding API into MOTIS. In the DB APIs you should be able to use the locations() endpoint with the ID as the query param, because it also searches by ID if I recall correctly. In MOTIS that's not (yet) the case I think (but there you could search by name).

[dabund24]

In the DB APIs you should be able to use the locations() endpoint with the ID as the query param, because it also searches by ID if I recall correctly.

Ohh, that's interesting to know. Thx!

In MOTIS that's not (yet) the case I think (but there you could search by name).

I think I would not do that, since it would be problematic if names are not unique. (I.e. there seem to be at least four places with the name "LOL" and at least five places named "Lol" in Transitious 😅)