-
Notifications
You must be signed in to change notification settings - Fork 31
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
WDC GetSeriesCatalogForBox3 provides richer response and more search parameters than GetSeriesCatalogForBox2 #1931
Comments
Thanks for looking in to this. Do we want to display series or sites? Our current implementation uses |
Ah, I didn't fully catch that. Got it. Using BTW, for future consideration: it occurred to me that currently there are only 94 "data services" in WDC (ie, the maximum total that can be returned by |
Because there are so few services, the |
One advantage I see in using |
Just for reference, this is a broader difference between the A |
Yes! I agree with Emilio that we want to focus on the information in the The hierarchy of this information model here is that:
We want to organize our returns by Sites, but display (and search) the info on all the Series at each Site. |
FYI, specially for Anthony: I've updated the notebook gist I mentioned at the start of this issue, to include examples from both |
@kdeloach and @ajrobbins , I had a conversation with @emiliom on Friday where we carefully explored the best approach for searching CUAHSI Water Data Center (WDC) and compiling the output provided to the user. We used these resources to inform our discussion:
The approach below resolves the open question about whether to use GetSitesInBox2 or GetSeriesCatalogForBox3. See #1858 and #1931 for more details. This will allow us to move forward on the CUAHSI WDC #1945. @emiliom can add where necessary. A. These are the GET requests that Azavea should use:
B. Azavea should develop a means to combine and filter GET request results in the following ways.
C. Later on, Azavea should develop a client-side means for filtering SiteRecords via a free-text search of all the terms in all the fields of the combined, hierarchical Site+Service(s)+Series result. Described in #1936.D. We will likely want to develop Constructors to build (and expose) user friendly URLs for Services and selected Sites, which resolves the questions in #1859.
|
These changes have been implemented in PR #1959. Check out the screenshots to compare the differences. Notes:
We still don't have access to these fields for each resource:
This is a known issue, but the We can dynamically generate URLs for each resource, if necessary. However, we don't need to generate URLs for services, since that is already available from the |
Yes, that's expected, as Anthony has mentioned above.
There's much more metadata coming in! See @aufdenkampe's comment above. Maybe what you mean is that there isn't much more metadata for the subset of metadata defined in your common dataset record metadata? Assuming this interpretation I'm making is correct, I guess that would be true b/c that dataset record metadata did not encompass the additional information Anthony listed in B.1.b that comment above (except for beginDate and endDate).
These do not exist in the WDC response, per se. But that should be ok. Depending on how
Ok. I guess this depends on the roll-out of the fixed WDC Catalog API, which hadn't been released as of June 7. |
With Kevin gone, I don't know if @rajadain is now automatically pinged. So I'm pinging him here. |
Thanks for pinging me @emiliom, I'll subscribe to all issues created so far so that I'm notified. I'll go through the discussion and respond here shortly. |
After reading through the comments in #1959, I think it's clearer we have a misunderstanding about what Anthony's and my intent was. It's clear that in that PR, the metadata specific to a "series" (which is sort-of a synonym for "variable" is thrown out. Anthony and I will submit a much more specific request/recommendation for what should be shown in the WDC dataset record boxes on the UI. |
Thanks, we'll wait for that. |
Just a couple of references, for future use:
|
@rajadain, we just created the Sample_WDC_Site_Record_BiGCZPortal_SearchResult Google Doc to provide an example record to display. In brief, output should look like this: NWISDV:14113000 Which would be constructed from this set of responses:
Please see the Goolge Doc for better formatting and additional info. |
Thanks @aufdenkampe. I just tried out Since this set of information isn't a lot, were you thinking this to be in the "list" view or the "detail" view? It could very well fit in a list view. I was unable to find examples listing multiple And, just to confirm, the site name links should only be generated for those that have One potential use of "variable linking" would be to filter results by the clicked variable. Other ideas may present themselves as we progress further along the implementation. |
Try this: If you'd like to examine it using my jupyter notebook, these request parameters worked for me: bbox1 = (39.9, -75.2, 40.0, -75.1)
keyword = ''
start_date = '01/01/2016'
end_date = '12/31/2016'
Neither here nor there. It just seems more obvious than a comma, plus some of the "variable" (
Yes, but I believe you should also add NWISUV, and possibly NWISGW (both USGS services). No other services, for now. |
@kdeloach, I think you (and I) have so far not done much testing on the WDC
GetSeriesCatalogForBox3
API query. My "series" queries have focused onGetSeriesCatalogForBox2
(eg, this notebook). But it turns out thatGetSeriesCatalogForBox3
has two important advantages:sampleMedium
,dataType
andvalueType
. Out of those, probably onlysampleMedium
is actually valuable for our likely use casesI ran a test, and
GetSeriesCatalogForBox3
seems to work fine, though probably with the same current bugs and keyword limitations as inGetSeriesCatalogForBox2
.cc @aufdenkampe
The text was updated successfully, but these errors were encountered: