Skip to content
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

Data Capture Distinctions #31

Closed
joewheaton opened this issue May 10, 2018 · 2 comments
Closed

Data Capture Distinctions #31

joewheaton opened this issue May 10, 2018 · 2 comments
Labels
discussion Discussion among BRAT developers and power users.

Comments

@joewheaton
Copy link
Contributor

@wally-mac and I were discussing some of @webernick79 work on the Arc Survey123 and ArcExplorer web apps (see also #29). We think the following are important distinctions and have tried to genericize this from a specific 'Validation' exercise or 'field app' to something more generic aimed at capturing additional data to serve different needs, but be captured in a Riverscapes Project (something @banderson1618 and @bangen can help us with creating placeholders in the BRAT Riverscapes Project). Those needs include (we'll want to split these out into specific issues with requests after we hash the details out):

  • Verification Exercises of specific inputs, intermediates and model outputs
  • Calculation of useful 'performance metrics' (i.e. comparisons of model outputs to data capture summaries)
  • Analyses and Calculation of Data (captured) summaries that provide independent metrics, graphs, tables, and map output summaries of the collected data; e.g.:
    • For Beaver Dam Counts
      • A layer of dam density (dams/km) for each segment (i.e. a field)
      • A summary of total dams, dam densities,
    • For Beaver Activity Surveys
    • For BRAT-cIS (i.e. BRAT Capacity Inference System)
    • For Vegetation Observations
    • For Nuisance Beaver Activities
    • For Nuisance Beaver Potential Impacts

@banderson1618 should think about where in the Riverscapes BRAT project the raw Data Capture Distinctions go (maybe a Inputs\DataCapture folder?), where the

Concepts of Data Capture

@wally-mac and I thought it made sense to genericize the concept of data capture into modes, sample-design, and spatial scale.

Modes

We see three<Modes> of Data Capture:

  • <Mode>Field-Based</Mode> - Note this is most likely done with Arc Survey123 using collector forms, from the 'field'.
  • <Mode>Desktop</Mode> - This is done at computer, in a browser through a Web App (e.g. Nick's example: https://www.youtube.com/watch?v=ieZPHtKUPxk)? @webernick79 can you clarify?
  • <Mode>Combined Field-Desktop</Mode> - This would be a mix of the two. For example, you went in the field, capture some observations, but maybe not a complete sample, and using your memory and having seen it on the ground, you augment the field sample with a desktop sample.

Sample-Desgin

We see the following types of sample-design worth differentiating:

  • <SampleDesign>Unstructured</SampleDesign> - This is just opportunistic, take points where you feel like it. These will often be biased, but still useful samples (i.e. people would go to where they are interested in or where they have easy access to.
  • <SampleDesign>Structured</SampleDesign> - By contrast a structured sample design would follow some pre-defined method, independently derived ahead of time (i.e. we make a draw of 50 sample locations (sample points or specific polyline reach segments or specific polygons like the valley-bottom thiessen polygons in RCAT or the 30m or 100 m riparian buffers from BRAT). Specific examples would include:
    • <SampleDesign>Structured - Random</SampleDesign> - random points within a defined extent (polygon) or along a defined route (polyline network)
    • <SampleDesign>Structured - GRTS </SampleDesign> - spatially balanced version of above
    • <SampleDesign>Structured - Stratified </SampleDesign> -
    • <SampleDesign>Structured - Systematic </SampleDesign> -

Spatial Scale

It is important to recognize that there is an implicit spatial scale from the data capture in terms of extent, resolution, spatial data type. For the most part, the raw data capture will always be vector, and the Sample Design explains how many. We don't need to define these independently, but recognize that the extent could be a watershed, a whole stream (collection of reaches). The vector types (points, polyline stream segments, and polygons (thiessen valley bottom polygons or 30 m or 100 m buffers in BRAT).

@joewheaton joewheaton added the discussion Discussion among BRAT developers and power users. label May 10, 2018
@joewheaton joewheaton added this to the Data Capture Apps milestone May 10, 2018
@wally-mac
Copy link
Contributor

One specific form of data capture that @joewheaton and I discussed was calibration of land fire existing veg data. So the idea here is we could take a sample of say 30 of each of the say approximately 30 land cover classes (n= 900) within our hundred meter buffer and do an assessment in regards to how the zero to four categories appear in the field versus how the landfire classification categorized these buffered stream segments. We could design the sample were we could collect many of these categories within a short distance to optimize the data collection.

@joewheaton
Copy link
Contributor Author

Good points Wally made in:

One specific form of data capture that @joewheaton and I discussed was calibration of land fire existing veg data. So the idea here is we could take a sample of say 30 of each of the say approximately 30 land cover classes (n= 900) within our hundred meter buffer and do an assessment in regards to how the zero to four categories appear in the field versus how the landfire classification categorized these buffered stream segments. We could design the sample were we could collect many of these categories within a short distance to optimize the data collection.

I think this discussion has run its course and I'm going to put your Data Capture request for LANDFIRE data in a new ticket. Note that the new BRAT cIS #35 gets us a good part of the way towards this in a BRAT context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussion among BRAT developers and power users.
Projects
None yet
Development

No branches or pull requests

2 participants