A Visualization Application for Anomaly Detection in Water Management Systems
Elias Eberhardsson
Computer Game Programming, bachelor's level 2018
Luleå University of Technology
Department of Computer Science, Electrical and Space Engineering
Sammanfattning
Denna rapport beskriver och går igenom processen med att utforma och implementera en applikation för visualisering av data relaterade till vattenhanteringssystem. Datavisualiseringen i fråga är im- plementerad på en kartvy. Uppgifterna tillhandahålls via Aquaductus sensorenheter vilka placeras i vattenhanteringssystem, dessa för sen regelbundet över data till Aquaductus databas. Applikationen kan både ge en snabb överblick av status över en stor mängd sensorenheter, och är gjord som ett verktyg för att diagnostisera och lokalisera eventuella läckor eller blockeringar.
Applikationen är gjord för att användas av kontorsarbetare, som är vana vid verktyg med många, många funktioner och har hög teknisk förmåga. Applikationen ska dock också fungera som ett verktyg för arbetstagare ute på fältet, som använder det på surfplattor eller möjligen mobiltelefoner.
Detta breda utbud av tekniska färdigheter och användarmiljöer lägger vikt vid användargränssnittet och att utforma verktyg som kan användas på olika nivåer.
Det färdiga verktyget levererar den kraft som behövs, men presenterar den kraften på ett använ- darvänligt sätt, upprätthållande av design loso n. Så levereras användbarhet och exibilitet, som utlovat.
Abstract
This thesis outlines and walks you through the process of designing and implementing an application for visualizing data related to water management systems. The data visualization in question is implemented on top of maps. The data is provided through Aquaductus sensors placed in water management systems, which relay data periodically. The application is able to both give a quick overview of the status of a large number of sensor-units, and is also made as a tool for diagnosing and locating possible leaks or blockages.
The application is made to be used by o ce workers, who are familiar with tools with many func- tions and have high technical prowess. The application though, should also work as a tool for workers out in the eld, who are using it on tablet devices or possibly smartphones. This wide range of technical skill and user environments puts a high priority on the user interface and de- signing tools that can be used at dierent levels of skill.
The tools designed gives the users the power needed but presented in a user friendly manner, upholding the design philosophy. Delivering the usability and exibility promised.
Contents
1 Introduction 1
2 Background 1
3 Research and Planning 2
3.1 Internal Planning . . . . 2
3.1.1 Map Markers . . . . 2
3.1.2 Map Utility . . . . 2
3.1.3 Further Utility . . . . 2
3.2 External Input . . . . 2
3.3 Marker Clarity . . . . 3
3.4 Tile layers, WMS, and WMTS . . . . 4
3.5 Map Projection . . . . 5
3.6 User Editing . . . . 5
3.6.1 Toolbar . . . . 6
3.6.2 Selection and Groups . . . . 6
3.7 Visual Modes . . . . 7
3.7.1 Line Modes . . . . 7
3.7.2 Node Modes . . . . 7
3.7.3 Group Mode . . . . 7
3.8 Interface . . . . 8
4 Implementation 10 4.1 Draft Version . . . . 10
4.1.1 Map and Layers . . . . 11
4.1.2 Units . . . . 11
4.1.3 User Added Data . . . . 12
4.1.4 Selection and Groups . . . . 13
4.1.5 Tools . . . . 13
4.1.6 Input . . . . 14
4.2 Release Version . . . . 14
4.2.1 Restructuring . . . . 14
4.2.2 Data . . . . 14
4.2.3 Improvements . . . . 15
5 Results 16
6 Social, Ethical and Environmental Considerations 16
7 Conclusion and Future Work 17
1 Introduction
Aquaductus[1] is a monitoring solution for water management system, used by cities in their systems for drinking water and sewers. The system is intended for detecting and locating leaks or blockage in pipes and wells easier, allowing for less frequent patrols and more accurate diagnosis.
The system is accessed by users through a web service, where sensor data can be reviewed. The service is intended both as diagnostics by o ce workers and as a tool by eld workers.
This work detailed in this thesis describes planning and implementation of data visualization while keeping ease of use as a priority .The focus is to improve the map view of the service.
2 Background
The Aquaductus system works by placing units, containing one or more sensors, somewhere in drinking water- or sewer- systems. The unit relays any collected data to a database, and from there is served to anyone authorized who logs on to the web service. The units are also capable of sending out text messages if the user-con gured alarm level is breached. The currently available sensors are:
• Water level
• Water pressure
• Water ow
The front-end contains a list of all units available to the user, graphs of the sensor-data and a map-view where the units can be located. The map-view is implemented using the Lea et[2] API for Javascript. In graph-mode, the user can con gure at which values the units should issue an alarm. Clicking the markers on the map also displays the latest data using gauges.
The forms displayed in the map-view and the list-view, including con gurations, are described in XML- les from the back-end. The system has been designed with modularity in mind, to easily allow adding new types of sensors to physical units.
3 Research and Planning
The research phase started with mapping out what the front-end map currently does and discussing what the goals are and how to reach them.
3.1 Internal Planning
3.1.1 Map Markers
Map markers on the live front-end show if one or more data-levels are above their warning level. In the current system it is not clear which sensor is issuing an alarm, nor does it convey any numeric data at rst glance. The goal here is to, at a glance, give more information, showing which sensor is sending an alarm and possibly display warnings based on historical data.
3.1.2 Map Utility
The map-view did not really contain any features except the markers. Users can click a marker to get the latest data, but other than that, it functions mostly as a navigational tool. The graph-view oers more data and becomes a more powerful tool. To this end, some functions should be added to exploit the potential of a map view. Allowing users to add nodes by themselves to complement the real units, to somewhat accurately match reality. Also, allowing users to connect these nodes visually, if reality is somewhat correctly matched, can be used to deduce where failures might have happened in reality.
3.1.3 Further Utility
The above items represent initially intended features, as determined through discussion between me and the project leader. On top of this, some more features were added on the todo-list for increased clarity and/or ease of use, namely:
• Selection: Allow users to select nodes.
• Groups: Allow users to make groups of selected nodes and select them easily.
• Colored lines: Give user some hint of where the warning on a node comes from.
• Visual modes: Show varying degrees of data on the map, hide sensors, hide colors and so on.
• Toolbars: Swapping between tools and options should be easy.
• Info nodes: Allow user to add notes and information to arbitrary locations on the map.
3.2 External Input
On top of internally planned features, two of the intended end users are pushing for more utility focused maps. They also provided some new ideas, and some of emphasized importance.
Figure 1: What a marker might look like with three sensors.
• Battery noti cation: On top of displaying sensor-values, also display battery status on the map.
• Line thickness: Allow a user to choose thickness of a drawn line.
• Valves: Allow a user to add vents to lines, extension to info nodes, speci c icons that can be picked by a user out in the eld to represent that, as an example, a valve has been closed, so alarms issued downstream are to be expected.
A very important part of this project was that this will be used by users of very dierent needs and technical prowess. You should be able to use whichever parts you need without being forced to learn all of the other parts.
3.3 Marker Clarity
To increase the overall clarity of the map the markers need to convey as much information as possible but not be hard to look at. Everything needs to be clean and have clear color coding. The markers will have any number of data attached, but currently, the assumed count is two, pressure and ow, three should de nitely be supported though since there are also water-level sensors. Just as the live version, alarms will be sent when data-values go above or below con gured levels, which issues a red icon. To complement this data, a historical comparison data-channel is introduced.
The user-admin will be able to con gure at what time the latest data should be compared to. The user-admin will also con gure percentages at which the map icon will be turned orange to warn that something might be o, but not enough to trigger a hard alarm.
Each marker shows the data attached with a circle, the sensor type is denoted with an icon, as shown in gure 1. Which order the sensors are presented are to be con gured by the user.
The user will be given a choice of displaying all of this data, or hide parts, or all of it, to get the desired visual representation for the individual. On top of this, information will be displayed by hovering the cursor on the markers. The end user has experience with maps containing a lot of text, and hovering seemed like the most e cient way to get the data into the map without too much cluttering.
The same gauges as currently available on the live front-end will still be available by clicking the unit markers.
Figure 2: Two properly projected maps, using dierent schemes and dierent source types. (Tile and WMTS)
3.4 Tile layers, WMS, and WMTS
Lea et is able to use some dierent standards of map-sources. The most common version used, openstreetmap[3] as an example, uses Tile layers[4]. In tile layers, the only thing needed for the API to do is calculate the projection and swap the x, y, and z in the URL and get the correct .png images. Other than this, lea et also has WMS[5] implemented, providing Lea et with the URL, API-key, and the layer-identi cation which can be found with the WMS-servers getCapabilities call. WMS is "Web Map Service", a protocol for serving map images over the internet. These two maps are good options for the application, openstreetmap is good enough, free and is the current live map. Lantmäteriet uses WMS for some older ornithological maps, which might be useful.
Finally, Lantmäteriet[8] supply a great and detailed map of Sweden in the WMTS[5] format, which, technically, is very similar to WMS. Where WMS builds the whole map image server side and then delivers it, WMTS delivers every tile used to build the map separately. Though not explicitly implemented, the WMS-implementation can be used with some tweaking.
3.5 Map Projection
All maps needs a projection-scheme[13]. The projection describes how the (mostly) spherical earth should be shown on a at surface. Depending on where you are, dierent kinds of projections give dierent results. Every map service assumes a projection, so the projection used by the map and the projection assumed by the service must be matched to each other.
Most maps used by map-services such as Lea et or Google Maps use a projection-scheme such as EPSG 3857[11] since it gives good accuracy all over the world. This is easy enough to use since it is fully implemented in Lea et. The WMTS map from Lantmäteriet uses EPSG 3006 (SWEREF99)[12], which is used in some Sweden-based maps. To be able to use this projection another plugin is used, proj4lea et[10], which allows any kind of projection based on its proj data-string.
"PROJ is a standard UNIX lter function which converts geographic longitude and latitude coor- dinates into Cartesian coordinates (and vice versa)." Retrieved from proj4.org.[9]
Making sure dierent projections will overlap properly when swapping between maps is one of the major challenges. Dierent maps might also have widely dierent zoom-levels, where a 3 on one map might be 12 on another. As long as the projection is done correctly though, coordinates should overlap. Examples of two dierently projected maps can be seen in gure 2, since the maps are properly projected the markers match the geography even though the maps are skewed from each other.
3.6 User Editing
To improve visibility and usability for the user we want to allow the placement of nodes which do not actually contain any real world data, and then connect any of these nodes and the units with real data freely. Doing this, a user may create a more complete image of the system than there are connected sensors. Thus relationships between values from sensors will make more visual sense, in relation to the real world. This data would be saved in the database to be displayed for the user-admin who drew it and any regular user. Alternatively, a map of the pipe-systems could be laid on top of the map, but this might bring some legal issues since it would need passing restricted documents from user to database and vice verse.
In a typical scenario, the user would edit the map by using tools from a toolbar inside the map.
This feature would only be allowed to a user-admin, as to not let any regular user mess around with carefully placed nodes and line-systems.
A feature requested by the end-user is to let the dummy nodes contain some user-edited data. A user might want to add a note to the system of lines you are drawing. Also requested was a feature to be able to add closed or opened valves to the lines, these features will be added together. In actuality this results in a feature were the user can add both information and a custom icon to the dummies based on what it is meant to represent in the real world. Another feature requested by the end-user is a tool to choose the thickness of the lines since this carries much information to the workers who will use the system.
Figure 3: Map with some real icons and some fake, connected to each other.
3.6.1 Toolbar
Anything that can be done to the map will be contained as tools on a toolbar. It was decided there would be a select tool, a node tool and a line tool. There is also be an option to undo the last action.
3.6.2 Selection and Groups
As an additional tool, we would allow users to select any number of nodes, in any combination, to let the user get some overview of only the desired nodes. And as an extension to this, groups of nodes could be created and given names. Thereby easily allowing the user to pick whichever group of nodes s/he wishes to study.
This feature could have any number of uses in the future, allowing for group-speci c analysis or updates to the units.
3.7 Visual Modes
Considering the Use only as much as you can and need mantra which we consider the backbone of the project, we want to allow the user to hide any information which s/he might not need, or want. A map with a view of both nodes and lines can be seen in gure 3.
3.7.1 Line Modes
The user may swap between modes: normal lines, advanced lines, or neither. In the normal mode, the lines are simply represented by colored lines and do not really carry any information. This might be useful if the user is only looking for an overview of the system. The advanced mode inherits and propagates the color-coding of the nodes to the lines to allow the user to instantly see where in the system of pipes that whatever blockage or leakage might have caused the alarm could be located. Alternatively, the user could turn o lines entirely if they are not needed at the moment.
3.7.2 Node Modes
Similarly to the line modes, there will be one simple mode, where any data is hidden and every node has the same icon, to give an overview without being bombarded with information. And then there is the advanced mode, which displays all the data as previously mentioned in the section describing nodes and its information. The nodes can be completely hidden if the user wishes to view only the lines.
3.7.3 Group Mode
There is one additional mode planned, a group mode. This mode will give an instant overview of all the groups created with the group tool. Each group will be given a unique color and mark any node contained in it with the color. Figure 4 shows how group mode displays data, the gure also shows the two advanced modes for lines and nodes.
Figure 4: Image showing how group mode displays an overview of all groups created.
3.8 Interface
When designing the user-interface for this project, keeping it simple and intuitive is important.
To help keeping everything in line, the design follows Nielsen's 10 Heuristics for User Interface Design[16].
Nielsen lists 10 "rules of thumb" for when designing user interface, and here any more or less appropriate rules will be applied:
• Visibility of system status:
The user should always be aware of the systems current status. Whenever you select a mode there will be a unique mouse cursor, the draw mode a pen, the node mode by a node-marker and so on. These cursors corresponds to the icon on the pressed button.
• Match between system and the real world:
More di cult to start of with, and will probably have to be adjust to t closer to what users are used to. The system will use the standardized symbols for valves, but pressure and ow are to be denoted by p and Q, this should possibly be something else, but there has not been enough time to adjust all of these things to the users. The front-end will be in Swedish, so that conforms to the users real life.
• User control and freedom:
The user will pretty much always have full control. There will only really be a single dialogue, the unit-settings, and that has a clearly visible close and save button. And if the user makes a mistake, there is an undo action.
• Error prevention:
Automation of any loading and saving of data solves most of any possible errors. Lea et is stable as it is and this will hopefully prevent most or all possible errors.
• Recognition rather than recall:
Any and all tools, options and information that you might need at any one moment is always visible. There should never be a situation were the user needs to remember some information, and can not get it.
• Flexibility and e ciency of use:
While there will not be many accelerators, ctrl-z for undo will probably be the only one, every system will be built as more or less standalone modules. You should be able to use any single part without needing to know what the others do, with limits of course. You could use this system and never select and group nodes, and that is ne, because the other functionality will work without it.
• Aesthetic and minimalist design:
This will be important, clutter will be minimized as far as possible. Nodes without informa- tion will be hidden, as an example.
• Help and documentation:
There will be a help section, which explains use of tools and what any symbols mean.
"Consistency and standards" and "Help users recognize, diagnose, and recover from errors" are excluded from this list. The rst since the system is so small, so anything that could fall into that category more or less is covered by "Match between system and the real world", though you could argue shortcuts like ctrl-z and shift clicks fall under this category. The second is hopefully not necessary, since any errors can hopefully simply be prevented.
Figure 5: What the layer-controller looks like.
4 Implementation
The implementation of the planned features described in the research part had to be rst done as a completely made up test version, with fake data and no real back-end. The live version is o
limits since it is in use, and the only test server is used for developing back-end features. Because of this completely disjointed implementation, it will be designed as a add-on to the current system and will have a simple API towards the current system instead of trying to implement it straight into the current front-end.
The implementation is split into two parts, the rst part was intended to test ideas and just make them work, this was done without much thought to how it would t to the live service. Part two is all about using the good parts and structuring them into an add-on for the live service.
4.1 Draft Version
To simulate a database behavior we run a local PHP[7] test-server with pretend-data, this allows for implementation of save and load functions that are not completely fake and actually loads and saves data from and to a server. We run some standalone PHP-scripts to talk to the database, the rest is done from a single HTML-document containing all HTML, CSS and Javascript.
4.1.1 Map and Layers
The map itself is easy to set up, as discussed in the research section, simply feed the map the map- service URLs and it will do any work needed. What needed to be done though was to support multiple types of map projections. Lea et supports a limited set of projection-schemes, so here the plugin proj4lea et[10] is used to add SWEREF99[12]. Lea et does not support swapping between projections in any kind though, so when you want to swap maps a callback is made which changes projection and refreshes the map.
In lea et everything but the map itself is represented as layers that you can add and remove. With the add-on "StyledLayerControl", extending lea ets control-class, any layers on the map can be added and removed whenever the user wishes, giving the freedom of choice concerning complexity that we want. This is how we represent the visual modes we discussed in the planning section.
There will be two layers for units and nodes, one containing the advanced nodes and one with simple nodes, and similarly for the advanced/standard lines. See gure 5 for controller.
4.1.2 Units
The units are stored as JSON-objects on the database according to:
{ {
" typ " : 1 ,
" coord " : {
" l a t " : 6 4 . 7 6 2 , " lng " : 2 0 . 9 4
" d i r " :1 45 ,} ,
" l e v e l " : 0 . 8 9 7 ,
" t o o l t i p " : " This i s some information . " ,
"sub " : {}
} ,. .. }
This le is loaded using PHP, parsed and then converted into nodes into the two node-layers. The simple node-layer places blue nodes at the given coordinates. The advanced nodes will display the data by looking at the "level" value and decide which color based on some prede ned percentages.
The "dir" is only relevant if "typ" is 1, this denotes the rotation of the arrow that represents water- ow. "typ" is which sensor this node represents, basically just deciding which icon to be used. "sub" is any of the smaller icons that will be shown if they issue a warning or alarm.
This data was assumed as a somewhat accurate approximation of the data that the map might get from the real database, this was all changed in the release version, to re ect how the actual data was formatted.
Figure 6: Editing a node.
positioning of the sub-nodes and rotation of the arrow must be remembered and reapplied whenever the layer is reloaded. This also applies to the HTML-span tag that works as an on-hover tooltip.
4.1.3 User Added Data
As planned, the user can add nodes onto the map, these contain some icon and may contain some text-info. The data for these are stored together with other user-added data on the database in the form of JSON.
{ "nod " : [ {
" pos ":[64.77230434986842 ,20.892245446877762] ,
" i n f o " : " Valve i s c l o s e d "
} , . . . ] ,
" i c o n s " : [ " c l o s e d " , . . . ] }
These icons are editable by right-clicking on them, bringing up a small menu to change the tooltip and change the icon, see gure 6. Thanks to lea ets built in callback-system this was very easy to implement. When the right-click, or context-menu, res on a node any data needed to change the icon or the tooltip can be gotten from this in the callback.
The lines are drawn in between nodes or units by clicking the map near or on one marker and then clicking on or near another one. The line then snaps to these two positions and remembers which unit-indices it belongs to. The user may choose the thickness of the line. When stored in the database these lines are stored as indices and a thickness. Since units and nodes might be connected by a line but they do not exist in the same array of objects any index of a real unit is its index in the list +1. Any node is 0 - (index + 1). Such that they can be properly parsed and loaded onto the map.
Figure 7: Toolbars.
4.1.4 Selection and Groups
The selection functionality is implemented by an array of references to any selected nodes. When clicking on a node in select-mode it gets selected, if the shift-key is pressed, formerly selected nodes stay selected. Otherwise, they are deselected, in line with anything users might be used to. When saving these selections as groups, the references are recalculated as indices to the units and nodes, these are always loaded in the same way, so it stays constant. They are saved using the same scheme as the lines.
4.1.5 Tools
The features explained above are used by the user through a toolbar which swaps between dierent modes, as shown in gure 6. These toolbars can be minimized if the user does not need them.
They can also be clicked and dragged, for a customizable feel.
The regular toolbar contains four tools:
• Draw: This tool will expand a small box where the user may select thickness of the lines.
They will be placed in draw-mode where they can use the draw tool as explained above.
• Node: This will expand some options where the user may select an icon and write some text for the node. After this clicking the map will place a node, see gure 8.
• Move: Standard click and drag to move around the map.
• Select: Click on nodes to select them, click and drag to multi-select, shift to keep selected selected.
• Undo: Undo last placed node or drawn line.
Figure 8: Node tool picked and options for that expanded.
4.1.6 Input
Lea et has built-in support for any callbacks using a mouse, so mousedown, mouseup and mouse- move worked great, leading us to design the draw and select tools as click->drag->release functions.
The need for cross-device usage meant that touch-devices needs to be looked at, and at rst glance, this should work just as well. Lea et does not support any touch callbacks other than tap, but this could be easily extended to work with regular HTML DOM(Document Object Model)-touch events[14].
Even though all of this worked great, there appears to be a known glitch that has yet to be patched that randomly res the touchup event during touchmove events on chrome on android[15]. There is no known x to this except downgrading lea et, which was not an option. Due to this the draw and select tool had to be remade to work by clicking point A and the clicking point B.
4.2 Release Version
All of the functionality from the draft version is used here, but structured so to be usable, readable and editable by anyone.
4.2.1 Restructuring
The restructuring was the most time-consuming part of this version of the project. All the code and features that were made with little thought to modularity and readability had to be extracted and structured. The code was structured into several dierent modules: Map and layers, callbacks, save and load, utility, toolbars, and data.
4.2.2 Data
By this time the actual data-structure that would be passed to the map had been locked down and the nodes had to be built based on this data instead. This then also made it clear what data was needed to be saved concerning the units together with nodes and lines. As seen in table 1 below.
This introduces the need to be able to con gure some data in the units. This is done through a drop-down module, as seen in gure 9. This data is then saved and loaded to the same JSON- le
Table 1: Data
Data from system New Map-data Unit Position Node data Sensor Values Line data Historical Di Groups
Alarm Levels Warning Levels Unit Type Unit Con guration Unit ID
Figure 9: Con gure how the node will act.
in the database as the nodes and lines.
Data is saved whenever any save-button is pressed, either on the temporary toolbar save button or using the button in the unit con guration module.
4.2.3 Improvements
To make the environment more user-friendly the location of the screen and zoom-level is saved when refreshing the page, and then reloaded into Lea et. The sub-icons now only show themselves if there is anything to inform the user about.
Nodes without information become invisible as to not clutter the screen, they can still be clicked, and if any information is added, they will turn visible.
This second version is the base for the nal product, which is not a part of this report.
Figure 10
5 Results
The resulting product was quite close to the plan, the necessary back-end components were sadly not nished in time for the map to be applied on the real data. Regardless, the result is a map where the user may gain an easy overview and edit the map themselves. They may group nodes and swap between dierent viewing modes. Furthermore, they can edit data in the units and they can edit data in nodes. Also, they can swap between several dierent maps. The nished map layout is shown in gure 10.
6 Social, Ethical and Environmental Considerations
The application, as it is implemented in this project, does handle some information that could be considered sensitive. Depending on how detailed the user-added data is, it could be used to sabotage the drinking water of the town or city in question. This will probably only be rough estimations of water management systems, and this is also why overlays of real pipe-maps are not planned. Very detailed maps could be disastrous in the wrong hands.
As for the environmental part, this application will, as discussed, lessen the need for patrolling.
Greater than that, it will allow users to locate leaks before a lot of water is lost. Every minute a leak goes undiscovered money, that could go to improving the city or town, is literally pouring out into nothing.
7 Conclusion and Future Work
Now, the question is: Is this new front-end more useful than the old? Or rather, will these new features add anything useful to the user experience?
And the answer is quite multifaceted. Currently, the Aquaductus front-end is almost exclusively used for its list and graph modes, and, if we have understood everything correctly, what users most often do is simply receive the text-message when a unit sends an alarm, then maybe check the location in the map-view. A user-admin might con gure some alarm-levels, add or remove some phone numbers, but the system is used purely reactionary.
There are however some users that use the data from the graphs and plot them on maps by hand to get some overview and work out where leaks might be or where something might be o. This is what the new map-view is supposed to streamline and make accessible to any user that feels like it would help, while of course leaving the option open to simply continue using the system as before.
For these users that want to use the data in this way, the new tools provide for some kind of base need. The end-users did request a far more complex color-coding scheme, to begin with, and more levels of warnings based on historical data. But since the goal was to not add too much complexity, we decided that simply having a warning at a single user-con gured level for the historical data would have to do. I started out assuming green->yellow->orange->red were the warning levels, where green was nothing wrong, yellow was a minor change, orange was a bigger change and red was a very large change. But red already represents an alarm on the regular data-channel, and then a user might also want to be able to set warnings to the regular data-channel. This quickly became confusing, and when I discussed this with my supervisor and tried to gure out how we wanted the user to set all these levels, remember that this would have to be done for every sensor on every unit, the idea was mostly scrapped and simply green->orange->red was decide upon.
Green is everything is alright, orange is a warning where the historical data is o by more than the user allows, and red is as before the hard alarm-level con gured and set into the device.
So, hopefully the new icons allow for some easier decision making, but let us not forget about the user-added content. When extracting the data, the users drew it out on maps of the pipe systems, wanting to replicate this we added this feature. This is a feature that I can guess might be useful, but only time will tell if it actually works out. It all depends on how much time someone spends drawing an accurate picture of the pipes. Absolutely useful though will the feature where you can add data to a dummy node and everyone can see it be.
At this time the least useful feature is probably the grouping. It might be useful to select every unit and node in a district to let any worker out in the eld concentrate only on what matters to their work. But even this seems like a slim use. But this feature does have a lot of potential use in the future. Creating groups is easy when in a visual map, and not so easy in a list-view. And you might imagine that you would like to see a list of only the units in a certain group. You could also want to add all units in a group to a user so that they would receive texts from alarms. And
nally, you might want to do some kind of update or something on any units contained in a group.
As for discussing the interface design philosophy, everything lined out in the research part about [16] is followed in the nished product. The one thing was that any decent help section was never completed, it was simply the lowest priority and there was not enough time.
References
[1] Aquaductus AB (2013) AquaDuctus. http://aquaductus.se// [2018-05-15]
[2] Vladimir Agafonkin (2017) Lea et - a Javascript library for interactive maps.
http://lea etjs.com/ [2018-03-19]
[3] OpenStreetMap Foundation (2012) OpenStreetMap. https://www.openstreetmap.org/ [2018- 03-20]
[4] Per Liedman (2014) The Hitchhacker's Guide To Tiled Maps. http://www.liedman.net/tiled- maps/ [2018-03-27]
[5] Vladimir Agafonkin (2017) Using WMS and TMS service - Lea et.
https://lea etjs.com/examples/wms/wms.html [2018-03-23]
[6] Mylen (2017) Add WMTS layering for lea et. https://github.com/mylen/lea et.TileLayer.WMTS [2018-03-23]
[7] Mehdi Achour, Friedhelm Betz, Antony Dovgal, Nuno Lopes, Hannes Magnusson, Georg Richter, Damien Seguy, Jakub Vrana, And several others (2018) PHP Manual.
http://php.net/manual [2018-03-22]
[8] Lantmäteriet (2018) Oppna geodata - Lantmateriet. https://www.lantmateriet.se/sv/Kartor- och-geogra sk-information/Kartor/oppna-data/ [2018-03-22]
[9] URBANEK, S. proj4: A Simple Interface to the PROJ. 4 Cartographic Projections Library (R package version 1.0-4). 2008.
[10] Proj4Lea et Contributors (2017) Proj4Lea et - Support all projections and CRS in Lea et.
http://kartena.github.io/Proj4Lea et/ [2018-03-26]
[11] Howard Butler, Christopher Schmidt, Dane Springmeyer, and Josh Livni (2005) EPSG 3857 TM: EPSG Projection - Spatial Reference. http://spatialreference.org/ref/sr-org/epsg3857- wgs84-web-mercator-auxiliary-sphere/ [2018-03-26]
[12] Howard Butler, Christopher Schmidt, Dane Springmeyer, and Josh Livni (2005) SWEREF99 TM: EPSG Projection - Spatial Reference. http://spatialreference.org/ref/epsg/sweref99-tm/
[2018-03-26]
[13] Melanie Frazier (2013) Overview of Coordinate Reference Systems (CRS) in R.
https://www.nceas.ucsb.edu/ frazier/RSpatialGuides/ [2018-03-27]
[14] PIXLEY, Tom, et al. Document object model (DOM) level 2 events speci cation. W3C rec- ommendation, November, 2000.
[15] zorji (2017) TouchEnd event is red before nger leaves the screen when dragging is disabled https://github.com/Lea et/Lea et/issues/5745 [2018-04-26]
[16] NIELSEN, Jakob; MOLICH, Rolf. Heuristic evaluation of user interfaces. In: Proceedings of the SIGCHI conference on Human factors in computing systems. ACM, 1990. p. 249-256.
