Inconsistent behavior of ST_READ in importing EMPTY geometry

[cuteDen-ECNU]

Considering the following geojson file:

{
    "type": "FeatureCollection",
    "features": [
        {
            "type": "Feature",
            "geometry": {
                "type": "Polygon",
                "coordinates": []
            },
            "properties": {
                "id": 0
            }
        },
        {
            "type": "Feature",
            "geometry": {
                "type": "LineString",
                "coordinates": []
            },
            "properties": {
                "id": 1
            }
        }
    ]
}

and SQL statement:

CREATE TABLE t0 AS SELECT * FROM ST_READ('/log/t0.geojson');
SELECT id, ST_AsText(geom) FROM t0;
-- ┌───────┬──────────────────┐
-- │  id   │ st_astext(geom)  │
-- │ int32 │     varchar      │
-- ├───────┼──────────────────┤
-- │     0 │                  │
-- │     1 │ LINESTRING EMPTY │
-- └───────┴──────────────────┘

The EMPTY POLYGON should be imported into t0 to avoid losing information during the importing process.

Besides, the EMPTY LINESTRING is imported successfully. The importing behaviors of POLYGON and LINESTRING should be consistent.

Version:
Spatial version:
FORCE INSTALL spatial FROM 'http://nightly-extensions.duckdb.org'; and LOAD spatial;

DuckDB version:

┌─────────────────┬────────────┐
│ library_version │ source_id  │
│     varchar     │  varchar   │
├─────────────────┼────────────┤
│ v0.10.0         │ 20b1486d11 │
└─────────────────┴────────────┘

[rouault]

Considering the following geojson file:

assuming DukDB Spatial uses GDAL for GeoJSON parsing, this will be fixed per OSGeo/gdal#9437
Note however that {"type": "LineString", "coordinates": []] is invalid against https://geojson.org/schema/LineString.json which requires an array of 2 points minimum. The concept of empty geometries in GeoJSON isn't super well defined