GPGK Getextent3D semi-fast implementation #8910
Conversation
Co-authored-by: Even Rouault <even.rouault@spatialys.com>
elpaso
force-pushed
the
getextent3d-gpkg
branch
from
aa1f366
to
be0fc5c
Compare
| extent3D.MinZ = sHeader.MinZ; | ||
| extent3D.MaxZ = sHeader.MaxZ; |
There was a problem hiding this comment.
There's one case that is probably not well covered. It is possible that a 3D geometry has a extent in the GPKG geometry header, but without the Z values (. sHeader.MinZ/sHeader.MaxZ as returned by GPkgHeaderFromWKB() are only valid if poHeader->bExtentHasZ .
Cf http://www.geopackage.org/spec/#gpb_format and bit E: envelope contents indicator code (3-bit unsigned integer).
I don't think the GeoPackage spec mandates to write a 3D envelope if the geometry is 3D (the GDAL GPKG writer will however always write a 3D envelope for a 3D geom, so this would be for .gpkg created by othersoftware). It could be just 2D.
So I believe OGRGeoPackageGetHeader() should be modified to have an extra bNeedExtent3D flag, where you would call getEnvelope3D() if only having a 2D envelope in the GeoPackage geometry header.
There was a problem hiding this comment.
I see... Do you have any recommendation about how to build a test for that case?
Also it is not entirely clear to me when this branch is triggered (and how to test it): https://github.com/OSGeo/gdal/pull/8910/files#diff-1b62be67e99a70d80f3b1651237e60b85c47cdb406a591e5d50dd0f13676361bR529
There was a problem hiding this comment.
Do you have any recommendation about how to build a test for that case?
the easiest would probably to patch GPkgGeometryFromOGR(), around lines 292-347 for the purposes of generating test datasets. One without any envelope at all, and another one with 2D envelopes
There was a problem hiding this comment.
Also it is not entirely clear to me when this branch is triggered (and how to test it): https://github.com/OSGeo/gdal/pull/8910/files#diff-1b62be67e99a70d80f3b1651237e60b85c47cdb406a591e5d50dd0f13676361bR529
perhaps issue an UPDATE table_name SET geom = 'some garbage here' on an existing .gpkg ?
|
Does this qualify for OLCFastGetExtent3D ? I don't think so. |
in the situation where there's a GPKG header with a 3D envelope, which I'd expect to be the nominal situation, it should still be significantly faster than the generic implementation. So I'd let that capability for now |
Followup #8806: