geoJSON feature IDs: Saved as a property instead of ID

[arcataroger]

Describe the bug
When exporting vector layers to geoJSON, feature IDs get saved in the properties of the feature instead of a top-level id, as described in the geoJSON spec.

Expected output:

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

Actual output:

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

How to Reproduce

1. Create new empty project
2. Create new shapefile layer of type Point, with the default id integer field intact
3. Turn on edit mode and add a new point, giving a new ID
4. Right-click on the layer in the layers panel and Export --> Save features as... --> Format: GeoJSON
5. Open exported geoJSON in a text editor

Using ogr2ogr

• Same thing happens with ogr2ogr output.geojson input.shp:

• With the -preserve_fid flag enabled, QGIS's id remains inside properties, but ogr2ogr adds its own top-level id incrementing from 0:
  { "type": "Feature", "id": 0, "properties": { "id": 22 }, "geometry": { "type": "Point", "coordinates": [ -87.617569033727861, 41.866959795008569 ] } }

• The output is correct using the -lco id_field=id flag, like ogr2ogr output.geojson input.shp -lco id_field=id

QGIS and OS versions

3.16.0 Hanover
macOS 11.1

Additional context
The same issue is described in other places:

• 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

[gioman]

Export layer to geoJSON

@arcataroger how? using the "export as..." dialog? using a tool (i.e "concert format") in Processing toolbox? have you tried the conversoin with ogr2ogr? if yes, how about the result? if no, can you test it?

[arcataroger]

Export layer to geoJSON

@arcataroger how? using the "export as..." dialog? using a tool (i.e "concert format") in Processing toolbox? have you tried the conversoin with ogr2ogr? if yes, how about the result? if no, can you test it?

@gioman Thanks for checking in, and happy new year :)

Yes, using the Export As dialog. It happens with ogr2ogr as well, both by default and using the preserve_fid flag. However, using -lco id_field=id results in a successful, correct output (per https://gis.stackexchange.com/a/286852/12167) But that's a lot of hoops to jump through, and also breaks the ability to natively edit/save geoJSON in QGIS. In our workflow, for example, we commit the geoJSON files directly to our codebase repo and open/edit/save the geoJSONs directly from QGIS without any intermediary shapefiles or geopackages. While it's possible to use ogr2ogr to re-save the affected geoJSONs after the fact, that seems a bit silly.

I am not sure if QGIS uses GDAL/ogr2ogr behind the scenes, but if so, perhaps the lco id_field=id flag could be added as an option to the geoJSON exporter?

I've updated the original issue summary with more details.

[gioman]

I am not sure if QGIS uses GDAL/ogr2ogr behind the scenes, but if so, perhaps the lco id_field=id flag could be added as an option to the geoJSON exporter?

@arcataroger the "help" button in the "save vector layer as..." dialog point to

https://docs.qgis.org/3.16/en/docs/user_manual/managing_data_source/create_layers.html#vector-specific-parameters

were you can find this paragraph:
Datasource Options, Layer Options or Custom Options which allow you to configure advanced parameters depending on the output format. Some are described in Exploring Data Formats and Fields but for full details, see the GDAL driver documentation. Each file format has its own custom parameters, e.g. for the GeoJSON format have a look at the GDAL GeoJSON documentation.

So... if you add the necessary GDAL layer creation option:

you get what you expect.

[arcataroger]

I am not sure if QGIS uses GDAL/ogr2ogr behind the scenes, but if so, perhaps the lco id_field=id flag could be added as an option to the geoJSON exporter?

@arcataroger the "help" button in the "save vector layer as..." dialog point to

https://docs.qgis.org/3.16/en/docs/user_manual/managing_data_source/create_layers.html#vector-specific-parameters

were you can find this paragraph:
Datasource Options, Layer Options or Custom Options which allow you to configure advanced parameters depending on the output format. Some are described in Exploring Data Formats and Fields but for full details, see the GDAL driver documentation. Each file format has its own custom parameters, e.g. for the GeoJSON format have a look at the GDAL GeoJSON documentation.

So... if you add the necessary GDAL layer creation option:

you get what you expect.

Great, thanks for that tip! Super helpful as a workaround.

Probably should still keep this open as a bug, though? The geoJSON spec is pretty clear that the ID should be a member, not part of properties. As it stands, the QGIS export output is not to spec, and it took me a while to figure out why my geoJSON files weren't working with other software (OpenLayers) until I tracked down this bug. Others, as per the links above, are affected as well.

[gioman]

Great, thanks for that tip! Super helpful as a workaround.

Probably should still keep this open as a bug, though? The geoJSON spec is pretty clear that the ID should be a member, not part of properties. As it stands, the QGIS export output is not to spec, and it took me a while to figure out why my geoJSON files weren't working with other software (OpenLayers) until I tracked down this bug. Others, as per the links above, are affected as well.

@arcataroger I don't agree is a workaround nor a bug, at best it is a feature request asking to improve the GUI of the dialog in case the geojson format is selected (in a way that "forces" the user to select the column for the "id_field" LCO.

[arcataroger]

Great, thanks for that tip! Super helpful as a workaround.
Probably should still keep this open as a bug, though? The geoJSON spec is pretty clear that the ID should be a member, not part of properties. As it stands, the QGIS export output is not to spec, and it took me a while to figure out why my geoJSON files weren't working with other software (OpenLayers) until I tracked down this bug. Others, as per the links above, are affected as well.

@arcataroger I don't agree is a workaround nor a bug, at best it is a feature request asking to improve the GUI of the dialog in case the geojson format is selected (in a way that "forces" the user to select the column for the "id_field" LCO.

@gioman Are there situations where a user might want to export geoJSON that's not to spec? If not, why wouldn't the exporter want to conform to the spec by default?

IMO, the bug isn't that the id_field isn't preselected, but that QGIS/GDAL by default creates invalid geoJSON no matter where you specify the ID. It's not a UI problem as much as a (reasonable, I believe?) belief that:

• Given the assumption that new features in QGIS have IDs (whether "id" or "fid")
• Those IDs can be exported
• Shouldn't the export process respect the ID specs for a given format? The same way the exporter puts geometry and type in the correct places (as top-level members for each feature), ID should be the same. It's not supposed to be an embedded property, per the spec.

Edit to add: The ID of a feature isn't just a generic, user-defined property, but a core part of geoJSON used by other software and expected in a certain format/place. By default, QGIS right now creates broken exports that other software cannot use without this modification/workaround.

[gioman]

@gioman Are there situations where a user might want to export geoJSON that's not to spec? If not, why wouldn't the exporter want to conform to the spec by default?

IMO, the bug isn't that the id_field isn't preselected, but that QGIS/GDAL by default creates invalid geoJSON no matter where you specify the ID. It's not a UI problem as much as a (reasonable, I believe?) belief that:

* Given the assumption that new features in QGIS have IDs (whether "id" or "fid")

* Those IDs can be exported

* Shouldn't the export process respect the ID specs for a given format? The same way the exporter puts `geometry` and `type` in the correct places (as top-level members for each feature), ID should be the same. It's not supposed to be an embedded property, per the spec.

Edit to add: The ID of a feature isn't just a generic, user-defined property, but a core part of geoJSON used by other software and expected in a certain format/place. By default, QGIS right now creates broken exports that other software cannot use without this modification/workaround.

@arcataroger if I'm not wrong even ogr2ogr do not use this LCO by default, correct? if yes QGIS behaves coherently I guess. Also: how QGIS would know what is the column to choose for "id_field", there is no garauntee that a "id", "fid", etc. column exist, and in general a user could want to use a column with a generic name, correct? Anyway I have no problem leave this open as bug, I personally just don't think it is given than there is a clear way (not a workaround) to get the expected result.

[arcataroger]

Sorry, I've never used ogr2ogr before this bug (downloaded it because you
said so) -- am I to understand that ogr2ogr is what QGIS uses behind the
scenes, and so I should file this over in their project instead of here?

When I create a new shapefile, the id column is automatically added... is
that not a default? It's possible I set a setting somewhere and forgot
about it...

But if that is a default, it seems like using that id field (if it
exists) would be a sane default. Where the LCO could be handy is to allow
the user to specify another field as ID if they so choose. One way to
expose it might be to have a simple dropdown in the exporter for "Use this
field for geoJSON ID...", which selects the id field by default if it
exists, nothing if it doesn't exist, and allows the user to choose another
one if they so please.

But also happy to bring this up to the ogr2ogr folks (is that part of the
GDAL project?) if that's more appropriate than here. Sorry, I wasn't clear
on the relationship between QGIS and GDAL... really new to this. Thanks for
your patience :)

[arcataroger]

Hmm, it seems like the id field is only a default for shapefiles. Geopackages and spatialite files don't have any fields added by default, at least on my computer. My mistake!

In that case, what you said makes sense... not all layers can be assumed to have an id field for exporting, and QGIS doesn't automatically know which field to use.

I think the dropdown would still be an easy fix, but whether that's more properly a bug or a feature request, I'll leave to you!

[gioman]

Sorry, I've never used ogr2ogr before this bug (downloaded it because you
said so) -- am I to understand that ogr2ogr is what QGIS uses behind the
scenes, and so I should file this over in their project instead of here?

@arcataroger yes, but I'm pretty sure you'll get a similar answer... it is up to the user to apply this LCO because there is no way to automatically the proper column. See below

Hmm, it seems like the id field is only a default for shapefiles. Geopackages and spatialite fields don't have any fields added by default, at least on my computer. My mistake!

even for shapefiles... QGIS GUI adds a "id" column just for user convenience, but is not mandatory (or it could have a completely different name).

If in your workflow you always have shapefiles with an "id" column with a unique identifier, why you don't just create a mini model with the "convert format" from the QGIS processing toolbox where you hard code the LCO you need?

[arcataroger]

That works only for the first conversion from the shapefile to geoJSON, not for subsequently working with the geoJSON as a layer directly. It would be nice to be able to add/edit geometries in geoJSON layers without losing the IDs with subsequent saves.

For example, if you have a geoJSON like this:

{
"type": "FeatureCollection",
"name": "my_geojson",
"crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:EPSG::3857" } },
"features": [
{ "type": "Feature", "id": "only_top_level", "properties": {}, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [ -9753600.426300490275025, 5141026.099048308096826 ], [ -9753526.289699155837297, 5141027.468623659573495 ], [ -9753525.897439897060394, 5141006.235203934833407 ], [ -9753562.965740563347936, 5141005.550416259095073 ], [ -9753600.034041231498122, 5141004.865628583356738 ], [ -9753600.426300490275025, 5141026.099048308096826 ] ] ] ] } },
{ "type": "Feature", "properties": { "id": "only_property" }, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [ -9753599.832634938880801, 5140988.417339080944657 ], [ -9753525.862954199314117, 5140989.783830795437098 ], [ -9753525.52837342210114, 5140971.672609879635274 ], [ -9753570.321762247011065, 5140970.845030345022678 ], [ -9753599.498054161667824, 5140970.306118167936802 ], [ -9753599.832634938880801, 5140988.417339080944657 ] ] ] ] } },
{ "type": "Feature", "id": "both_1", "properties": {"id": "both_2" }, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [ -9753622.106315340846777, 5140958.046617023646832 ], [ -9753612.610966777428985, 5140956.94570704549551 ], [ -9753615.167930025607347, 5140934.891899031586945 ], [ -9753624.66327858902514, 5140935.992809009738266 ], [ -9753622.106315340846777, 5140958.046617023646832 ] ] ] ] } }
]
}

This is how QGIS reads it:

• If the feature has a top-level member ID in the geoJSON, that is used as the QGIS ID field
• If the feature has a property ID in the geoJSON, that is used as the QGIS ID field
• If the feature has both, only the property ID is used as the QGIS ID field

Then, if you edit that ID field in QGIS, it gets saved back to the properties part of the geoJSON and creates unintentional additions and orphans as separate IDs:

{ "type": "Feature", "id": "only_top_level", "properties": { "id": "overwritten" }, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [ -9753600.426300490275025, 5141026.099048308096826 ], [ -9753526.289699155837297, 5141027.468623659573495 ], [ -9753525.897439897060394, 5141006.235203934833407 ], [ -9753562.965740563347936, 5141005.550416259095073 ], [ -9753600.034041231498122, 5141004.865628583356738 ], [ -9753600.426300490275025, 5141026.099048308096826 ] ] ] ] } },
{ "type": "Feature", "properties": { "id": "overwritten" }, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [ -9753599.832634938880801, 5140988.417339080944657 ], [ -9753525.862954199314117, 5140989.783830795437098 ], [ -9753525.52837342210114, 5140971.672609879635274 ], [ -9753570.321762247011065, 5140970.845030345022678 ], [ -9753599.498054161667824, 5140970.306118167936802 ], [ -9753599.832634938880801, 5140988.417339080944657 ] ] ] ] } },
{ "type": "Feature", "id": "both_1", "properties": { "id": "overwritten" }, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [ -9753622.106315340846777, 5140958.046617023646832 ], [ -9753612.610966777428985, 5140956.94570704549551 ], [ -9753615.167930025607347, 5140934.891899031586945 ], [ -9753624.66327858902514, 5140935.992809009738266 ], [ -9753622.106315340846777, 5140958.046617023646832 ] ] ] ] } }

(Now the first feature has a new ID while the old one still exists, while the third feature had its both_1 ID unintentionally kept there).

That's if I try to save the edits in place (using the "Save Layer Edits" button). If I instead try to use the format convert in the toolbox, it won't let me convert the same file in-place, overwriting the one currently open (the dialog just crashes when I try to replace the file). If I manually specify the same filename instead of using the browser, the log output asks me to use -update. If I do that, then it produces a "Layer my_geojson already exists, and -append not specified." error. If I do that, then it produces a ERROR 5: -nln name must be specified combined with a single source layer name, or a -sql statement, and name must be different from an existing layer. error.

If I try to use the Export dialog instead, it won't let me overwrite an existing file:

So, still no way to edit and re-save a geoJSON in place, with IDs intact as per the spec :(

(This really isn't the end of the world, since it's possible to take care of it as a batch find/replace after edits, but it is a hassle. And perhaps more importantly, this behavior is pretty unexpected when you're working with a format as common as geoJSON. While the workaround of using the id_field is pretty straightforward, it's not at all something I would've thought to look for when trying to save a geoJSON file.

I guess the difference is that to geoJSONs, the ID field has special importance. To QGIS and ogr2ogr, it's just another user-defined field with no special significance.)

[gioman]

That works only for the first conversion from the shapefile to geoJSON, not for subsequently working with the geoJSON as a layer directly. It would be nice to be able to add/edit geometries in geoJSON layers without losing the IDs with subsequent saves.

For example, if you have a geoJSON like this:

{
"type": "FeatureCollection",
"name": "my_geojson",
"crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:EPSG::3857" } },
"features": [
{ "type": "Feature", "id": "only_top_level", "properties": {}, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [ -9753600.426300490275025, 5141026.099048308096826 ], [ -9753526.289699155837297, 5141027.468623659573495 ], [ -9753525.897439897060394, 5141006.235203934833407 ], [ -9753562.965740563347936, 5141005.550416259095073 ], [ -9753600.034041231498122, 5141004.865628583356738 ], [ -9753600.426300490275025, 5141026.099048308096826 ] ] ] ] } },
{ "type": "Feature", "properties": { "id": "only_property" }, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [ -9753599.832634938880801, 5140988.417339080944657 ], [ -9753525.862954199314117, 5140989.783830795437098 ], [ -9753525.52837342210114, 5140971.672609879635274 ], [ -9753570.321762247011065, 5140970.845030345022678 ], [ -9753599.498054161667824, 5140970.306118167936802 ], [ -9753599.832634938880801, 5140988.417339080944657 ] ] ] ] } },
{ "type": "Feature", "id": "both_1", "properties": {"id": "both_2" }, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [ -9753622.106315340846777, 5140958.046617023646832 ], [ -9753612.610966777428985, 5140956.94570704549551 ], [ -9753615.167930025607347, 5140934.891899031586945 ], [ -9753624.66327858902514, 5140935.992809009738266 ], [ -9753622.106315340846777, 5140958.046617023646832 ] ] ] ] } }
]
}

This is how QGIS reads it:

* If the feature has a top-level member ID in the geoJSON, that is used as the QGIS ID field

* If the feature has a property ID in the geoJSON, that is used as the QGIS ID field

* If the feature has both, only the property ID is used as the QGIS ID field

Then, if you edit that ID field in QGIS, it gets saved back to the properties part of the geoJSON and creates unintentional additions and orphans as separate IDs:

{ "type": "Feature", "id": "only_top_level", "properties": { "id": "overwritten" }, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [ -9753600.426300490275025, 5141026.099048308096826 ], [ -9753526.289699155837297, 5141027.468623659573495 ], [ -9753525.897439897060394, 5141006.235203934833407 ], [ -9753562.965740563347936, 5141005.550416259095073 ], [ -9753600.034041231498122, 5141004.865628583356738 ], [ -9753600.426300490275025, 5141026.099048308096826 ] ] ] ] } },
{ "type": "Feature", "properties": { "id": "overwritten" }, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [ -9753599.832634938880801, 5140988.417339080944657 ], [ -9753525.862954199314117, 5140989.783830795437098 ], [ -9753525.52837342210114, 5140971.672609879635274 ], [ -9753570.321762247011065, 5140970.845030345022678 ], [ -9753599.498054161667824, 5140970.306118167936802 ], [ -9753599.832634938880801, 5140988.417339080944657 ] ] ] ] } },
{ "type": "Feature", "id": "both_1", "properties": { "id": "overwritten" }, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [ -9753622.106315340846777, 5140958.046617023646832 ], [ -9753612.610966777428985, 5140956.94570704549551 ], [ -9753615.167930025607347, 5140934.891899031586945 ], [ -9753624.66327858902514, 5140935.992809009738266 ], [ -9753622.106315340846777, 5140958.046617023646832 ] ] ] ] } }

(Now the first feature has a new ID while the old one still exists, while the third feature had its both_1 ID unintentionally kept there).

That's if I try to save the edits in place (using the "Save Layer Edits" button). If I instead try to use the format convert in the toolbox, it won't let me convert the same file in-place, overwriting the one currently open (the dialog just crashes when I try to replace the file). If I manually specify the same filename instead of using the browser, the log output asks me to use -update. If I do that, then it produces a "Layer my_geojson already exists, and -append not specified." error. If I do that, then it produces a ERROR 5: -nln name must be specified combined with a single source layer name, or a -sql statement, and name must be different from an existing layer. error.

If I try to use the Export dialog instead, it won't let me overwrite an existing file:

So, still no way to edit and re-save a geoJSON in place, with IDs intact as per the spec :(

(This really isn't the end of the world, since it's possible to take care of it as a batch find/replace after edits, but it is a hassle. And perhaps more importantly, this behavior is pretty unexpected when you're working with a format as common as geoJSON. While the workaround of using the id_field is pretty straightforward, it's not at all something I would've thought to look for when trying to save a geoJSON file.

I guess the difference is that to geoJSONs, the ID field has special importance. To QGIS and ogr2ogr, it's just another user-defined field with no special significance.)

@arcataroger this seems anyway a different issue from the one initially reported in this ticket. I suggest filing a new one (if you find multiple issue is 1 issue per ticket). Please note that the messages you are getting are from OGR, you should check first if you get the same problems using ogr2ogr to translate/edit this datasources, if yes the is likely to be an OGR issue, not qgis's.

[gioman]

@arcataroger as you can see GQIS seems coherent with OGR:

ogrinfo test.geojson my_geojson    
INFO: Open of `test.geojson'
      using driver `GeoJSON' successful.

Layer name: my_geojson
Geometry: Multi Polygon
Feature Count: 3
Extent: (-9753624.663279, 5140934.891899) - (-9753525.528373, 5141027.468624)
Layer SRS WKT:
PROJCRS["WGS 84 / Pseudo-Mercator",
    BASEGEOGCRS["WGS 84",
        DATUM["World Geodetic System 1984",
            ELLIPSOID["WGS 84",6378137,298.257223563,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4326]],
    CONVERSION["Popular Visualisation Pseudo-Mercator",
        METHOD["Popular Visualisation Pseudo Mercator",
            ID["EPSG",1024]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["False easting",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["easting (X)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["northing (Y)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["unknown"],
        AREA["World - 85°S to 85°N"],
        BBOX[-85.06,-180,85.06,180]],
    ID["EPSG",3857]]
Data axis to CRS axis mapping: 1,2
id: String (0.0)
OGRFeature(my_geojson):0
  id (String) = only_top_level
  MULTIPOLYGON (((-9753600.42630049 5141026.09904831,-9753526.28969916 5141027.46862366,-9753525.8974399 5141006.23520393,-9753562.96574056 5141005.55041626,-9753600.03404123 5141004.86562858,-9753600.42630049 5141026.09904831)))

OGRFeature(my_geojson):1
  id (String) = only_property
  MULTIPOLYGON (((-9753599.83263494 5140988.41733908,-9753525.8629542 5140989.7838308,-9753525.52837342 5140971.67260988,-9753570.32176225 5140970.84503035,-9753599.49805416 5140970.30611817,-9753599.83263494 5140988.41733908)))

OGRFeature(my_geojson):2
  id (String) = both_2
  MULTIPOLYGON (((-9753622.10631534 5140958.04661702,-9753612.61096678 5140956.94570705,-9753615.16793003 5140934.89189903,-9753624.66327859 5140935.99280901,-9753622.10631534 5140958.04661702)))

[arcataroger]

Right, but is "coherence with OGR" really the underlying objective here, as opposed to "being able to edit geoJSON in-place without destroying IDs"? The command-line tools have a different use case than QGIS, don't they? For the command-line tools, it totally makes sense to specify flags and parameters. They were built for transformations (is there even an "open, modify, and save in place" workflow for the command-line tools?). But when I'm just trying to save the geometries I'm editing in QGIS, shouldn't I be able to do so without jumping through hoops with every save? It is confusing to users when IDs get ambiguously read and saved.

Do you agree that being able to work with geoJSONs in-place, retaining IDs, would be a useful addition to QGIS (maybe more properly as a feature request, as you suggested), or do you think that's just entirely out of scope? If you agree, I believe this would make more sense as a GUI tweak in GQIS, or a modification to the geoJSON driver, regardless of how the command-line tools work. I only brought up those errors to illustrate that the command line tools aren't really made for this use case.

To be clear, what I think would be most helpful is an additional geoJSON-specific parameter, "Use field X as ID", built into the exporter/driver (and retained with subsequent saves), alongside the other current geoJSON-specific options. I understand this would be inconsistent with the command-line tools, but maybe that's OK given the different use case? This is a quirk of the geoJSON format, granted, but IMHO it's not an unreasonable one for QGIS to understand and deal with in a more user-friendly way. It's a fantastic tool for editing geoJSONs otherwise (and there aren't many out there!)

I would be happy to try and make a PR for this myself if I could... if you have any suggestions as to where to start, I'll look into it and try to learn.

Or if you think this is entirely out of scope for QGIS, that being able to read/edit/save geoJSONs as layers directly isn't an intended use case, then I understand and thank you for all your time and patience here. I especially appreciate you taking the time to walk me through the thought processes -- I had no idea how QGIS worked behind the scenes, so this discussion illuminated a lot for me.

Thank you either way :)

[gioman]

To be clear, what I think would be most helpful is an additional geoJSON-specific parameter, "Use field X as ID", built into the exporter/driver (and retained with subsequent saves), alongside the other current geoJSON-specific options. I understand this would be inconsistent with the command-line tools, but maybe that's OK given the different use case? This is a quirk of the geoJSON format, granted, but IMHO it's not an unreasonable one for QGIS to understand and deal with in a more user-friendly way. It's a fantastic tool for editing geoJSONs otherwise (and there aren't many out there!)

@arcataroger this seems reasonable to me, it is anyway a feature request, not a bug. Feel free to open one. Also you may know (or not)... this is open source, so if for your organization workflow this is really important you have the power to make it happen sooner than later.

[arcataroger]

@gioman I will open a new feature request and link it back to this one, closing this one in the meantime. Thank you!

I'm a relatively new dev in general, and haven't touch C++ in a decade, but I would love to help contribute if I can. I'll look into what it would take to add that option. Thanks again for all the tips.

[gioman]

but I would love to help contribute if I can

@arcataroger on qgis.org there is a page about commercial support, there are plenty of individuals and companies that can get you where you need.

[arcataroger]

@gioman Sadly, the nonprofit I work for has no money to sponsor something like this. However, I do appreciate all the work the community has put into QGIS, so I donated some personal funds just now as a small token of gratitude. Thanks again for taking the time to walk me through this.