(re-adding the list)
Le 23/06/2023 à 11:34, B. De Mezzo a écrit :
Thanks!
I will try this sql request to handle this specific case.
Do you think it could be possible to have a OGR_L_GetExtent3D()
function which returns, as a default implementation, the
OGR_L_GetExtent() result and with 0.0 (or NaN) for the Z coordinates?
Future works can re-implement the OGR_L_GetExtent3D driver function to
fit the real data.
That's technically possible, but at bit odd. I'd say that while at it,
it would be much better to have a default generic implementation in the
base OGRLayer class that does the iteration, just like the 2D version at
https://github.com/OSGeo/gdal/blob/master/ogr/ogrsf_frmts/generic/ogrlayer.cpp#L230
. Driver specializations could indeed come afterwards
Benoit.
Le 23/06/2023 à 11:25, Even Rouault a écrit :
Benoit,
Indeed OGR_L_GetExtent() will never fill the Z fields, since it has
no idea they are there. So a 3D specific function would be needed.
But in the case of GeoPackage, as many/most other formats, layer
extent metadata doesn't include the Z component either. The generic
option is to iterate over all features and use OGR_G_GetEnvelope3D()
on their geometry.
In the specific case of GeoPackage, you could also issue a
ExecuteSQL("SELECT MIN(ST_MinZ(geometry_column_name)),
MAX(ST_MaxZ(geometry_column_name)) FROM layer_name") which should be
faster on big layers
Even
Le 23/06/2023 à 11:14, B. De Mezzo a écrit :
Hi,
I was looking for a solution to retrieve a 3D extent (in my case
from a gpkg). Currently, the OGR_L_GetExtent function uses an
OGREnvelope and when I pass a OGREnvelope3D parameter, it does not
fill the Z fields.
What should be the best approach to the minZ and maxZ for a layer?
Regards.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
