Export>Save Features As... : Omits records with NULL geom when "Current Layer Extent" is pressed

[multiquadric]

What is the bug or the crash?

GeoJSON input. CSV output. Pressed "Current Layer Extent" and two records were not exported (converted, from GeoJSON, to CSV).

Steps to reproduce the issue

1. Load GeoJSON
2. Export>Save Features As...
3. Press Current Layer Extent
4. Press OK

gn_50000-6.geojson.txt

Versions

<style type="text/css"> p, li { white-space: pre-wrap; } </style>

QGIS version	3.38.2-Grenoble	QGIS code branch	Release 3.38
Qt version	5.15.12
Python version	3.12.5
GDAL/OGR version	3.9.1
PROJ version	9.4.1
EPSG Registry database version	v11.006 (2024-03-13)
GEOS version	3.12.2-CAPI-1.18.2
SQLite version	3.46.1
PDAL version	2.7.2
PostgreSQL client version	unknown
SpatiaLite version	5.1.0
QWT version	6.1.6
QScintilla2 version	2.13.3
OS version	macOS 14.6
Active Python plugins
Socrata	2.2
Coordtransform	1.1
latlontools	3.7.0
wfs_styler	1.0.1
gml_application_schema_toolbox	1.3.1
processing	2.12.99
grassprovider	2.12.99
db_manager	0.1.20
MetaSearch	0.3.6

QGIS version 3.38.2-Grenoble QGIS code branch [Release 3.38](https://github.com/qgis/QGIS/tree/release-3_38) Qt version 5.15.12 Python version 3.12.5 GDAL/OGR version 3.9.1 PROJ version 9.4.1 EPSG Registry database version v11.006 (2024-03-13) GEOS version 3.12.2-CAPI-1.18.2 SQLite version 3.46.1 PDAL version 2.7.2 PostgreSQL client version unknown SpatiaLite version 5.1.0 QWT version 6.1.6 QScintilla2 version 2.13.3 OS version macOS 14.6

Active Python plugins
Socrata
2.2
Coordtransform
1.1
latlontools
3.7.0
wfs_styler
1.0.1
gml_application_schema_toolbox
1.3.1
processing
2.12.99
grassprovider
2.12.99
db_manager
0.1.20
MetaSearch
0.3.6

Supported QGIS version

• I'm running a supported QGIS version according to the roadmap.

New profile

• I tried with a new QGIS profile

Additional context

Absent any warning, it was a surprise to see two records omitted from a large dataset.

It is not clear, to me, if the ogr2ogr call in QGIS can be duplicated at the command-line. One cannot see what parameters were passed to ogr2ogr.

[agiudiceandrea]

@multiquadric, since you have set the option "Extent (current: layer)" (why have you set such option?), then IMHO the intended behavior should be to only export features having the associated geometry that is within the current layer extent and it seems to me that a null geometry (or a feature without an associated geometry) cannot be considered to be within the current layer extent.

[multiquadric]

The example file allows one to reproduce the error. It is unexpected behavior. The original data contained over 100,000 points. The intended behavior should not differ with this option. Changing the data representation ought not be a filter. The behavior is not documented (AFAICT).

For the moment, this is a QGIS question. Is the API call correct? Were assumptions made? As time permits, this bug will find its way to GDAL.

A feature request, for GDAL (ogr2ogr) would be to have see input feature counts and output feature counts. A simple flag.

[nyalldawson]

. It is unexpected behavior

I disagree. These features do not lie within the filter extent, so should clearly be omitted from the export.

[multiquadric]

@nyalldawson It is not a filter. Please do not muddy the waters. Thank you.

The generation of the layer extents is an ordinary task. There was neither an ask nor guidance (that I have seen) regarding the culling of records absent geom.

It is entirely reasonable to expect a clean change in the data format.

[nyalldawson]

@multiquadric

It is not a filter.

What would you call it then?

Please do not muddy the waters. Thank you.

Please give me SOME credit here. https://github.com/qgis/QGIS/graphs/contributors

I know what I'm talking about! 🤣

[multiquadric]

The notion of exporting data from one format to another is easy to grasp. The subtleties (advantages and disadvantages) are not (so easy). It is reasonable to expect the data to be preserved unless an action is taken place to remove some features (e.g. those with NULL geom).

If we assume setting the extent will filter data, then the same should be explicitly documented. Who reads documentation? Perhaps a warning should be available to a user somewhere in the process: 48 features exported (converted, ...) and 2 features dropped.

Why? It is not unusual to find data that are being managed in odd and different ways. Deleting a feature? An intermediate steps may be to first delete the positional information. Later, the record (attribution) may also be deleted. Not uncommon. There is no need to point out countries and agencies publishing data with this strategy. Or companies.

Supposing only the documentation were to be changed? OK, however let's also see a change in the GUI for the user.

The use case is not relevant, but suffice it say that a bounding box was a part of a pipeline for handling a large amount of data. The extents were required.

It is clear now that such a pipeline will have an extra step, or perhaps skip QGIS entirely and use ogr2ogr directly.

Docs?
https://docs.qgis.org/3.34/en/docs/user_manual/introduction/general_tools.html#extent-selector

The Extent selector widget is a convenient shortcut when you want to select a spatial extent to assign to a layer or to limit the actions to run on. Depending on the context, it offers selection between:

The former was the goal for me. Filtering was not the intent.

Cheers.

[github-actions]

The QGIS project highly values your report and would love to see it addressed. However, this issue has been left in feedback mode for the last 14 days and is being automatically marked as "stale".
If you would like to continue with this issue, please provide any missing information or answer any open questions. If you could resolve the issue yourself meanwhile, please leave a note for future readers with the same problem and close the issue.
In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this issue.
If there is no further activity on this issue, it will be closed in a week.

[github-actions]

While we hate to see this happen, this issue has been automatically closed because it has not had any activity in the last 42 days despite being marked as feedback. If this issue should be reconsidered, please follow the guidelines in the previous comment and reopen this issue.
Or, if you have any further questions, there are also further support channels that can help you.