WQX

[ksonda]

Let's add them

• which namespace? /wqx? /epa/wqx?
• do we want to pilot out some jsonld content for them and host them at info.geoconnex.us, or put that in a roadmap for WQP?

[jkreft-usgs]

Good Question! The goal being to add all the monitoring locations that are part of the Exchange Network Water Quality Exchange? (e.g. the EPA part of the Water Quality Portal?)

[ksonda]

Ah yes. that raises another question. Should there be WQP? and do some sameAs -ing between the WQP and NWIS, WQP and Exchange Network, WQP and other ocntributory systems.

[dblodgett-usgs]

We certainly want PIDs for the water quality portal monitoring location pages and it would be good for those pages to link to reference features in info.geoconnex.us. We could create something akin to ref_gages that is more generally monitoring locations for that. The set of locations in the portal would be a good source to build that out.

[ksonda]

given how you've defined gages so far im not sure what would distinguish this reference set from ref_gages exactly.

[ksonda]

asnwering my own question, non-stream locations. got it.

[dblodgett-usgs]

Yeah -- "gage" is often thaught to measure flow but anything can be monitored at a gaging location. I could have called it reference_stream_monitoring_locations but that seemed a little overdone ;)

[ksonda]

mkay, so what im hearing, for now, is we're going to make two sets of PIDS,

• /ref/monitoring-sites?/
• /wqp/sites? /nwqmc/wqp/sites?

where the monitoring-sites are in info.geoconnex.us and subjectOf the WQP PIDs, and for now they will be the same set of features (all the wqp sites). Maybe the monitoring-sites that are also in NWIS are also subjectOf the /usgs/monitoring-location PIDs.

[dblodgett-usgs]

Or we do:

• /ref/wells/ in addition to /ref/gages/
• /wqp/sites/

Where wqp sites are sameAs USGS and/or EPA and/or state data sources and are about / subjectOf with the appropriate reference feature.

[ksonda]

WQP has all kinds of weird other site types like distribution system samples and internal facility samples and such though, which eventually should go in probably.

I see why your way is conceptually cleaner, its just more long term maintenance work. we can bite off ref/wells as a start though and use WQP wells as a base, we've been meaning to do that anyway.

[dblodgett-usgs]

I like the idea of having a super set of reference locations that are either special or sameAs to the gage or well set.

[ksonda]

mkay so we're saying 3 levels of stuff now?

• /ref/monitoring-sites -^sameAs
• /ref/gages, /ref/wells, and later on /ref/facilities etc.
• ^subjectOf
• /wqp/sites, usgs/monitoring-locations/, state-agency/gages, etc.

[dblodgett-usgs]

The sameAs isn't really necessary as a level if we want to have a ref/foobarbaz/ for things that don't fall in a major category.

[ksonda]

Im thinking if we shunt everything "not cateogrized" into /ref/foobar, then we have to mint new PIDs that are sameAs the PIDs in /ref/foobar if a new category justifies itself down the line.

Vs. 3 levels, where the top level can be part of a workflow that is auto-maintained from the set of location type namespaces as they emerge.

[ksonda]

we can just make /wqp/ for now just so it's there. regex?

[dblodgett-usgs]

What do you think @jkreft-usgs ? Site pages are like : https://www.waterqualitydata.us/provider/NWIS/USGS-AL/USGS-02339215/

[jkreft-usgs]

I think that's fine for now, and then we can figure out more later.

[ksonda]

For now, the YOURLs-based PID server can really only handle regex for the "basename" of a PID (thing after the last "/"). E.g. only USGS-02339215 would get passed through from something like https://geoconnex.us/wqp/sites/NWIS/USGS-AL/USGS-02339215

Having @webb-ben look at this.

Short term workaround could be a series of regex PIDs that are based on data source and provider

^wqp/sites/NWIS/USGS-AL/{id regex} --> https://www.waterqualitydata.us/provider/NWIS/USGS-AL/{id regex match}

^wqp/sites/STORET/NC-WQX/{id regex} --> https://www.waterqualitydata.us/provider/STORET/NC-WQX/{id regex match}

and so on. And maybe in WQP case this is an appropriate way to do things anyway, since PIDs are supposed to be organized around "organization" in some sense.

[ksonda]

lol nvm. https://github.com/USGS-R/dataRetrieval/issues/434#issuecomment-522230798

Ill prioritize fixing pid server

[ksonda]

apologies for earlier today when the hu10 was down @dblodgett-usgs , I hope that wasn't a bad hiccup for something you were trying to show off or test.

However, fixing that error resulted in us figuring out some other stuff, resulting in this pattern functioning for WQP:

https://geoconnex.us/wqp/([_a-zA-Z0-9/-]+)$

eg

https://geoconnex.us/wqp/NWIS/USGS-AL/USGS-02339215/

IDK if @jkreft-usgs is the appropriate "owner" of WQP redirects but seems like as good a person as any if you would like to reconstruct this through a PR and create the /wqp namespace.

This csv should be sufficient (or change /wqp/ pattern as you like..idk /wqp/sites? /wqp/stations/?

id	target	creator	description
https://geoconnex.us//wqp/([_a-zA-Z0-9/-]+)$	https://www.waterqualitydata.us/provider/$1	email	Water Quality Portal Sites

*edited to include extra "/" that denotes to the PID server a regex redirect

[ksonda]

This cool with you @jkreft-usgs ?

[ksonda]

@jkreft-usgs I've noticed in the NLDI now that WQP uri links are broken. URLs are like https://www.waterqualitydata.us/data/provider/STORET/WIDNR_WQX/WIDNR_WQX-10017576/ when they need to be like

https://www.waterqualitydata.us/provider/STORET/WIDNR_WQX/WIDNR_WQX-10017576/

Alternatively could replace with https://geoconnex.us/wqp/STORET/WIDNR_WQX/WIDNR_WQX-10017576/ or whatever :)

[jkreft-usgs]

blerg, that's a bug on the WQP side! I'll get a ticket in to fix it.