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

USBR RISE #81

Open
ksonda opened this issue Oct 9, 2020 · 2 comments
Open

USBR RISE #81

ksonda opened this issue Oct 9, 2020 · 2 comments

Comments

@ksonda
Copy link
Member

ksonda commented Oct 9, 2020

@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
Copy link
Member

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
Copy link
Member Author

ksonda commented Jun 11, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants