Walking + PT has been started in this repo. Just starting a list of improvements.

UI

• Just make a nice UI to explore GTFS data. See routes on a map, see timetables per stop, etc. Look for inspiration. Old ideas in https://github.com/dabreegster/bus_spotting and a-b-street/abstreet#372.

A-to-B routing

• Configurable start time
• Display text route directions nicer. "Walk 5 minutes", "wait 4 minutes", plumb info about the route taken
• Correctness -- only ever 1 stop per trip? Impossible
• Use route shapes for display (and see how much space they need)
• Get more precise about linking walking and transit steps

Isochrone

• Implement it

Data model

• Decide requirements for days of the week, service exceptions, etc
• Think through serveless-friendly ways of getting GTFS data

Performance

• Can an A*-like heuristic help for PT routing? Edit: yes, but it loses optimality
• Get base file size down, without GTFS. London is 370MB, but the PFB is 90MB
• Smaller GTFS data. London is around 300MB right now
• More compact NaiveTimes?

Refactoring

• Figure out what frontend and backend components are generally shareable
• Specifically use in https://github.com/Hussein-Mahfouz/meet-me-halfway/

• Make much more configurable
• Popups cover up routes
• Display all parking, to sanity check results
• Some routes aren't shown
• Improve handling of positions along a road

For a possibly large GJ input representing something like a new scheme built somewhere, calculate

• POIs within X minutes by some mode
• Intersect some polygon buffer with polygon areas and sum up census/demographic data
• Output everything visually/interactively, but also as a big downloadable report (specifically what're all the schools close by?)
• Calculate mesh density specifically

Ideally, this tool will be able to answer the same kinds of questions for any mode. Over in Severance Snape, to calculate ped shortcuts, we need a driving graph. In the LTN tool, we need to understand non-driveable roads to detect some modal filters. Without going back to the sheer complexity of the osm2streets approach, revisit all of these requirements. One graph structure, many views onto it?

Maybe this is intentional, but it surprised me:

$ curl 'https://assets.od2net.org/severance_pbfs/elephant_castle.pbf' | head                                              
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0<?xml version='1.0' encoding='UTF-8'?>
<osm version="0.6" generator="osmium/1.11.1">
  <node id="107564" lat="51.4986115" lon="-0.079333"/>
  <node id="108118" lat="51.4977008" lon="-0.0797753"/>
  <node id="108119" lat="51.4971248" lon="-0.0808368"/>
  <node id="108120" lat="51.4966987" lon="-0.0818124"/>
  <node id="108121" lat="51.4959887" lon="-0.0829106"/>
  <node id="108183" lat="51.4947912" lon="-0.084657"/>
  <node id="108184" lat="51.4947597" lon="-0.0851832"/>
  <node id="108186" lat="51.494026" lon="-0.0862054"/>

This could be another good way to minimize your page load.