Mobile ETo
This mobile application would give users the ability to see current, past, and average weather conditions, as they affect ETo, for the state of California. The application will allow users to either search for a particular city or zipcode, or geo-locate to their current position.
The application will be built using Polymer WEb Components. The data will be created and stored using cloud-based services. A simple web API will allow communication with the data. The API can be used without a key, and by other services. The original intent was to use DWR's standard Web Service API, however, it has been determined not to use these services so as not to impact their utility with an added burden of service requests.
Currently, the [prototype application] (http://watershed.ice.ucdavis.edu/mobile/) is only in template form.
The above drawing shows an overview of the server side processing. The reason for using Amazon SOS services are to reduce the overall cost of the system, and to provide more exact details on the cost of operation for the service. The underlying technology, REDIS, and Postgres, are open source tools, and can be replicated on the DWR website as well at a later date.
Phase 1 is the minimum requirement to get an application on online. For this, the current CIMIS Spatial data system currently operational is used as the input to the system. This system updates the REDIS database on a daily basis, as new data arrives. This requires only the Amazon SOS REDIS server, and a small 24/7 Amazon server to provide http access to the system. _ If Amazon provides external access to it's REDIS service (unlikely), it is also possible to provide httpd access via another server, either via DWR, or via Google App Engine for example. Using App engine could provide a method of authentication as well. _
At this point, only 14 data will be available to the client. However, we anticipate that will support 95% of the mobile requests.
Phase 2 will provide historical and yearly data support to the application. This requires a much larger dataset to be provided by the system, both to serve the yearly data, and to provide input to the historical data. We chose to use Amazon RDS (Postgres) as a system for this to provide a path for long-term access to an SQL enabled version of the Spatial CIMIS data. This can, in-turn, be used as a backend for alternative access methods to the Spatial CIMIS system.
Phase 3 is out of scope of the original proposal, but is something of a requirement if an alternative location for the Spatial CIMIS program is desired. In this case, the entire spatial CIMIS setup is replicated on a secong processing service under Amazon. This would in essence, replace the Spatial CIMIS application being run at the UC Davis.