Skip to content
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

Refactor graph code #17

Open
dabreegster opened this issue Aug 16, 2024 · 4 comments
Open

Refactor graph code #17

dabreegster opened this issue Aug 16, 2024 · 4 comments

Comments

@dabreegster
Copy link
Contributor

A core library is indeed emerging. I want to use logic here for a-b-street/severance_snape#18. See also a-b-street/utils#2.

@dabreegster
Copy link
Contributor Author

Use case 1: Share code here with severance snape, enabling the "driving vs walking" comparison there.
Use case 2: Buffer LCWIP networks and look for POIs / population inside. Need to call core logic already here, but at non-web scale and with CLI progress / parallelism.
Use case 3: Not thinking about this one much yet, but may need to take in OS (not OSM) graphs at some point.

Question 1: How should amenities work? It'll need to become a generic point resource that's snapped to a road. The code could continue living in Graph, but it'd need a generic introduced. Simpler for the caller (the 15m layer) to handle these, using RoadID to map. There might be perf implications to losing some cache locality, but could measure and reconsider later when that matters. Clean API is the priority for now.

Question 2: Same for the census zones. These'll probably evolve quickly in the short-term with more popgetter layers. They're just tacked onto Graph, not connected to anything, so trivial to move to the 15m layer, out of Graph.

Question 3: Where should the muv logic for determining direction/access per mode live? Sevsnape will want it for driving mode, but want to override for walking (and attach RoadKind). I think for now, I'll keep it baked into the graph layer, but might make it overridable next -- something like OSM tags -> Option<access and maxspeed per mode and direction

@dabreegster
Copy link
Contributor Author

And revisit why internals are in Mercator. Most operations don't really care about the geometry at all, or just need to measure length.

@dabreegster
Copy link
Contributor Author

Splitting things up messes up serialization. Or rather, serialization of the bundle including graph needs to happen.

dabreegster added a commit that referenced this issue Aug 24, 2024
dabreegster added a commit that referenced this issue Aug 25, 2024
dabreegster added a commit that referenced this issue Aug 25, 2024
For now, Timer goes with it.

No change in dev build time!
@dabreegster
Copy link
Contributor Author

dabreegster commented Aug 25, 2024

  • Docstrings and docs/examples
  • Fix main (doing the GTFS data prep and generating a graph)
  • Fix the benchmark
  • Make serialization happen for MapModel (and rename), not Graph
  • Reconsider mercator projection

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant