Notes from 10/20 version

[emilyeros]

In no particular order...

Tables, etc

• Fix bug that's not saving the data when applied from a template
• Add alphabetical sort for label types (and a feature ID so we can sort temporally (which preserves a geographic order too)). (This could replace the filter search box if you like. Sidenote: Using the filter search box was a little awkward... when I start making changes to a group of filtered features, I often get kicked back out to the unfiltered table.)
• Curb paint subtype is disabled and should be enabled... this used to be there but disappeared
• (maybe harder than it sounds) Checkpoints for saving data to prevent losing everything if someone accidentally hits "back", refreshes, or has a browser crash
• When entering a regulation (second table), the timespan template name should autocomplete the same way that regulation template names do in the first table. (Otherwise it's hard for a user to remember what the previous timespans were called)
• At the end: @emilyeros to go through and replace some technical names (rate, duration) with more user-friendly/intuitive names. Might involve tooltips.

Could not reproduce: multiple boxes were selected and do not unselect. Will try to replicate this and add the console error.

Map

• Move highlighted map span to the top of the pile
• Geometries all seem to be appearing on one side of the street... even when I've mapped both sides. Can you confirm that the spans are being created correctly, @kpwebb? If so, then it may be a visual offset issue
• Minor styling change, not important: Make spans a bit thinner at higher zoom levels so that they don't dominate the map

[emilyeros]

One more:

• Export not working...

[peterqliu]

Knocked out most of these with the most recent commits. Of note:

• trying out a satellite style for the map. a bit noisier, but hopefully the visual context will help orient users to the span they're working on. Map also zooms into the active span as you go down rows in the spreadsheet:

• spans are now offset to a side of the street, but this introduces criss-crosses at intersections (see above) where geometries aren't trimmed at the terminals

Fix bug that's not saving the data when applied from a template

Export not working...

• I THINK these are fixed, but not 100% sure I reproduced the bugs in the first place.

[emilyeros]

Taking a spin through this now. Some comments:

• I like the satellite imagery in theory but it's a little tricky to see the blue of the spans. Could we change the color to stand out more (maybe red?). Alternatively, could have a toggle to choose between map view and satellite view.

• Was able to reproduce the many-selected-cells thing. Screenshot from the console:

• Asset subtype is a little quirky... If I have asset type=curb cut, I get a dropdown of potential values for asset subtype but none of them are actually valid inputs for curb cut; they are things like "yellow", "zigzag", and "parallel parking" rather than stuff like "driveway". Meanwhile. if I have asset type=curb paint, then I get an empty textbox and have to type in "yellow". So in the first case we allow users to input invalid options and in the second we require text. Ideally, we have a dropdown of asset subtype options that correspond to the asset type. Or if that's hard, we could have the same dropdown for asset subtypes even if there are invalid options. Or text input for all asset subtypes.

• Quirk: hitting "enter" on a timespan template name causes the payment profile fields to expand. This also happens if I take a regulation and apply a timespan template name from the dropdown:
  

• Can confirm that export kicks out two files. Can you change the asset points export to be a .geojson file extension? That is easier for GIS engines... they like it to be explicit.

• Assets export has a bug where the output file has asset type = curb cut for all features in the dataset, even those that are not curb cuts and were classified as signs in the digitizer. (Related: asset subtype is empty for all features, even curb paint. But that might be because the curb paint asset type was overwritten with type = curb cut)

• CurbLR json export: Can remove "label" and "ref_side" from the location properties. Once we have ID's in the backend, we can add those in (cc @kpwebb ). Features have payment = foo where payment should be empty. Many properties come out with a value of null instead of just an empty array or quotes (does that matter?). I thought we were going to paste a default manifest at the top?

[emilyeros]

one more thing to document: the curblr feed also includes point features for fire hydrants, which are noncompliant. this is fine for now - tagging @kpwebb who'll be working on transforming those points into spans before they are exported into the digitizer

[peterqliu]

most changes are in per #3 ^ converted the bullets above to checkboxes, and the ticked ones should be resolved. Notes:

Assets export has a bug where the output file has asset type = curb cut for all features in the dataset

Looked into this, and realized there's a bit of ambiguity: we're assigning assetType and assetSubtype to assets, based on the corresponding properties on the spans with shstRefIds that match the asset's. However, it looks like there can be multiple spans with the same shstRefId (at least in the sample survey), with plausibly different values for those properties. In those cases, which span should the asset take after?

Was able to reproduce the many-selected-cells thing. Screenshot from the console:

the console is helpful, though do you recall how you got to this bad state? let me know if it happens again

[emilyeros]

For assets - not sure I'm interpreting this correctly... Multiple spans with the same shstRefId is fine, because that reference ID refers to the street itself and we don't expect these to be unique in the feed. But each span in the feed should have the asset type that was entered for that span. (It's possible that there may be paint, signs, and other assets that all denote the same rule. We only allow users to enter one asset type, so it's up to them to determine what the "primary" marker is. For example, a handicap space often has paint on the ground and a sign; I mark those with a sign because it's the most obvious, visible marker. In any case, they'll enter one asset type for the span and we just need to port that into the feed for that particular span's regulation(s).

The bad state isn't triggered by any obvious behavior; it just happens sometimes when I'm clicking around. There's not a particular copy-paste or text input or dropdown selection action that causes it. Sorry I can't be more helpful.

I pulled in the updates and I'm getting an export error now. Screenshot is below with the console error:

Another issue: halfway through digitizing, a bunch of features that I had already digitized suddenly had images that wouldn't load (or were taking ages to load and didn't appear). Not sure what was up there... The only interesting thing about that particular round is that I left the digitizer open and running overnight to simulate what could happen if someone paused for a long time between entering data. Screenshot of console with missing images when this happened:

Right after the previous images disappeared, the multiple cell select behavior showed up.