Develop a plan on moving the service to SWRCB

[qjhart]

@brmagnuson sez... Just checking in on the status of this. The State Board is starting to murmur about getting started on porting the website over to their side rather than perpetually maintaining it at Davis, which I believe was the intent all along. I said you guys had some improvements you still wanted to make (mainly this issue) and I would check in and see how it was going.

[qjhart]

@jrmerz sez...

@brmagnuson Perhaps this should be a new ticket, but here is the breakdown for transferring the application.

Application assets (HTML, JS, CSS), basically everything in stored in this repository, needs to be hosted on a state server. The Postgres backend needs to be ported A Jetty/Tomcat/[Insert your java servlet server here] needs to be stood up The servlet server needs to host the custom Google Visualization Source build. The PG connection will need to be configured as well. The first item is easy. Just pull this repo down and host it on any web server. This will give you the main application as well as CSV upload and visualization. The next 3 steps are for the 'query' functionality. @qjhart do you want to chime in with more details on this?

Finally, we are still working out the solution for submitting data back to postgres instance (this ticket). @qjhart I think we need to have a more formal discussion about this if that functionality is required for the transfer.

[qjhart]

@brmagnuson / @jrmerz . OK, so I want to make sure that we are all on the same page here, so that we understand everything that our backend is doing, and what needs to be done.

• The server provides four sets of data; supply, demand, public health points of diversion, and finally allocation. The first three are inputs that go into the allocation model. All the inputs change, supply daily; demand about monthly; and public health maybe constant, or monthly, I don't recall.
• For the supply, the USGS site is queried everyday. For the demand and public health, the daily values are calculated with the data we received from swrcb.
• The last version of the dwrat solver that I saw used this server to download all that information. I don't know if that's the case or not anymore, I assume so.
• Results from the solver were expected to be uploaded to the server. Nick had written a tool that would output a single CSV file for that; but we know that's not well used, and there is no formal method for an "offical" upload. Hence this issue :)
• The reason for that upload step is to provide a public interface for that output, (Intra or Inter)net.

OK so...

• If SWRCB wants some online "offical" allocation to look at, then we need to figure out the upload step.
• If the current solver still uses the input data from the server, then we need to maintain the Postgres, Jetty backend, Justin describes above. It's not really that much work but needs to be maintained a bit.
• If that is required is to visualize the output of the solver, than that is a "mostly" client side issue, and requires less of a backend. I say "mostly" because I don't recall exactly where the things like "HUC" boundaries come from.

[jrmerz]

@qjhart great point about the HUC layer. Think that comes from a layer hosted over on Google Maps Engine, which is due to be shutdown soon and we need to find a replacement.

[jrmerz]

Updates on this issue

• HUC 12 rasters and vectors now coming from CWS ArcGIS instead of Google
• Watershed rasters now coming from CWS ArcGIS instead of Google
• App Id geolocation now coming from waterboards ArcGIS instead of CWS viz source (Postgres).

[nickrsan]

Hi all,

We're getting going on delivering this service to SWRCB again - @qjhart and @jrmerz I have two quick questions for you:

1) Did you deliver any code to SWRCB? There is some speculation that they might have an old version. I'm not sure if that's the case or not. 2) Is the summary of the technology in this issue still a good overview of what's involved? I can dig in and figure it out from there, but just want to make sure I'm looking for the right things.

Thank you!

[nickrsan]

OK, looks like it's a self-contained node app that relies on a water board GIS server and Google Docs - question 1 still stands though if you have a moment, and I may have questions about how uploads were handled.

[jrmerz]

@nickrsan Let me see if I can help here.

So no NodeJS. The app itself is a static web app. Files are either 'uploaded' (not to server, just added to client), then parsed and rendered on client. Or files can also be added to a public readable google drive directory, that how they show in 'Public Directory' (https://docs.google.com/spreadsheets/d/1ACi7P0pOy-JRjtw6HribQphhEOZ-0-CkQ_mqnyCfJcI/edit#gid=0). The Id column is the id of the sheet to be rendered. Both directory sheet and data sheet need to be public readable on google drive.

The (http://atlas.cws.ucdavis.edu/arcgis/rest/services/Watersheds/MapServer/0/query) service is then used to lookup region geometry while the (http://gispublic.waterboards.ca.gov/arcgis/rest/services/Water_Rights/Points_of_Diversion/MapServer/0/query) service is used to look up point information.

[nickrsan]

Thanks for the clarification Justin - that helps a bunch and will save me a bit of trouble looking for the geometry (I'd seen the reference to the Water Board services in the code, but not to Atlas).

So, I'd assumed that it was node originally because I saw the build instructions, but seems like I just have a misunderstanding about how this all works - I saw that it ultimately builds a static set of files (which is really nice construction for this, by the way). I'll take a look and see if I have any other questions, but I think for now I know enough to proceed and probably to get them the working setup.

Thanks again for chiming in!

-Nick nick@enviroconsumer.org

On Sat, May 6, 2017 at 9:08 AM, Justin Merz notifications@github.com wrote:

@nickrsan https://github.com/nickrsan Let me see if I can help here.

So no NodeJS. The app itself is a static web app. Files are either 'uploaded' (not to server, just added to client), then parsed and rendered on client. Or files can also be added to a public readable google drive directory, that how they show in 'Public Directory' ( https://docs.google.com/spreadsheets/d/1ACi7P0pOy-JRjtw6HribQphhEOZ-0-CkQ_ mqnyCfJcI/edit#gid=0). The Id column is the id of the sheet to be rendered. Both directory sheet and data sheet need to be public readable on google drive.

The (http://atlas.cws.ucdavis.edu/arcgis/rest/services/ Watersheds/MapServer/0/query) service is then used to lookup region geometry while the (http://gispublic.waterboards. ca.gov/arcgis/rest/services/Water_Rights/Pointsof Diversion/MapServer/0/query) service is used to look up point information.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ucd-cws/dwrat-app/issues/15#issuecomment-299649500, or mute the thread https://github.com/notifications/unsubscribe-auth/AApzMS1HzbGhwqSuySxVUR_DXCO_pih0ks5r3JrigaJpZM4Fa_6Y .

[jrmerz]

Ya, so the code is written using NodeJS/CommonJS Modules, they run through Grunt + Browserify to create a browser friendly package. Proly why you got thrown off. Here a couple commands of interest while developing

Commands

npm run init-dev

install NPM and Bower dependencies

npm run dev

Runs watch process. This watches for changes to the lib/shared js files and builds a new public/js/app.js file automagically after you make a change

npm start

Serves /public

npm build

Builds /dist

npm run start-dist

Serves /dist