Generalize alerts secondary datasets beyond Mapeo - #563
Conversation
rudokemper
left a comment
rudokemper
left a comment
There was a problem hiding this comment.
This accomplishes the glorified "Find & Replace All" for "Mapeo" -> "secondary". But it is missing an important piece of the puzzle which I described in one of my comments. I think we should have another PR (targeting this branch) handle the required changes to config to allow users to pick their filter column, and specify values to include on the alerts dashboard.
Once the dust on all this has settled, we can rethink overall config UX in #435
| /** | ||
| * Warehouse tables that expose both `g__type` and `g__coordinates` (plottable secondary datasets). | ||
| */ | ||
| export const getGeospatialTableNames = async (): Promise<string[]> => { |
There was a problem hiding this comment.
The addition of this could have been its own PR. Think of how easier it would be to review this overall large PR, AND to follow the commit history of this project. I strongly recommend thinking about this for future PRs.
| emit("updateConfig", { | ||
| SECONDARY_CATEGORY_IDS: values, | ||
| MAPEO_CATEGORY_IDS: undefined, | ||
| }); |
There was a problem hiding this comment.
The concept of a "category" is unique to Mapeo.
If we are generalizing to any secondary dataset, then we need more general language and handling.
Currently, for Mapeo data, we hardcode a category field somewhere, and then in config, allow the user to pick the categories for which they want data to show on the map:
Now we actually need two fields:
- "Filter data by column" (to replaced hard-coded
categoryfield for Mapeo) - "Pick the values to show on the map" (the current equivalent of "Mapeo Category IDs to show on the alerts map")
We actually already have a "Filter data by column" field - we just don't use it for the alerts dashboard.
Confusingly, we also have a "Which values to filter out from the column" which does the opposite of what we need for (2).
But we can reuse the existing "Filter data by column" field, and then turn "Category IDs to show from the secondary dataset on the alerts map" into that?
Maybe this should be a follow-on PR, though.
| item.name === "Secondary data" | ||
| ? $t("secondaryData") |
There was a problem hiding this comment.
Whatever the name of the secondary dataset table is should show here, instead of "Secondary Data" which is not helpful to the end user.
71c81aa to
8366d8e
Compare
8366d8e to
57ac618
Compare
2 participants
Goal
Make the Alerts Dashboard secondary layer data-source agnostic: any compatible geospatial table can be configured and rendered, with generic “secondary dataset” terminology instead of Mapeo-specific naming, while existing Mapeo-backed alerts views keep working. Closes #544
Screenshots
What I changed and why
mapeoData→secondaryData,MAPEO_CATEGORY_IDS→SECONDARY_CATEGORY_IDS,mapeoDocId→secondaryDocId, layermapeo-data→secondary-data,feature_type: "mapeo"→feature_type: "secondary"isMapeoDataflagmapeoDocId,MAPEO_CATEGORY_IDS, andfeature_type: "mapeo"are accepted via migration or silent URL rewrite so existing views and deep links continue to workHow I convinced myself this is right
I confirmed the generic flow works for any compatible geospatial table while existing Mapeo-backed views remain unchanged through backward compatibility and targeted tests.
What I'm not doing here
mapeoDocIdURLsmapeo_dataor Mapeo schema docs/fixturesBasically nothing extrenous
LLM use disclosure
Cursor Grok 4.5 with me driving