Checklists: How should we handle them?

[danrademacher]

https://dev-ecoengine.berkeley.edu/api/checklists/

there are only about 50 checklists. We're going to hold off on dealing with them till we manage the other major data types. And it seems like these are relevant when you're doing a footprint search

[postfalk]

Maybe a general comment on this: checklists, photos, plot data are collections of observations that are also represented in the /api/observations/ endpoint. They just create a many-to-many relationship to a more complicated entity such as a photo, a plot survey, or a inventory list (there will be others, e.g. drill cores.) and add some additional attributes to the "composite" event (and in some cases also on the the relationships, see https://dev-ecoengine.berkeley.edu/api/vtmplots_brushes/.

Because that is such an essential structure, we should review this more thoroughly together with @mkoo.

Data will show up in two places: The "composite event" and the single observations associated with them. Maybe it would be cool to present different observation types with various symbols and link back to the composite event (latter needs to be implemented in the API).

[danrademacher]

@postfalk: Can we assume then that everything other than Layers and Rasters will be represented in the Observations table in some way?

[postfalk]

Only if a species is associated with it - which is not always the case, especially not for photos. @mkoo has more to say

On Thu, Oct 2, 2014 at 2:09 PM, Dan Rademacher [email protected] wrote:

@postfalk https://github.com/postfalk: Can we assume then that everything other than Layers and Rasters will be represented in the Observations table in some way?

— Reply to this email directly or view it on GitHub https://github.com/stamen/ecoengine/issues/15#issuecomment-57708506.

Falk Schuetzenmeister, PhD Web Application Developer Geospatial Innovation Facility http://gif.berkeley.edu/

University of California Berkeley 111 Mulford Hall 94720 Berkeley, CA

[email protected] 1-510-642-4897

[syntagmatic]

Many-to-many relationships don't really fit within the current multi-endpoint interface, which focuses on flat lists of observations/sensors/etc.

A good way to treat this would be either:

• A standalone detail view for checklists/photos/etc that lists observations within it
• A singly-nested table that can treat a list of objects which each contain a list of observations