internetofwater / geoconnex.us

URI registry for https://geoconnex.us based URIs
Other
24 stars 16 forks source link

USBR RISE #81

Open ksonda opened 3 years ago

ksonda commented 3 years ago

@amabdallah and I had a good conversation with Allison Odell at RISE. In principle, she seems supportive, and schema.org markup was already on their road map for the next year, so the marginal effort we're asking of them isn't very high. Some issues came up that will be good to keep in mind both for that system specifically and more in general.

  1. RISE is a highly general data-sharing platform that includes an interface to time-series data but is mostly just a very CKAN or Geonode-type CMS/DMS. Landing pages are organized into Catalog Records that link to Catalog Items. Catalog Records are diverse, and could be something similar to USGS Monitoring Location pages, or more like this, a bucket for some random, non-georeferenced report. Catalog items are anything related to the record, and might be a link to a PDF or links to time-series data query GUIs. Multiple catalog records might be about something going on at the same location. There is a table on the back end that associated Catalog Records to Locations, but currently Locations don't have landing content or HTTP URLs.

Questions: Would we like to try and persuade them to make Locations landing content that link to relevant catalog records? Or just have them mint PIDs to Catalog Records that are relevant (e.g., ones about Dams/Reservoirs and monitoring locations).

  1. RISE conceptualizes a major observational location as a "Dam and Reservoir" as a single concept.

Questions: Do we want geoconnex.us/ref/dams/ to identify only physical dams, or think about it similarly to the way USBR does?. Should there be geoconnex.us/ref/waterbodies that geoconnex.us/ref/dams link to? And we ask USBR to say their pages are about: items in both?

dblodgett-usgs commented 3 years ago

This is great!!

There may be something to use in the HY_Features "reservoir" and "impoundment" storage model with regard to how to deal with Dams and Waterbodies.

http://docs.opengeospatial.org/is/14-111r6/14-111r6.html#_surface_hydro_feature_concepts

http://docs.opengeospatial.org/is/14-111r6/14-111r6.html#_the_storage_model

Re: having their loction information exposed, I think that would be ideal, but maybe not critical as long as we can get the catalog pages linked to appropriate community locations. One less layer of indirection out in the open would be kinda nice.

ksonda commented 3 years ago

Had a really good call with USBR today. System is well set up for this, they are going to have a very nice setup for linked data:

/locations (X dam + reservoir, X stream gage)

linked to

/catalog records ("modeled operations data for X dam + reservoir", "observed data for X dam + reservoir")

linked to

/catalog items (1 time series per observed property)

Think would be very natural to implement linked data resources similar in structure to https://opengeospatial.github.io/ELFIE/usgs/nhdplusflowline/uswb/010300032404 (location/ feature of itnerest) -> https://opengeospatial.github.io/ELFIE/usgs/nwissite/uswb/01049265 (sample?) -> https://opengeospatial.github.io/ELFIE/usgs/pr/uswb/010300032404 (observation)

We need to think about giving them a pretty step-by-step of what to do though. Linking to new generalized issue #113