Superschemes for sketcher

[Pete-Y-CS]

Alright this is still very rough and ready: both the code, and what we're calling stuff will want some tweaking but we have here a first pass at having subschemes to which interventions belong. https://acteng.github.io/atip/superschemes-for-sketcher/scheme.html?schema=pipeline&authority=TA_Lincolnshire&style=streets#9.32/53.1242/-0.4517

Currently you should be able to:

• name your (super) scheme
• Add and name subschemes
• When adding an intervention you select a subscheme to which it belongs
• Delete a subscheme and all its interventions
• Change which subscheme an intervention belongs to by using the edit form

[dabreegster]

I realize we haven't written down a design doc or anything to describe the purpose of this idea, so I want to start with that. I'll review what this PR does next.

Use cases

1) Short-term: LCWIP PDFs tend to show many schemes on one map. People sketching them likely want to do the same -- so this is a way to edit multiple schemes at the same time. 2) Speculative long-term: When some future funding round starts, if an authority already has a bunch of planned schemes mapped out, they could load their one or more LCWIP schemes, then extract/select/copy some things into a new scheme for submission.

Data modelling questions

Should a feature belong to exactly one scheme, or can it belong to multiple at a time? #372 brings up some ambiguous cases:

• Multiple routes with a common shared middle
• A desire line with a few alternative routes that could satisfy the goal. The alternatives might share some common segments or not.

As soon as multiple schemes share the same feature, we have to decide how that should work -- are there two copies of something that can diverge, or do they reference the same single object? My inclination is towards the latter -- otherwise we have to communicate through the UI something quite confusing.

A minimal design

152 was an earlier attempt at this, but here's a fresh idea. The simplest UX I can think of to satisfy the two use cases would look like this:

• The user can load multiple disjoint schemes at a time, as long as they're for the same area.
  • Think of each scheme as a layer in a GIS tool. There's a way to create a new scheme, load a scheme from a file, show/hide a layer that's loaded, and remove a layer from the "working set" that's been loaded.
• Each feature belongs to exactly one scheme.
  • When you edit a feature, you have a dropdown to change its scheme
  • We still have just the one list of features on the left, but we show the grouping with colors or labels. We could also re-order things to group a scheme's features together; the order shown (and stored in the file) is not meaningful.
  • We could also color features on the map by their scheme, auto-assigning colors and letting people change them.

The GeoJSON representation would pretty much match what's used for all_scheme_data in the browse page right now.

• Every feature has a scheme_reference field
• The top-level JSON object has a schemes dictionary, keyed by this scheme_reference. The contents are a dictionary with whatever scheme-wide metadata is relevant -- right now that's just the scheme name, but that's likely to grow soon with #355.

Implementing this should be pretty straightforward, except for the problem of how to save files. Right now one exported GJ file (and equivalently, one stringified GJ object in local storage) represents one scheme, and is named by authority and scheme name. We could save multiple files / local storage keys, one per scheme? Or maybe we should natively handle a file that has everything bundled together with this extra schemes object, and in simple cases, just have one scheme. Both approaches are perfectly compatible with properly storing data in a DB through a future API call.

[Pete-Y-CS]

Re: the bug you mentioned. I wasn't seeing that locally. I will try to work out if I failed to push some key change or what.

Re sub/super schemes the naming got away from me a bit, because I wanted to use existing infrastructure for populating 'schemes' but my idea is that the subschemes are effectively schemes. They will have more data collected about them and this is the use case we are trying to deal with: an LCWIP is a superscheme, and then the (sub)schemes are meaningfully distinct: they will have (some of the following:) names, routes with segments, a priority level (low, medium, high).

Ultimately it's editing multiple schemes at the same time, I agree. I think what I've done is already equivalent to all_schemes_data.geojson, no?

[dabreegster]

an LCWIP is a superscheme, and then the (sub)schemes are meaningfully distinct: they will have (some of the following:) names, routes with segments, a priority level (low, medium, high).

I'm confused by this... based on the latest data spec doc, #380 adds a bunch of fields at the scheme/LCWIP level, and changes the per-feature ones. I don't think priority is in there?

If our goal is editing multiple schemes at a time without trying to establish relationships between schemes, I think there's a simpler design possible

[Pete-Y-CS]

Timescale is synonymous with priority here. Timescale was what Robin and I spitballed early on, I've hear Guy use priority since. In any case if there's a simpler solution I'd be down, although I think it's going to end up similar data wise to what I've already done? Might be another one for a call to work out where we're differing, but I think that PR you linked looks great abut could presumably be plugged into something like what I've done here (bug of interventions not showing notwithstanding)

[dabreegster]

About to look at this again, but just to note, it's failing tests / TS checks currently

[Pete-Y-CS]

About to look at this again, but just to note, it's failing tests / TS checks currently

Seems to pass locally, might be one of the flakey tests

[dabreegster]

npm run check breaks for me locally too https://github.com/acteng/atip/actions/runs/6708978389/job/18258013700

[dabreegster]

I need to figure out how to repro this, but I lost everything on the map after making something:

[Pete-Y-CS]

Yep I ran npm run test not check. Solved most except an issue with turf bbox is puzzling because it was simply me moving around some code which preexisted

[dabreegster]

Another bug: if I delete the default subscheme and wind up with none, then creating something new breaks:

There are enough big structural changes here that I think some Playwright tests would be helpful. How about:

• creating a feature
• creating a new subscheme and moving the feature to it
• deleting an empty subscheme
• deleting a subscheme with stuff in it
• deleting all subschemes
• splitting a route within a subscheme
• renaming a subscheme with features in it

[Pete-Y-CS]

Good idea, I'll get on em, type checks resolved

[dabreegster]

I'm happy to merge this into main and iterate. Some thoughts on follow-ups:

• We should discuss with our partner, but "super-scheme" and "sub-scheme" still feel semantically complicated to me. Also if you click "add subscheme", you wind up with "Untitled subscheme" and then "Unnamed scheme 1". I would vote to use "scheme" in favor of "subscheme", and think of "superscheme" just as "file that's been loaded" -- not sure of wording
• The list of interventions being nested under schemes feels a bit confusing to me, especially in the simple case of just one scheme. I would vote for showing the full list of interventions and just grouping by scheme. Something like: where that's my attempt at the eye open/closed for show/hide layer
• And if we auto-assign some colors (and let people change them), we can change on the map. And in map tooltips, show the scheme name in the tooltip