Project: GeoSAFE
Changelog for version: 2.0
This release sees a major upgrade to GeoNode 2.8 and InaSAFE 4.4.
It includes varous feature and performance enhancements and bug fixes.
Back end
The new InaSAFE 4 reports are generated once the analysis is finished. The reports then loaded as GeoNode documents are linked to the impact layer in GeoNode
https://github.com/kartoza/geosafe/issues/335
InaSAFE 3.5 had been deprecated since early 2017 so it was important to upgrade it in GeoSAFE to stay in line with InaSAFE desktop. This was a major upgrade that involved back and front-end refactoring to accommodate and take advantage of the major changes from 3.5 to 4.4.
One of the many advantages is that you no longer need to export v4 keywords to 3.5 but can create them in desktop InaSAFE and upload them to GeoSAFE as is.
You can now easily deploy GeoSAFE via Rancher using this configuration: https://github.com/kartoza/kartoza-rancher-catalogue/tree/master/templates/geosafe.
If you want to set up a development environment using Docker, Ansible and remote debugging from PyCharm, the intructions are at https://github.com/kartoza/docker-geosafe
This release of GeoSAFE runs on the stable 2.8 release of GeoNode. We did however have to make some fixes to GeoNode (that might make it into the 2.8.1 bugfix release) so we use our kartoza/GeoNode fork.
Further GeoSAFE development occurs on GeoNode and the next release will likely be on GeoNode 2.10.
https://github.com/kartoza/geosafe/issues/303
With Kartoza's docker-osm project integrated with GeoNode-QGIS_server, you can now configure any OSM extract you like as a QGIS layer published in GeoNode. If you give that layer valid InaSAFE keywords, it becomes a valid GeoSAFE layer.
The exposure data you define from OSM is updated regularly.
https://github.com/kartoza/geonode/issues/422
Front end
GeoSAFE now has this tagline:
Realistic Natural Hazard Impact Analysis -- InaSAFE made easy
https://github.com/kartoza/geosafe/issues/198
If there are valid InaSAFE aggregation layers available in GeoNode, they will be listed in the Aggregation tool. Choose an aggregation layer that covers your analysis area. Then the analysis will be run on each polygon in the aggregation layer that falls within the view extent, in the same way as on InaSAFE Desktop. The report will show the results per aggregation polygon, aggregated.
To further limit the analysis extent, click on aggregation polygons to add or remove them from a selection. then the analysis will run only on the selected polygons.
Using an aggregation layer is optional. If you don't choose one, analysis will run on the intersection of the view, the hazard layer and the exposure layer.
If you do choose one but don't choose any polygons, the analysis area will be constrained to the intersection of the whole aggregation layer with the above.
Updated tooltips guide the user through choosing layers and setting up an analysis.
https://github.com/kartoza/geosafe/issues/51 https://github.com/kartoza/geosafe/issues/364
With the upgrade to InaSAFE 4, there is no need to select an impact function since InaSAFE chooses the correct function automatically based on the hazard and exposure keywords. Therefore, the button no longer appears in GeoSAFE
You can now design your own custom report template in InaSAFE desktop and then add it to your local theme repository so it overrides the default template. The INGC custom template is added through https://github.com/kartoza/ingc_geonode_theme.
Multiple languages can also be managed this way.
In the previous version with InaSAFE 3.5 the analysis extent defaulted to the intersection of hazard and exposure layers. If this was a large area it could take an excessively long time to process. To obviate long waits we added the constraint of the view extent so you could zoom in to limit the analysis area. We also implemented a fairly arbitrary size limit above which you would be warned that the analysis area was too big.
With this upgrade we have removed the size limit. The other analysis area constraints still apply, along with the new features of aggregation layers and improved communication with the user about progress.
Internationalisation has been enabled in GeoSAFE. Most of the experience should be available in English or Portuguese now, with some translation still underway at the time of writing.
These different components needed translation via different platforms:
- GeoNode: The Transifex GeoNode project https://www.transifex.com/geonode/geonode/
- GeoSAFE: The Transifex GeoSAFE project https://www.transifex.com/inasafe/geosafe ('django' resource)
- The INGC theme: The Transifex GeoSAFE project https://www.transifex.com/inasafe/geosafe ('ingc' resource)
- InaSAFE reports: The Transifex InaSAFE project https://www.transifex.com/inasafe/inasafe-code ('SAFE' resource)
- InaSAFE map reports: QGIS templates
https://github.com/kartoza/geosafe/issues/178 https://github.com/kartoza/geosafe/issues/327 https://github.com/kartoza/geosafe/issues/242 and related issues
https://github.com/kartoza/geosafe/issues/223
The interaction of the view extent and the extents of available layers, together with layers already selected, has been improved, resulting in more reliable and predictable analysis configuration.
https://github.com/kartoza/geosafe/issues/217
The analysis page used to default to the extent of the world. Default behaviour is now to zoom to the extent of available GeoSAFE layers.
https://github.com/kartoza/geosafe/pull/392
While the default extent in GeoSAFE is now the extent of all valid layers, this can be overridden as part of a custom theme.
At the INGC in Mozambique, all local theme elements are defined in http://github.com/kartoza/ingc_geonode_theme. Among other settings there is a custom default extent, which for the INGC is the extent of the country of Mozambique, no matter what layers are available.
https://github.com/kartoza/geosafe/issues/394
GeoSAFE is supposed to be independent of the skin being used because some people may want to put different skins. Thus the skin is on separate repo.
The benefit:
-
When GeoSAFE is stable, you just need to perform changes in INGC theme repo if you want to apply skin changes (logo, text, etc). You don't need to change main GeoSAFE base.
-
If two instance of GeoSAFE use two instance of skins, they can just apply the changes for their respective skins repo. It will not affect the other (which probably belong to different organizations or divisions)
-
Localizations and Organizations specific settings can be put on the skin repo. That organizations only needs to translate language specific for their needs. It will not clash with other org
-
Theme app are made as a django app. Technically speaking, in the orchestration it is installed as python package using pip with desired package URL. You can change the skin easily by changing the url of the theme you want to install. The URL will be asked as a Rancher question, when you do update or deployment. Attached below the screenshot of said question:
- As a side note, because it is just a theme app. I recommended to use just the repo URL to install the app, instead of deploying the package as actual python app on python package repository like Pypy. This is in the sense that no other people will use the theme app besides that organization. It is also easier to maintain the release using just a git tag, instead of deploying it as python app distributions.
The theme repository for INGC in Mozambique is at http://github.com/kartoza/ingc_geonode_theme
https://github.com/kartoza/geosafe/issues/381
Issues resolved
https://github.com/kartoza/geosafe/issues/282
https://github.com/kartoza/geosafe/issues/281
https://github.com/kartoza/geosafe/issues/15
