| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
It turns out persist does support these, they're just not mentioned in
the yesod book.
(for future reference, the syntax is defined in Database.Persist.Quasi,
which does include some documentation [1])
[1] https://hackage.haskell.org/package/persistent-2.14.6.1/docs/Database-Persist-Quasi.html
|
| |
|
|
|
|
|
|
| |
A simple way to have "announcements" available via API, and otherwise
distinct from the service announcements which show up in Gtfs Realtime.
These are meant to go e.g. be embedded on the operator's website, or in
other places where it's not as easy to display per-trip specific messages.
|
| |
|
|
|
| |
not sure if i'll keep it here — it should probably gain some logic for
real-time udpates and be moved to the map view instead.
|
| |
|
|
| |
in preparation for using these elsewhere, where they are less cramped
|
| |
|
|
| |
(same as previous commit, this displayed the wrong ping)
|
| |
|
|
|
|
|
| |
this is really two changes:
- some leftover lat,long keys in the clientside javascript
- the Server.Subscribe module should send a correct ping after a
connection has been opened
|
| | |
|
| |
|
|
|
|
|
|
|
| |
can't believe it was this simple … but seems to be all that was wrong.
Tracktrain should now automatically remove tripUpdates for tickets whose
trip has ended more than five minutes ago (taking delay into account).
Nothing in the gtfs-rt spec says you should do this, but google likes to
complain if one doesn't do this.
|
| |
|
|
|
| |
also make the code generally look nicer. Turns out I made a lot more
fragile assumptions than I thought I did.
|
| |
|
|
|
|
|
|
| |
now takes all potential stops along each trip into account when guessing
tickets; also checks if a ticket is still likely in case the tracker
switched its direction. This should solve many cases where a tracker is
accidentally turned off or falls asleep halfway before the last station
of one trip, then wakes up in the middle of the next.
|
| |
|
|
|
| |
this is meant to be false by default, and otherwise relaxes requirements
on e.g. incoming pings, which are inconvenient when testing by hand.
|
| | |
|
| |
|
|
|
|
| |
this does svg templating with hamlet. It might be better to use a
javascript library instead (templating svgs is a little confusing tbh),
but for now i'll see how far i get with this.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
there's some trade-offs here (cookies may be discarded by the browser,
query parameters lost if people use a bookmark), but either works fine
for not re-issuing tokens if someone reloads the web site.
|
| | |
|
| |
|
|
| |
apparently i forgot an if here?
|
| |
|
|
|
| |
largely based on things noticed on 2024-05-01, this year's first day
of Ilztalbahn trains running.
|
| |
|
|
| |
this is the initial version used during 2024's Ilztalbahn season.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should hopefully be the final (major) part of the restructuring: a
tracker no longer has to know which trip it is on (and indeed it has no
idea for now), instead the server keeps state about which trips are
currently running and will insert incoming pings in a hopefully
reasonable manner, based on their geoposition & time.
There's lots of associated TODO items here (especially there should be
manual overrides for all this logic in the web ui), but that's work for
a future me.
(incidentally, this also adds support for sending all log messages out
via ntfy-sh)
|
| | |
|
| |
|
|
| |
now mostly independent of the gtfs, but still no live-reloading of it.
|
| |
|
|
|
|
| |
this is mostly meant to guard against the gtfs changing under
tracktrain, and not yet complete (e.g. a ticket does not yet save its
expected stops, which it probably should).
|
| | |
|
| | |
|
| |
|
|
|
| |
jumps to GHC2021 as default language, adds in some fields, moves the old
org mode glossary to markdown, etc.
|
| |
|
|
|
|
| |
I do not really like either option, but at least the second one seems
more likely to be maintained (and a little less clunky to use, too, for
what it's worth).
|
| |
|
|
|
|
|
|
| |
protocol-buffers's last release has been some while ago, and since then
a deprecated function it used to use has been removed from the
bytestring package.
so here's some fun overrides to ignore that.
|
| | |
|
| | |
|
| |
|
|
| |
google maps complains about it otherwise
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
these are just enough to send train positions to tracktrain with the
current API, but are somewhat brittle (e.g. will fail if not restarted
between trips, etc.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
this makes the nix builds /much/ nicer
|
| |
|
|
|
|
| |
this is unfortunately uffd-specific, since oauth2 is apparently sort of
a vague standard. But since it doesn't actually do much it should
probably be possible to make it fully configurable & generic if needed.
|
| |
|
|
|
| |
(what was that about doing the realtime stuff somewhere else and /not/
in this monolithic server thingie? oh well …)
|
| | |
|
| |
|
|
| |
(for a leaflet map view or sth which isn't implemented yet)
|
| | |
|
| |
|
|
| |
(hardcoded for now, since we don't have new trips)
|
| |
|
|
| |
(but maybe google will like it)
|
