Auto-generate road name and speed limits for a drawn route

[dabreegster]

As you draw a snapped route, we can give some info about it to help people decide its quality over possible alternatives.

• the amenities along it (broken down by categories -- groceries, health facilities, schools, etc)
• a measure of "directness" / number of turns / mental complexity to follow it (see Ungap the Map ideas a-b-street/abstreet#1013 (comment))

There are design tradeoffs to nudging people onto quieter back-streets vs past the local high street. We don't need to be opinionated about them, but we could just start exposing the information and see how people might use it.

[dabreegster]

Another request: how many "critical" junctions crossed

[dabreegster]

Reviving this. Further ideas from Kit and others:

• Amenities: high streets, rail/bus stations, childcare, medical facilities, schools, etc
• Speed limit along the route
• Use the route endpoints to automatically fill out a name for the route -- "Xyz St to Abc St". Many people in submitted ATIPs did this manually!
• Current lane allocation and/or width
• Census stats within a nearby walkshed

I'd like to start discussing how we might implement this.

Strawman implementation idea

The A/B Street map model (outdated docs, code) has much of the required data already. Or for things missing or inaccurate (like the current classification of OpenStreetMap's amenity tagging into higher-level categories), fixes that fit ATIP's purposes would be very much welcome there too.

I can think of a few approaches here:

1. Bake more detailed data into the file used by https://github.com/dabreegster/route_snapper/.
2. Load a serialized map file in the browser and interact with the contents using a WASM/JS API. We'd feed in a drawn LineString (or an area's polygon or anything else), do basic map matching to relate it to the roads defined in the map model, and return any details we need.
3. Create a read-only API that does the same, but host it remotely and make API calls over the network.

(1) and (2) are similar. Both would mean shipping and deserializing a larger file to the browser. For the large authority boundaries we've got, this could impact initial load time. (Which is unfortunate -- if we were shipping people a desktop app that they download/update only occasionally, that cost is amortized, and we have the full power of threads, etc....) I could estimate how much, if it's helpful.

(3) bumps up our team's responsibility, because now we'd need to productionize something running in the cloud somewhere, not just host static files. But the operational burden is not likely to be high; this is a read-only API. And it's probably something we're doing anyway, for some kind of cloud ATIP.

Another thought is to punt on this decision a bit. If we went with (2), it'd be really nice to deserialize the file and do some of the more expensive queries in a web worker to not block the main thread. I tried this in #23 for the route snapper -- IIUC, if we deserialize in a web worker, we're kind of forced to run queries there too for perf reasons. So the way we punt is to assume from the rest of the Svelte app that there's some JS layer that gives us these route details asynchronously. That async call could either go to a web worker, or to a remote server. We're forced to deal with the asyncness and possible failures anyway, and swapping out implementations becomes pretty trivial.

[dabreegster]

Another advantage of remote: if we wind up using datasets that we can't publicly host (like OS data), we keep those private on the server, and just let people ask certain queries of that data. We can also put this API behind an auth layer, make some ATIP users login, and only reveal this more private data to certain people.

[dabreegster]

If web workers are part of the implementation, https://github.com/GoogleChromeLabs/comlink

[dabreegster]

v2 MVP is route name and speed limit

[dabreegster]

Closing as finished for v2 -- naming and speed limits are initially implemented. There's improvements possible with both, but nothing specific in scope for v2. This issue also has useful notes for the next round of features, but I'll link this to #120 to refer back