Changes to MountainHub API list of returned variables

[aaarendt]

It appears the Mountain Hub API has changed the names for some of the variables we need. This will require changing the mountainhub.js code.

@aaarendt is working to figure out correct variable names.

[aaarendt]

See this PR for attempts to use Python for direct access to the API.

We need to find out which field contains the notes, for example to parse out the contest and SnowEx observations.

[aaarendt]

From David Hill: we seek to grab snow depths both from the 'snow conditions' option, but also the 'snowpack test' option. There are a lot of depths in the latter category that we would miss otherwise.

Be sure to check on this.

[emiliom]

From David Hill: we seek to grab snow depths both from the 'snow conditions' option, but also the 'snowpack test' option. There are a lot of depths in the latter category that we would miss otherwise.

From what I can tell on the current mountainhub.js code (last modified 11 months ago, on 2019-2-19), both 'snow_conditions' and 'snowpack_test' are already handled. I've also confirmed via Python requests that the API obs_type parameter being used in mountainhub.js still works with those two values.

We need to find out which field contains the notes, for example to parse out the contest and SnowEx observations.

Based on the responses with Python and browser requests, it looks like you've captured the main observation comment (record.observation.description) in PR #10.

[emiliom]

@aaarendt I've worked with your retrieve_from_MountainHub.ipynb Jupyter notebook, tweaking the code it and reissuing many requests. I've also examined the MountainHub JSON responses very closely, to wrap my head around it. Here are some observations and questions:

• Could you describe exactly what problems you're still having? Be specific about when you're referring to the web app (ie the Javascript code) vs the Python request in your notebook. You mentioned the change in variable names, but it looks to me like you've already addressed that in the notebook. You also mentioned recent data not being available, but that also seems fine (with a possible caveat -- more below) in your notebook.
• Using your notebook, I'm able to get the most recent data, as recent as the last 24 hours.
• I don't know what the old version of the API looked like, but the current version uses "pagination" and the service parameter limit to handle the number of responses. The current practice seems to be to set limit to a very large number (10,000), but if there's been a change in the API's maximum number of records returned in one request, you could be getting unexpected behavior.
• I browsed around the mountainhub web site and googled for their API. I could not find any documentation whatsoever on the API (request parameters available, acceptable parameter values, header parameters, etc). The endpoint itself (https://api.mountainhub.com/timeline) doesn't provide any documentation, unlike say a Swagger REST API such as this static example: http://odm2.github.io/ODM2RESTfulWebServices/. Is there a technical contact person at mountainhub who can answer questions about the API?

I'll issue a PR to push a new notebook, a modified version of retrieve_from_MountainHub.ipynb but with a new name.

[emiliom]

The PR with my new notebook is #13. The notebook has lots of notes

[emiliom]

@aaarendt have you had a chance to review where things stand, including my comments above and notebook? Let me know if you have follow-up questions that I can help with.

[emiliom]

@aaarendt could you add details here about the problem you're still seeing with the API, that we talked about on Friday? Specifically, you said you don't get any returns when you query for recent data for specific submissions done by your colleagues, which are visible on the MountainHub web app map.

• Can you describe what exactly you've tried when you couldn't get the results you expected? For example, the exact API request url or parameter & arguments passed
• Can you provide me with an example or two of the data from colleagues that is not being returned by the API? I assume there is a user name associated with each submission. Day and user name (or full person name) would be helpful

[emiliom]

Just wanted to note here that the validation repo also contains Python code to read from the MountainHub API: https://github.com/communitysnowobs/validation/blob/master/validation/MountainHub.py. That code has basically the same functionality as the one at cso-legacy-api, https://github.com/communitysnowobs/cso-legacy-api/blob/master/src/resources/obs/MountainHub.py. But they're not identical. Ultimately, we should consolidate these two and leave a single, well documented, master code (package?) to access the MountainHub API.

Both of these code bases were last updated in mid 2018.