dabreegster
commented
2 years ago Maybe each scheme has a "data entry lifecycle." There's an MVP stage to get it on the map at all -- the polygon for area interventions, the linestring for routes (without really caring if it snaps to existing roads). Then there are refinement stages. For routes, that could be to chop up the linestring into pieces, and for each piece, give more detail about what the route looks like there. Along the entire piece, it's a stepped cycletrack on the left side, and every side road junction has a particular treatment. The "does it fit" check later happens per piece.
Also another bit of functionality we should wire together at the layer-level is an assessment / review mode of some sort. Both automated and manual. Github issues is almost an inspirational UI -- be able to see open problems ATE has raised about something, keep discussion in one place.
Robinlovelace
Nothing organized yet, just a place to dump stray thoughts.
From convo with Robin: real-time collab on the map isn't important. Organizationally, it could even be good to have just one person per HA mainly responsible for the data. The technical consequence is a big simplification -- real-time collaborative editing is hard.
Many unknowns about underlying data storage, how user auth / permissions will work, etc. The important functionality of ATIP to prototype is more on the UI side. In figuring out the key things different people will do with it, we'll arrive at a schema that supports everything needed.
What's the simplest thing we could start building that lets us punt on the unknowns till we have someone else onboard who can make better decisions there? To start with, a web map (I'd start with MapLibre GL) that operates on one "layer" representing all the planned interventions somewhere. There could be one layer for current conditions, one layer for individual schemes, or one layer for a bunch of planned changes -- doesn't matter yet. We can serialize the data in some quick format like GeoJSON and save in local storage or on the filesystem (and do something much better later on). We can sketch out the overall flow through the app, and start focusing on each type of intervention.
From a tech stack perspective, we shouldn't make any big choices until we have someone else around. I can't make informed decisions myself without taking some time to play around with Vue, Angular, React, etc. I'd probably just start with vanilla JS or TS.
The easiest scheme to start with is maybe LTN / area based interventions. The minimal level of detail is just asking the user to draw a polygon showing the interior of the proposed LTN. That's all. Later we can ask for details like where filters go, any road direction changes, etc, and use prior work to evaluate if the scheme is watertight and will actually have intended effects. (And point them to that tool to help with the design or engagement, if they want to use it.) There are maybe some basic properties to fill out for the area polygon -- temporary or permanent scheme? Approx costs? (And some of these might even be common questions about any scheme.)
Once we have one or two of these dirt-simple intervention mapping UIs going, we can look at the harder questions of what we'll need to do with layers themselves. One operation could be auditing. The user would go through each object in the scheme and verify it, or leave notes about it. For a current conditions layer, this could be a periodic audit of existing infra, or a manual step to verify OSM-imported data. For an existing scheme, it could be feedback from ATE. The user should be able to filter / style all the objects in the scheme based on some audit status, to see what still needs to be checked, for instance.