Export to KML generates invalid file

[Yogurt4]

What is the bug or the crash?

The export progress goes smoothly without any warnings and finishes successfully but the generated file has all

<coordinates>0.0,inf 0.0,inf 0.0,inf 0.0,inf 0.0,inf</coordinates>

in it.

Steps to reproduce the issue

1. Extract wfs_211680662.zip
2. Add a Vector Layer for this Shapefile.
3. You should see Hungarian motorways and trunk roads fine.
4. Select this layer, right click, select Export... / Save elements as...
5. Format: "Keyhole Markup Language [KML]", give a target file name, CRS: "EPSG:4326 - WGS84"
6. Open the saved KML in a text viewer. All coordinates are 0.0,inf.

A funny thing: If you leave the "Add exported file to the map" (or whatever it's in English) checkbox checked, a new layer is added with seemingly proper contents. However, if you try to add the just-saved KML, the map remains empty (obviously).

Versions

QGIS-verzió	3.40.2-Bratislava
QGIS forráskódverzió	14826ca1
Könyvtárak
Qt-verzió	5.15.13
Python-verzió	3.12.8
GDAL/OGR-verzió	3.9.3
PROJ-verzió	9.5.0
EPSG-nyilvántartási adatbázis verziója	v11.016 (2024-08-31)
GEOS-verzió	3.13.0-CAPI-1.19.0
SQLite-verzió	3.46.1
PDAL-verzió	2.8.1
Postgresql kliens verziója	16.2
SpatiaLite-verzió	5.1.0
QWT-verzió	6.3.0
QScintilla2-verzió	2.14.1
OS-verzió	Windows 10 Version 2009
Aktív Python-modulok
SentinelHub	2.0.2
MetaSearch	0.3.6
processing	2.12.99
QuickOSM	2.3.2

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

No response

[agiudiceandrea]

@Yogurt4, thanks for reporting. It looks like the CRS defined for the provided ESRI Shapefile layer is correctly recognised/supported neither by QGIS nor by the GDAL/OGR library (maybe also the PROJ library), thus the transformation to the EPSG:4326 CRS fails.

[elpaso]

@agiudiceandrea yes, you can see that in the logs:
2025-01-22T11:44:08 WARNING Error transforming extent: Could not transform bounding box to target CRS
but I think QGIS export should fail with an error instead of silently produce an unusable KML.

[Yogurt4]

As a note, this is the official datum used in the whole country. I know it's a mathematically difficult projection, but QGIS itself manages fine to display it. You can put OpenStreetMap tiles behind it to check.
It's just the export that has this reprojection problem.

[agiudiceandrea]

QGIS itself manages fine to display it. You can put OpenStreetMap tiles behind it to check.

It doesn't seems the case in my system (QGIS 3.40.2 OSGeo4W / Windows 10):

• if you add the "wfs_211680662Line" ESRI Shapefile layer in an empty project, then the project's CRS is automatically set to "Unknown CRS" and the "WARNING Error transforming extent: Could not transform bounding box to target CRS" message is printed in the "General" tab of the Log Messages panel;
• if afterwards the OpenStreetMap XYZ Tile layer is added to the project, the it will be impossible to display such layer and the "WARNING Transform error caught: Could not transform bounding box to target CRS" message is printed in the "CRS" tab of the Log Messages panel and a bunch of "WARNING Could not reproject layer extent: Could not transform bounding box to target CRS" messages is printed in the "Raster" tab of the Log Messages panel;
• if you set the project's CRS to the OpenStreetMap XYZ Tile layer's CRS (EPSG:3857) the is possible to display such layer, but it is not possible to zoom to the "wfs_211680662Line" layer and a bunch of "WARNING Simplify transform error caught: Forward transform ( to EPSG:3857) of (0.000000, 0.000000) Error: No inverse operation" messages is printed in the "Raster" tab of the Log Messages panel.

projinfo shows some issue in the layer's CRS definition stored in the *.prj ESRI Shapefile sidecar file:

projinfo --identify @wfs_211680662Line.prj
Warning: Coordinate system of GeographicCRS in the WKT definition is different from the one of the authority. Unsetting the identifier to avoid confusion
PROJ.4 string:
Error when exporting to PROJ string: Unsupported conversion method: Oblique_Mercator

WKT2:2019 string:
BOUNDCRS[
    SOURCECRS[
        PROJCRS["HD72 / EOV",
            BASEGEOGCRS["HD72",
                DATUM["Hungarian Datum 1972",
                    ELLIPSOID["GRS 1967",6378160,298.247167427,
                        LENGTHUNIT["metre",1]]],
                PRIMEM["Greenwich",0,
                    ANGLEUNIT["degree",0.0174532925199433]]],
            CONVERSION["unnamed",
                METHOD["Oblique_Mercator"],
                PARAMETER["longitude_of_center",19.0485717777778,
                    ANGLEUNIT["degree",0.0174532925199433]],
                PARAMETER["latitude_of_center",47.1443937222222,
                    ANGLEUNIT["degree",0.0174532925199433]],
                PARAMETER["azimuth",90,
                    ANGLEUNIT["degree",0.0174532925199433]],
                PARAMETER["scale_factor",0.99993,
                    SCALEUNIT["unity",1]],
                PARAMETER["false_easting",650000,
                    LENGTHUNIT["m",1]],
                PARAMETER["false_northing",200000,
                    LENGTHUNIT["m",1]],
                PARAMETER["rectified_grid_angle",90,
                    ANGLEUNIT["degree",0.0174532925199433]]],
            CS[Cartesian,2],
                AXIS["easting",east,
                    ORDER[1],
                    LENGTHUNIT["m",1]],
                AXIS["northing",north,
                    ORDER[2],
                    LENGTHUNIT["m",1]],
            ID["EPSG",23700]]],
    TARGETCRS[
        GEOGCRS["WGS 84",
            DATUM["World Geodetic System 1984",
                ELLIPSOID["WGS 84",6378137,298.257223563,
                    LENGTHUNIT["metre",1]]],
            PRIMEM["Greenwich",0,
                ANGLEUNIT["degree",0.0174532925199433]],
            CS[ellipsoidal,2],
                AXIS["latitude",north,
                    ORDER[1],
                    ANGLEUNIT["degree",0.0174532925199433]],
                AXIS["longitude",east,
                    ORDER[2],
                    ANGLEUNIT["degree",0.0174532925199433]],
            ID["EPSG",4326]]],
    ABRIDGEDTRANSFORMATION["Transformation from HD72 to WGS84",
        METHOD["Position Vector transformation (geog2D domain)",
            ID["EPSG",9606]],
        PARAMETER["X-axis translation",52.17,
            ID["EPSG",8605]],
        PARAMETER["Y-axis translation",-71.82,
            ID["EPSG",8606]],
        PARAMETER["Z-axis translation",-14.9,
            ID["EPSG",8607]],
        PARAMETER["X-axis rotation",0,
            ID["EPSG",8608]],
        PARAMETER["Y-axis rotation",0,
            ID["EPSG",8609]],
        PARAMETER["Z-axis rotation",0,
            ID["EPSG",8610]],
        PARAMETER["Scale difference",1,
            ID["EPSG",8611]]]]

Identification match count: 1
BoundCRS of EPSG:23700: 25 %

To workaround the issue, you need to manually assign (Layer Properties -> Source -> Assigned Coordinate Reference System) the CRS "EPSG:23700" to the layer. You can also use the "Define Shapefile projection" processing algorithm to permanently set the CRS "EPSG:23700" to the ESRI Shapefile layer.

This way, the exported KML layer is correctly generated.

[agiudiceandrea]

The exporting issue with such layer also occurs for any other output layer format, when a reprojection is needed (if a different output CRS is set), and also using the "Vector general -> Reproject layer" processing algorithm.

Even ogr2ogr (from GDAL/OGR 3.9.3) generates not correctly transformed KML file (and any other file format) layer and prints various error messages:

ogr2ogr wfs_211680662Line.kml wfs_211680662Line.shp
Warning 1: Several drivers matching kml extension. Using LIBKML
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: No inverse operation
ERROR 1: Reprojection failed, err = 4098, further errors will be suppressed on the transform object.

[Yogurt4]

The difference might be due to that I have conversions from EOV (to WGS-84 and to Web Mercator) added.
If I removed them, I got the very same results as you.
All in all, manually setting/forcing EPSG:23700 fixes the KML export.

Then it's just lacking some user feedback on failure as @elpaso wrote.

[elpaso]

@rouault I am looking at the issue, it seems to me that OGR_G_ExportToKML should return NULL when such an error occoured, if that's the case I can fix this upstream instead of a fragile "let's check if OGR has error" from QGIS.

[agiudiceandrea]

@elpaso, the exporting issue with such layer also occurs for any other output layer format, not only KML.

[rouault]

it seems to me that OGR_G_ExportToKML should return NULL when such an error occoured

yes that would be the right thing to do here

[rouault]

@Yogurt4 Do you know which software has generated this shapefile ? The use of "Oblique_Mercator" in the .prj file is incorrect, or at the very least unttypical, it should be instead "Hotine_Oblique_Mercator_Azimuth_Center"

[Yogurt4]

Do you know which software has generated this shapefile ? The use of "Oblique_Mercator" in the .prj file is incorrect, or at the very least unttypical, it should be instead "Hotine_Oblique_Mercator_Azimuth_Center"

I'll try to get information on this. It was exported by a government organisation. (The Shapefile has other issues, like inconsistency between the points, the element bounding boxes and the file bounding box.)