There are so many great things to do outdoors in Hawke's Bay, sometimes it's tricky to choose just one. But, environmental conditions such as weather, water quality, sea conditions and air quality can all affect our activities.
Many people look at the weather before they go and work or play - either out of the window or online. There's goodly amounts of information available about other aspects of the Hawke's Bay environment, but it's in lots of different places. Some websites even have multiple pages showing related data. It's sometimes not easy for the user to find the information they need.
This project turns data provision around, by focusing on what the user wants to know, rather than what the data provider is choosing to make available. It is intended to bring together a wide spectrum of data on the natural environment, to help users find suitable places to go and play (or work). The project takes the user's perspective - allowing them to ask "where can I..." do the activity I want to do? These are 'Where can I...?' modules.
The general principle behind 'Where can I...?' modules is that new modules can readily be designed to inform specific recreational activities. Not all activities need the same conditions: High wind is good for windsurfing, but bad for ocean swimming. In this way, data from different sources can be used to help users decide where and when to go and have fun (or work!).
The user can select modules for activities they want to do. We've placed 3 example 'Activities' in the drop-down at the top of the interface. They are 'Do general things', 'Swim' and 'Fly kites'.
In a fully-implemented application, the user would choose a module, which would display sites with data suitable for that activity, then set max and min conditions for attributes that are key to their activities, using parameter sliders below the drop-down. The sliders dynamically re-colour data points on the map to show where the conditions are within the min-max range set by the user. The map displays where it's suitable to do that activity. Clicking on any mapped point reports data available at that site in the panel to the right of the map.
For 'Do general things' we have 'Air Temperature', 'Humidity' and 'Wind speed' sliders. For 'Swim' this would include 'Water temperature' and 'Turbidity'. For 'Fly kites' this would include 'Max Wind Speed' and 'Wind Direction'. These haven't been implemented yet.
As an example, the 'Swim' module would collate information from monitoring sites for weather and sunshine, water temperature of rivers, lakes and the sea, and bacteria levels. A user might wish only to show river sites where water temperature was more than 20 degrees Celcius, and where E. coli counts were less than 260 per 100 ml - a clean, warm bathing spot. (NB, the E. coli and Enterococci limits in the NZ Rec Water Quality Guidelines are complex, and are not fully represented in the prototype.)
The modules bring data from the Hawke's Bay Regional Council's (HBRC) environmental datasets through XML calls to their Hilltop server. They could also aggregate data through Metservice's Python API, the lawa.org.nz API and from any other relevant environmental data source. New modules can readily be created by using suitable key attributes on the sliders. The number of sliders could be increased to suit specific activities, and a user-selectable attribute could be added to a dynamic slider if required. These features are not yet implemented.
The data are stored in a MySQL database hosted on AWS. A Node.js server hosts the web application, with Leaflet providing mapping services on HTML via MapBox. We've aggregated data from HBRC's Hilltop server to the MySQL database on AWS. The HBRC server is polled every 15 minutes to provide just the most recent value for each parameter. HBRC collect data at intervals varying from 5 minutes to 24-hourly. However, some data are only collected during particular seasons, such as the summer Rec Water Quality programme. Although the prototype reports these values, a full application would exclude them, because they can be up to 8 months out of date.
All monitoring sites available are mapped in the prototype. Where no data exist or the data don't match the user-set filters, the site is coloured orange on the map. Sites that match all the user-set filters are coloured dark blue on the map. Sites that partially match the user-set filters are coloured light blue. Sites with red map points are 'unsafe' - being outside the user-set filter limits. Pop-up messages provide additional feedback to the user on the status of each site, taking into account the user-set filters.
We've provided designs for the finalised concept for both a website and a mobile application. These improve the basic user-interface elements that exist at present, to make the application as easy to use as possible. Both the website and the mobile applications are intended to allow a user's location to be identified, and to use that to place a local focus in the map. There are some incompatabilities between the sliders developed in Materialize CSS and Firefox. These could be worked around.