qgis / QGIS-Enhancement-Proposals

QEP's (QGIS Enhancement Proposals) are used in the process of creating and discussing new enhancements for QGIS
117 stars 37 forks source link

Graph oriented GeoJSON editing and visual mapping for nested data structures #233

Open aourednik opened 2 years ago

aourednik commented 2 years ago

QGIS Enhancement: Graph oriented GeoJSON editing and visual mapping for nested data structures

Date 2021/09/29

Author Ourednik André (@aourednik)

Version QGIS 3.28

Summary

A fully functional nested data editor should be added to QGIS to unfold the full potential of GeoJSON. One should also be able to map visuals to nested GeoJSON "property" objects. Example: the label editor in layer properties should be able to use an expression like concat("name.en",' (',"name.local",')') to construct labels. The same should be possible in the field calculator.

Rationale

Graph databases exist since 2000 but we are still using flat table models to store and edit geodata in GIS solutions. Even Geopackage uses flat sqlite tables with a WKT column. We should move on and stop wandering in NULL fields.

Wouldn't GeoJSON be an excellent format for storing and editing nested data?

Its support in QGIS is slow and buggy for now but it has more potential than a flat tables set. To use the full potential of the GeoJSON object-oriented format, an appropriate editor should be added to QGIS. Here an example of such an editor by @josdejong

JSON in GeoPackage

It is possible to add a JSON field to a Geopackage layer and to switch to a tree view in the attribute editor (Layer Properties > Custom forms > Widget type > JSON view > tree) but the tree is not editable in the attribute table. The only current solution is to choose Widget type > Text edit and to write JSON manually. Moreover, it is unclear how to access a nested property in field calculator or Label and symbology visual mapping.

Proposed Solution

Data editor

  1. It is possible to add a JSON field to a GeoJSON layer (currently only supported for GeoPackage)
  2. Widget type > JSON view > tree is set by default when editing a JSON field, regardless whteher this is in GeoJSON or Geopackage
  3. The JSON tree view allows editing arbitrarily nested objects.

In the field calculator and in visual mapping

One can use JSON adresses like "myfield.mysubfield[i].mysubsubfield" in the field calculator and in Layer properties visual mappings.

Example(s)

The label editor in layer properties is able to interpret an expression like concat("name.y1491.en",' (',"name.y1491.local",')') to obtain a Constantinople (Κωνσταντινούπολις) label from this GeoJSON layer:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {
        "name":{
          "current":{
            "local":"İstanbul",
            "en":"Istabul"
          },
          "y1491":{
            "local":"Κωνσταντινούπολις",
            "en":"Constantinople"
          }
        }
      },
      "geometry": {
        "type": "Point",
        "coordinates": [
          29.179687499999996,
          40.91351257612758
        ]
      }
    }
  ]
}

Affected Files

(required if applicable)

Performance Implications

Setting myvar.myfiled.mysubfield = val is very fast in JavaScript, so this should be no issue in QGIS python. Geometry editing of GeoJSON seems more problematic, but why not make it faster by creating an optimezed temporary file when editing is active. Geopackage, too, uses such files (write ahead logging and shared memory).

Further Considerations/Improvements

I have no ressources or comptence now to work on this, I never developped even a package and I wouldn't know which files in the QGIS source to look at. If someone points me to them I could hae a look. In all cases, I could test and discuss implementation solutions.

Backwards Compatibility

This feature would create GeoJSON files potentially non-readable in earlier version of QGIS

Votes

(required)

zoidable commented 1 year ago

This would be kind of a game changer imho. Could anyone provide an estimate of the feasibility? I guess JSON schema would have to be integrated somehow to produce useful data...?