-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mask "Experiment" to support metrics for AOIs and VBs #550
Labels
enhancement
New feature or request
Comments
Tasks:
** Check if there are other tables with column references or foreign keys that will need to be rebuilt.
Stop short of Metric, analysis, climate engine enhancements. These will come next in a separate ticket(s). |
Research
Revised DB Migration Workflow
INSERT INTO SampleFrames (Title, Attribute1, MetaData) SELECT (Title, Attribute1, encapsulate primary key in JSON) FROM Masks; For the MaskFeatures, we need to join using the old MaskID, but then insert the new sample frame ID. INSERT INTO SampleFrameFeatures (SampleFrameID, geom, attribute1) SELECT
(
SELECT SF.SampleFrameID, geom, attribute1) FROM MaskFeatures MF INNER JOIN
SampleFrames SF ON MF.MaskID = SF.json_extract_value("MaskID")
) |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Fundamental Need
Users need the ability to create analyses using AOIs, valley bottoms and other polygon layers. Currently we only support doing this for sample frame polygons.
AOIs might be single polygons (catchment polygons delineated usung stream stats) or multi polygons (fish extent polygons scattered across a HUC10).
Users want the full analysis experience for these polygons. They want to hoover GIS or manually enter metric values for these "big polygons" just like they currently do with small DGO polygons. If they import VBET level path polygons they might want to enter metric values for each level path, or for the entire watershed valley bottom.
Conceptual Solution
A bit like when we genericized data capture event features using the "3 feature class experiment", we are going to genericise storing of input layer polygons in a single feature class.
Sample Frames, AOIs, Valley bottoms and any other layers for which we want to perform analyses, will have their features stored in a single "MaskPolygons" feature class. The rows in this feature class table will join to the MetricValues table (much like sample frames currently do) allowing for storing metrics for any of the mask types.
"Masks" and "MaskFeatures" will be terms that only appear in the database. Sample Frames, AOIs etc will retain their current names in the user interface and their position in the QRiS project tree will not change. In other words, what's changing is just the data storage. It's presentation to the user will remain unchanged.
drawing
The text was updated successfully, but these errors were encountered: