Saving geoJSON: Specify and remember ID field

[arcataroger]

Feature description

When saving geoJSON, can we allow the user to select a specific field to use as the geoJSON feature ID member?

Having geoJSON features saved with proper IDs would allow other software, like OpenLayers, to use them properly.

Currently, when a geoJSON layer is edited and saved, all its fields gets saved into the properties member of the feature, like so:

    {
      "type": "Feature",
      "properties": {
        "id": "my_id",
        "prop2": "prop2",
        "prop3": "prop3",
      },
      "geometry": {
        "type": "Point",
        "coordinates": [
          -9753562.172631999477744,
          5141014.504863454028964
        ]
      }
    },

However, per the geoJSON spec (RFC 7946 sec 3.2, last bullet point), geoJSON features with IDs should have that ID as a top-level member of the parent feature object, rather than as a part of the properties child. In other words, geoJSON prefers this ID format:

    {
      "type": "Feature",
      "id": "my_id",
      "properties": {
        "prop2": "prop2",
        "prop3": "prop3",
      },
      "geometry": {
        "type": "Point",
        "coordinates": [
          -9753562.172631999477744,
          5141014.504863454028964
        ]
      }
    },

To make this work properly, there are at least two similar workflows to consider:

1. When a vector layer is first converted to geoJSON, the user needs to choose a field to save as the geoJSON ID. Perhaps this could be an additional option (drop-down menu?) alongside the other current geoJSON-specific parameters.. Current workarounds for this exist, such as using ogr2ogr -lco id_field=id (or manually specifying the same as a Custom Option in the export dialog). More discussions and workarounds are in geoJSON feature IDs: Saved as a property instead of ID #40805.
2. QGIS can also open geoJSONs as vector layers, edit, and save them in place. In this case, it should read/save IDs in the proper place (as a top-level member of the feature instead of moving them to properties). Since there should only be one id member per geoJSON feature, this does not have the same problem with ambiguity as the conversion workflow above. However it's possible that the attribute table/feature identifier would need to accomodate a special ID field as something distinct from the other properties.

Additional context

See also:

• geoJSON feature IDs: Saved as a property instead of ID #40805
• https://gis.stackexchange.com/questions/212014/qgis-removes-id-field-when-saving-as-geojson
• https://stackoverflow.com/questions/34314066/adding-a-unique-feature-id-to-geojson-in-qgis-or-python
• https://gis.stackexchange.com/questions/286843/ogr2ogr-expose-osm-id-in-geojson/286852#286852