<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>(re-adding the list)
</p>
<div class="moz-cite-prefix">Le 23/06/2023 à 11:34, B. De Mezzo a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:2fc36c19-a27e-fe00-2b65-d5a9754425c1@oslandia.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Thanks!</p>
<p>I will try this sql request to handle this specific case.</p>
<p>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.</p>
</blockquote>
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
<a class="moz-txt-link-freetext" href="https://github.com/OSGeo/gdal/blob/master/ogr/ogrsf_frmts/generic/ogrlayer.cpp#L230">https://github.com/OSGeo/gdal/blob/master/ogr/ogrsf_frmts/generic/ogrlayer.cpp#L230</a>
. Driver specializations could indeed come afterwards<br>
<blockquote type="cite"
cite="mid:2fc36c19-a27e-fe00-2b65-d5a9754425c1@oslandia.com">
<p>Benoit.
</p>
<div class="moz-cite-prefix">Le 23/06/2023 à 11:25, Even Rouault a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:4006468e-dec1-5b21-8630-08a8385a31c1@spatialys.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Benoit,</p>
<p>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.</p>
<p>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.</p>
<p>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</p>
<p>Even
</p>
<div class="moz-cite-prefix">Le 23/06/2023 à 11:14, B. De Mezzo
a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:9d6ab5a5-4179-e486-8f2d-4253ee72cd8d@oslandia.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<p>Hi,</p>
<p>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. </p>
<p>What should be the best approach to the minZ and maxZ for a layer?</p>
<p>Regards.
</p>
<p><style type="text/css"></style></p>
<p><style type="text/css">Regardp, li { white-space: pre-wrap; }</style><style type="text/css">p, li { white-space: pre-wrap; }</style></p>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:gdal-dev@lists.osgeo.org" moz-do-not-send="true">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com" moz-do-not-send="true">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>