Summary
HASTE stores labels in three independent places, and the Projects-list Labels column counts only one of them. A project can have 1,311 interactive labels and a completed 200-building validation and still display Labels 0.
The three stores
| Store |
Endpoint |
Scope |
Written by |
| Interactive labels |
GetInteractiveLabels |
per model |
Interactive Labeler |
| Building validation |
GetBuildingValidation |
per imageLayer |
Building Validation tool |
| Drawn polygons |
GetLayerLabelingToolData |
per imageLayer |
polygon labeling tool |
GetDashboardData.labelsCount reflects only the third.
Evidence (same dev instance, same day)
| Project / layer |
Drawn polygons |
Building validation |
Interactive labels |
Dashboard shows |
jamie_test / a90386c9… |
9 |
0 |
— |
9 |
Cameron and Scout / e7fbe9ec… |
0 |
200 |
1,311 |
0 |
The drawn-polygon features carry properties.source = "Drawn|Imagery" and primaryClass = "Damaged Building" | "Building" — hand-digitised outlines, which is a different task from both interactive labeling and building validation.
Second, larger problem
For an imagery + Rapid Building Assessment workflow, the counted store appears to be unreachable, so the counter is structurally guaranteed to stay 0:
- the Labeling column offers only Embed
- the row overflow menu offers only Export Labels to GeoJSON, Download Building Footprints, Download Valid Area Mask, Edit, Remove
- direct routes
/label/…, /labeling/…, /labeltool/… all 404
So this isn't a matter of the user doing more work — there is no action available that makes the number correct.
Impact
The dashboard actively misrepresents completed work. A reviewer scanning the Projects list sees a finished, validated assessment as an untouched project. It also caused real confusion during our run: the 0 was reasonably read as "the labels didn't save", prompting an investigation into data loss that turned out to be a display problem.
Suggested fix
Sum all three stores, or split into separate "Drawn / Interactive / Validated" columns. At minimum, don't display 0 when 1,511 labels exist.
Summary
HASTE stores labels in three independent places, and the Projects-list Labels column counts only one of them. A project can have 1,311 interactive labels and a completed 200-building validation and still display Labels 0.
The three stores
GetInteractiveLabelsGetBuildingValidationGetLayerLabelingToolDataGetDashboardData.labelsCountreflects only the third.Evidence (same dev instance, same day)
jamie_test/a90386c9…Cameron and Scout/e7fbe9ec…The drawn-polygon features carry
properties.source = "Drawn|Imagery"andprimaryClass = "Damaged Building" | "Building"— hand-digitised outlines, which is a different task from both interactive labeling and building validation.Second, larger problem
For an imagery + Rapid Building Assessment workflow, the counted store appears to be unreachable, so the counter is structurally guaranteed to stay 0:
/label/…,/labeling/…,/labeltool/…all 404So this isn't a matter of the user doing more work — there is no action available that makes the number correct.
Impact
The dashboard actively misrepresents completed work. A reviewer scanning the Projects list sees a finished, validated assessment as an untouched project. It also caused real confusion during our run: the 0 was reasonably read as "the labels didn't save", prompting an investigation into data loss that turned out to be a display problem.
Suggested fix
Sum all three stores, or split into separate "Drawn / Interactive / Validated" columns. At minimum, don't display 0 when 1,511 labels exist.