TODOs

[felixguendling]

• translations.txt
• realtime:
  • second accuracy
  • vehicle IDs
• duplicate checker
  • generalise between VDV/SIRI
• frequencies detection - show next 3 frequencies (client: last connection of the day)
• flight / train checkin times
• on-trip train query
• area database - PoI type (opening hours) in admin area
• geocoding / stops - additional info:
  • metabhf (on city: bus terminals == main station(s) == air ports)
  • events
• multi criteria / weighted sum
  • operator preferences
  • mode preferences
  • CO2
  • operator changes
  • uninterrupted sleep time
• speedup:
  • parallel RAPTOR
  • heuristic
  • swap start/target + direction if less arrivals than departures
  • preprocessing
  • fine-granular overtaking check
• API to retrieve next departures that allow to traverse the leg (entry stop and exit stop the same) to show for local transport as "next departures"
• more time to transfer -> earlier arrival, later departure function
• McRAPTOR
• Shapes:
  • extract routes from OSM
  • if not in OSM: route with osr
• GBFS
  • rework API (DNF)
  • API to retrieve operators + vehicle types
  • map endpoint to show vehicles, zones, stations, etc. on map
  • configurable ttl
  • battery
• GTFS-RT ADDED, NEW,
• GTFS-RT REPLACEMENT, DUPLICATE wip
• routing: selection of transfer points based on distance + station size (drive 2h to airport vs 2h to bus stop)
• GRFS for ride sharing + GTFS-RT mdfz extension
• osr
  • default speeds: https://github.com/westnordost/osm-legal-default-speeds/blob/master/demo/distribution/legal_default_speeds.json
  • contraction hierarchies / A* für one-to-many
  • profiles
    • baby buggy (avoid stairs if possible)
    • more wheelchair profiles
    • blind
    • walk speed
    • bike speed
  • nice routes (along lakes / trees / etc.)
  • safe routes
  • bike P&R / bike + walk to platform
  • P&R:
    • live parking occupancy (parkendd?)
    • snap parkings to street + pedestrian network
  • predicted traffic flow
  • live traffic flow
  • area routing
  • speedup:
    • A*
    • bidirectional A*
    • distance vector
    • prepare osr lookup results for all stations
    • routing: store osr Dijkstra state for routing first/last leg -> reconstruct path instead of routing it again
  • connected components based lookup (only select start/dest nodes that are in the same component) -> do not extend lookup radius after first match (=more precision, especially for wheelchair profile)
• via locations, not just stops
• VehiclePositions -> delays TripUpdates
• ServiceAlerts
• GeoCoding
  • Fix matching of one-letter tokens ("U Haltestelle Berlin")
  • Location bias
  • Map border filter
  • Address formatting based on country (+ local script)
• Pass through GTFS
  • trip_name_short
  • route_name_short
  • route_name_long
  • route_type
  • in_allowed (not fully yet - call etc)
  • out_allowed (not fully yet - call etc)
  • wheelchair
  • bike allowed
• Pass through GTFS-RT:
  • occupancy
  • GTFS VehiclePositions
• TransModel
  • NeTEx
  • SIRI
  • OJP
• GTFS Flex
• GTFS TripModifications
• Incremental OSM updates
  • osr
  • adr
  • tiles
• Incremental timetable updates (merge tree, important for high matching rate GTFS-RT)
• zoned times in API
• OTEL
• Checkin Zeiten (Eurostar) / Luggage Checkin+Claim / Umstieg beim Fliegen#
• Car ferry / car train
• Bike carriage -> bike transfers
• Passenger information during trip
  • Connection monitoring -> PUSH updates to client
  • Connection refresh -> PULL updates from client
• UI:
  • Show server version in UI
• Only load data within a GeoJSON bounding box

[DomeQdev]

@felixguendling any update on trip modifications and added/new/duplicated?

[traines-source]

ADDED/NEW are supported, DUPLICATED/REPLACEMENT are work in progress, trip modifications is more long term. Do you have any example feeds that use these?

[DomeQdev]

Not really, but I'm planning to implement it for my Warsaw GTFS-RT feed. If you would like, I can provide one random trip modification in this feed.

[traines-source]

Ah nice. Any reason you would do that with trip modifications instead of NEW/REPLACEMENT? As far as I recall the strengths of trip modifications were that one could modify many trips at once (i.e. being less complicated for producers, but more complicated for consumers). So I would lean towards limiting ourselves to REPLACEMENT/DUPLICATED in MOTIS for the time being.

[Jouca]

Hello @felixguendling,
Do you have any update about DUPLICATED/REPLACEMENT trip modifications?

I need it specifically for IDFM GTFS-RT for RATP lines.

[felixguendling]

Why would cancel + new not work in your case?

[Jouca]

It does, but based on the GTFS-RT documentation, it seems that it would be much better to do it like that.

Because currently, I need to cancel RATP lines due to how they works with realtime data and replace with new trips based on theoretical trips.

[Jouca]

There is also a difference between a CANCELED trip and a REPLACEMENT trip also, for mobility apps it's quite weird to make the difference with only CANCELED trips that they are just replaced and some that are really canceled.

[felixguendling]

We are still planning on implementing this but we didn't have time yet.

Do you have a feed to test with? A static GTFS and a single protobuf file is sufficient.

[Jouca]

You can use these feeds, I've applied the REPLACEMENT objects :

GTFS : https://clarifygdps.com/hexatransit/datasets/gtfs/fr-idf.zip
GTFS-RT : http://gtfsidfm.clarifygdps.com/gtfs-rt-trips-idfm-beta

[Jouca]

@felixguendling I created a new endpoint for the GTFS-RT with REPLACEMENT objects, use this one :

http://gtfsidfm.clarifygdps.com/gtfs-rt-trips-idfm-beta