2. LESSONS LEARNED
Interoperability is a key
point
Capturing information
from the crowd is a
new powerful method
to complement
forecasting and alerting
Provocation:
“Perhaps were they at
avalanche risk?”
3. What is GeoAvalanche?
A double face project for improving snow
avalanche information
A crowdsourcing system to collect localized
snow avalanche information from the crowd in a
map through a secure approval workflow
A geospatial avalanche data fusion server
for supporting information in compliance with
standards towards a spatial data infrastructure
27 giugno 2021
Autore: Francesco Bartoli
3
4. Crowd Mapping
27 giugno 2021
Autore: Francesco Bartoli
4
Background concepts behind the
system:
Mountaineers are the first
responders on the ground
Professionals are always on the
snow visiting mostly inaccessible
places ready for a coordinated
meaningful response
Report critical snow conditions
from the wilderness may affect the
avalanche danger locally
Get near real-time alerts for a
specific zone could save lives
Open Data is the recipe for
sharing knowledge
6. Reports structure
Primarily categories with sometimes
subcategories:
Avalanche Incidents divided into 5 classes
related to danger levels:
Danger very-high
Danger high
Danger considerable
Danger moderate
Danger low
Snow Conditions
Snow Depth
Spontaneous Avalanche
27 giugno 2021
Autore: Francesco Bartoli
6
7. How to report
27 giugno 2021
Autore: Francesco Bartoli
7
By native Apps
By sending an Open geoSMS to a SMS
gateway
By sending an email to a specific address
By tweeting a geotagged post with particular
hashtag (#geoavalanche, #avalreport,
#avalevent)
incident.geoavalanche.org
8. Avalanche data fusion server
GeoAvalanche server is a geospatial engine able to
support your snow avalanche information and
overcome your current GIS facilities to meet the Web in
a fashionable way
It can out-of-the-box manage with a variety of raster
and vector data formats and ready CAAML-enabled
It’s entirely based on a Service Oriented Architecture
ready to publish maps, data, observations and
processes over the Internet simply invoking web
services
Such web services are consumable in a well
established way because of their compliance with OGC
standards (WMS, WFS, WCS, WPS, etc)
It can be easily pluggable into existing solution given its
open architecture and has the ability to connect with
the most of spatial databases (PostGIS, Oracle Spatial,
MySQL Spatial, Spatial SQL Server)
27 giugno 2021
Autore: Francesco Bartoli
8
9. Software development
GeoAvalanche is open source, GNU GPL v3 licenced,
built on top of GeoServer a powerful GIS server
suitable for the GeoWeb
GeoServer has been extended with its GML app-
schema plugin and further develop to support CAAML
application schemas
A first working prototype has been built up to
accommodate the EAWS bulletin profile and each
CAAML feature can be retrieved from a spatial
database PostGIS and then pushed through a WFS
service over the Web
A basic request
http://localhost:8080/geoavalanche/avy/ows?service=WFS&version=
2.0.0&request=GetFeature&typeName=avy:bulletins&outputFormat=
gml32 returns a bunch of bulletin feature type
Optionally using the outputFormat=json you can return
the same as JSON stream. Pretty useful for
smartphone
27 giugno 2021
Autore: Francesco Bartoli
9
14. Conclusions
GeoAvalanche brings a lots of benefits to the
build of a modern avalanche data
infrastructure:
The use of geospatial standards as key element
to achieve interoperability
The use of a mature product which was made
ready to support the snow avalanche semantic
behind CAAML
The ease of adaptation to the different models
The combination of Open Source software with
Open Data that leads to a powerful open
architecture more sustainable for each
avalanche center
27 giugno 2021
Autore: Francesco Bartoli
14
15. Thank you
Contacts
Francesco Bartoli – Geobeyond Srl
francesco.bartoli@geobeyond.it
follow @geoavalanche/@geobeyond
27 giugno 2021
Autore: Francesco Bartoli
15
Editor's Notes
Let me start with a snow story occurred in Rome this winter before talk about what is geoavalanche.
40 centimeters of snow fully blocked the city. Roads, transportation, goods delivery, everything down. Snow chains at prices 10 times higher. Just 40 sirs. I know this seems to be unbelievable at your eyes but it’s the reality. And also there was a dispute between the major and the national civil protection department about responsibility and bad communications on snow height forecast. And even more about the real height. Crazy.
So…does the provocation seem to be a bit off?
Well actually a question that makes more sense to me is “How come they weren’t at work?”
But we learned some lessons:
1. Interoperability between information systems is a key element for exchanging data
2. Crowdsourcing is a manner at affordable cost to acquire more knowledge on geographical phenomena
Let’s image for a while how useful could be to collect snow height measurements in real time from the citizens and how this could avoid being misled
GeoAvalanche has been thought to work for the benefit of the avalanche community but primarily it is intended as a decision-support tool for avalanche centers which have the authority to trust the information. We have identified them as country validation and analysis staff.
So each country should have its first-response teams who are basically professional groups which can provide the first level quality control. But they can also be used as third level normally being engaged by the validation team to ask for verification of recreational sources.
The second level of quality control come from the same national avalanche center that makes a first evaluation of the credibility and maybe also some changes to the report before going to finally publish it in the map.
Given that from a technical perspective the whole amount of the data is pretty easily accessible from a JSON interface then we can imagine the wide capabilities to retrieve historical and statistic incidents information by IKAR
Each category has a color that can be defined in the platform or it can be identified by a custom icon. For example we have been setting each danger level with the corresponding icon
Reports of the same category can be clustered in the map on the basis of neighborhood concept but also filtered out by simply clicking on that specific category/subcategory
Each category can have its specific form to submit information even though subcategories like danger levels share the same form
At the moment we support iOS and Android apps that can be downloaded for free following the link on the widget at the right side in the map but an upcoming release of a branded version for iOS is expected before the beginning of the next season.
Open GeoSMS is a standard protocol under the umbrella of OGC that permits to embed a geographical position into a standard SMS. It is particularly of interest because it allows communication even though you are off the internet connection. Well even more if the whole network is down you can store the message with the GPS position and then broadcast it at earliest opportunity. So pretty cool.
Using twitter is another option. It is a straightforward way to send quickly new updates but requires the internet connection as well as the apps
Finally we have the website that can be used to report when people are back to home from the backcountry. So let’s have a look. The main page display the map with clustered dots based on the filter category which has been selected in the left widget. The cluster expresses a certain number of dots which belong to the same category under a neighborhood area. It is also possible to search reports by a free text query or also comes up the clustering by zoom in/zoom out. Each dot displays the number of the underlying reports which can be further browsed by clicking on that. Yesterday I’ve set Alaska area as the base location on the map and going here we find two incidents since the October 2011. Following the button “submit a report” you have the opportunity to share a new kind of information. From the submitting page you have firstly to choice the appropriate form from the combo box related to the type of report we have mentioned in the slide before. The basic information that each report shares are location, timestamp and description but our platform has been customized to accommodate the need of avalanche data. So for example an incident provides basically some useful fields such as kind of activity, aspect, safety gear, number of buried, injured, fatalities, kind of trigger and so on. You can also refine the location with a more detailed textual name. so pretty easy. Well the whole system can be used for free and also all the data collected can be easily fetched through a JSON interface and reused by third application at no cost for non commercial scopes. Everyone has also the ability to submit information anonymously that is pretty much of interest over those countries like Italy where a legal framework affects anyone who unfortunately triggers an avalanche. There are also functionalities under login which allows to express for example the rank of credibility for each given report.
This interaction is based on the SOAP paradigm: you ask the server for its capabilities. That returns a well-formed list on the base of which you can ask for specific geographical features: it means for example give me the bulletin for a specific location (an example can be a mountain region). This request is initially resolved with a BoundingBox by searching among the locations actually stored and then passed as parameter to the above request that returns the more specific bulletin.
GeoAvalanche is fully based on the concept of open architecture. This picture figures out how a basic configuration between local and remote information systems can permit to exchange data over the Web as long as they are compliant to most of the OGC standards.
In fact, once that you do make sure to having a product satisfying the requirements of compliance with this set of OGC web service then you are ready to go.
You can publish maps with the web map service
You can stream data with the web feature service and even more caaml datasets
You can publish coverage with the web coverage service
You can acquire observations in a data collector with the sensor observation service
And also you could publish a process on the web that performs some kind of
Everything is web based and therefore oriented to the GeoWeb with a lot of capabilities for data-driven services. In addition those services can be consumed both over an intranet for back-office operations like data analysis or forecasting elaboration and over the internet for the public alert or for transferring information to the downstream systems like municipalities, road and railways authorities, etc.
So at the end of the day we have several possibilities from a data input perspective: local vector and raster data (among them caaml databases), other local spatial database, and remote services which enable a datastore framework. Their combination results in a series of web services that can be consumed to publish maps, exchange data or combine them into a process.
This open architecture is the key element to achieve cooperation at all level and is the base methodology towards a spatial data infrastructure where avalanche centers can collaborate each others without any kind of misleading.
The open approach based on standards like WPS guarantees to be model-independent and therefore leads to a strong flexibility able to accommodate almost all use cases from the avalanche centers perspective.
Each center can implement its own web processing server simply defining for each use case the algorithm to be used and which input data have to be ingested or assimilated. The result will be a new geographical layer ready to be published in a map or streamed to the Web. This model is also valid in a cascade workflow since the nature of services.
Feature collection means for example spatial data like slope zones from DEM, frequent avalanche zones,
Grid collection means variability of measurements from raster image analysis like Snow Surface Te