Geonode 2.8 was released 3th April 2018. Kartoza has made several bug fixes and enhancements in the kartoza/geonode fork, some of which might make it upstream into 2.8.1 bugfix release, else they will be in 2.9 waiting to push upstream for the next official release
GeoJSON layers can now be uploaded to GeoNode.
This is a convenient new feature for GeoNode users even though it was prompted by InaSAFE 4 requiring and producing GeoJSON, for the upgrade of GeoSAFE to use InaSAFE 4.
see https://github.com/kartoza/geonode/issues/405
We wanted QGIS server backend and GeoSAFE to run on a stable version of GeoNode. At the time of starting this project phase, GeoNode 2.8 had just been released.
In the previous phase of this World Bank project, we had pushed all our QGIS-server backend contributions upstream to 2.6 / 2.7.
However, we could not get everything to work on GeoNode 2.8 and no bug-fix releases were planned, so we made improvements to our own fork, which we hope to push upstream to get into a subsequently-planned 2.8 bugfix release and also into 2.9 / 2.10.
To compare our fork to upstream see https://github.com/GeoNode/geonode/compare/master...kartoza:2.8.x-qgis_server
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.
The layer you define from OSM is updated regularly.
https://github.com/kartoza/geonode/issues/422
You can embed an interactive map from GeoNode into another website with 'Embed widget link' or as an iframe with 'Embed iframe link'. You can also download your own standalone full-page Leaflet web page of your map with 'Download Leaflet page'
https://github.com/kartoza/geonode/issues/86 https://github.com/kartoza/geonode/issues/152 https://github.com/kartoza/geonode/issues/153
GeoNode has some quirks when it comes to handling metadata. It stores some fields in its backend database and it stores a full XML metadata document in the database if you specify that you don't want to be able to edit the metadata after upload. While the metadata supports some GeoNode content it also has to be available for search and query via the CSW endpoint provided by the pyCSW service that comes with GeoNode.
GeoSAFE added further complications: Firstly that metadata had to store InaSAFE keywords in a non-standard 'nested' XML document within the main metadata Supplemental Information element; secondly, that the metadata document has to sit with the exposure or hazard data file (typically shapefile or GeoTIFF) on disk, i.e. outside the database.
If you edit the metadata it has to be maintained in at least two places, not lose any content and not break anything.
We've made various fixes that make metadata upload, replacement and editing more reliable and predictable.
https://github.com/kartoza/geonode/issues/396 https://github.com/kartoza/geonode/pull/500 https://github.com/kartoza/geosafe/pull/378
https://github.com/kartoza/geonode/issues/370
https://github.com/kartoza/geonode/issues/303
Saved maps used to get the world extent or the extent of the last added layer. Now they get the extent of all participating layers.
Incorrect bounding boxes were used (i.e. in the wrong CRS) resulting in layers not drawing and thumbnails not being generated
Some artefacts (like QGIS projects) got left behind when deleting a layer, which prevented a layer with the same name from being uploaded again. Now all objects associated with a layer are deleted in the backend when a layer is deleted
Several cases where thumbails were supposed to be generated were quite buggy, mainly because of CRS and request bounding box issues. - when a new layer is uploaded - when a new map is created - when a layer of map thumbnail is reset - when a map is edited - when a layer's default style is updated
Various controls and links were inactive or buggy, now everything should work as expected when interacting with a map
When an impact layer was generated in GeoSAFE (after the upgrade to InaSAFE 4) and published back to GeoNode, it caused the server to crash (https://github.com/kartoza/geosafe/issues/345)
This was fixed with https://github.com/kartoza/otf-project/pull/13.
When a new layer is published in GeoNode with QGIS server backend, a new QGIS project is created on the fly to house that layer. This fix ensured that process configured the QGIS project correctly.
If layers did not have an explicit EPSG code in their projection definition, their CRS would get registered incorrectly, resulting in problems with thumbnails, layer rendering in the GeoNode layer and map clients and analysis in GeoSAFE.
This was fixed by improving CRS detection on layer upload and improving error feedback to the user. Now layers with a much wider range of CRS can reliably be published in GeoNode with QGIS server.
See https://github.com/kartoza/geonode/issues/435