hydroviz data via API

[Joshdpaul]

This PR adds an endpoint to access data for the SECASC Hydroviz project. Append a unique identifier for stream geometry features (i.e. geom_id) to the route URL to fetch data for that stream segment. For example:

http://localhost:5000/conus_hydrology/1000 to fetch data for stream segment 1000.

Data is pulled from both Geoserver and Rasdaman.

NOTE: the shapefiles on Geoserver and the coverage on Rasdaman will likely be updated or otherwise revised in the future, which will probably break things in this branch.

To test, set environment variables as below and start the app as instructed in the README.md:

export FLASK_APP=application.py
export FLASK_DEBUG=True
export API_GS_BASE_URL=https://gs.earthmaps.io/geoserver[/](https://gs.earthmaps.io/geoserver/)
export API_RAS_BASE_URL=https://zeus.snap.uaf.edu/rasdaman/

Confirm that this works in general, and check out the JSON output for a stream segment. Any ideas for improvement here? Should we incorporate more request flexibility into the route?

I was considering adding support for GET parameters to make specific requests, but I don't know if this level of granularity in the request will be necessary, or if we will always want the whole datacube for the stream segment (for example, something like: http://localhost:5000/conus_hydrology/1000?model=CCSM4&scenario=rcp85&vars=dh3,dh15,fl1)

ALSO NOTE: using Zeus prevents the app from starting (see this convo in Slack for details) so routes.__init__.py has been modified in the branch as a workaround. Therefore, expect that none of the other endpoints will work when running this branch!

[cstephen]

@Joshdpaul, I may have jumped the gun reviewing this since it is in draft mode, but I noticed that the hydrology GeoPackage / shapefile doesn't appear to be hosted on GeoServer at the moment. I.e., this URL returns an HTTP 404:

https://gs.earthmaps.io/geoserverwfs?service=WFS&version=1.0.0&request=GetFeature&typeName=hydrology:seg&propertyName=(GNIS_NAME,the_geom)&outputFormat=application/json&cql_filter=(seg_id_nat=1000)

Also, there are a few places in the code that try to write to your home directory. No biggie, though, as these can be commented out for testing if this PR is still in draft mode.

[Joshdpaul]

Ah @cstephen I see what happened! The code block with environment variables in the PR description got garbled! It leaves out the / in the ....geoserver/wfs.... part of the base URL. It should be like this:

export FLASK_APP=application.py
export FLASK_DEBUG=True
export API_GS_BASE_URL=https://gs.earthmaps.io/geoserver/
export API_RAS_BASE_URL=https://zeus.snap.uaf.edu/rasdaman/

As for the reference to my home directory, I totally forgot to comment those out. You can zap them or change to a different directory if you are curious to see the individual data packages that are fetched from GS & Rasdaman.

[cstephen]

@Joshdpaul, this works on my end now, too, using the environment variables from your latest comment. And this is awesome! Very impressive progress, and it looks you have put nearly everything (or maybe even everything) we need in place to start developing a webapp prototype.

I used the OpenLayers preview in GeoServer to interact with the "hydrology:seg" layer, tried clicking a point in the layer preview, then coped & pasted the segment ID (26084) into the API URL like this:

http://localhost:5000/conus_hydrology/26084

And verified that the segment name from GeoServer matches the API output.

The 376kb API response seems reasonable, but if we do ultimately end up showing only a small subset of the stats on the webapp, it'll likely be worth adding support for the vars GET parameter to handpick which stats are returned and cut the response size down to a half or less. It may be too early in the process to do this, though, as we'll get more guidance from others on what stats are needed.

One small issue I noticed is that it looks like we'll need to reproject the latitude and longitude values in the API response to actual lat/lon values. It looks like the values are X/Y coordinates from a non-lat/lon projection currently:

{
  "26084": {
    "name": "Pomme de Terre River",
    "latitude": 1591022.5996,
    "longitude": 261685.3833,
    ...
  }
  ...
}

Fantastic work!!