[gdal-dev] Why does OGREnvelope default to valid values when uninitialized?

[Even Rouault]

On mardi 21 mars 2017 12:14:52 CET Vautour, André (INT) wrote:
> Hi all,
> 
> We've recently updated from GDAL 1.11.x to GDAL 2.1.x and ran into some
> failing unit tests.
> 
> I can simplify the failure to:
> 
> OGRPoint aPoint(0.0, 0.0);
> OGRPoint anotherPoint(1.0, 1.0);
> OGRMultiPoint multiPoint;
> multiPoint.addGeometry(&aPoint);
> multiPoint.addGeometry(&anotherPoint);
> 
> OGREnvelope envelope;
> multiPoint.getEnvelope(&envelope);
> 
> The minx/miny are both 1.0, when I would have expected them to be 0.0.
> 
> Looks like OGRGeometryCollection::getEnvelope was updated to make use of
> OGREnvelope3D::Merge() during the curve geometry work. From what I can
> tell, the envelope of the 0.0, 0.0 point is seen as uninitialized since
> OGREnvelope::IsInit() returns false in that case.
> 
> Would it make sense to have the uninitialized envelope values be outside the
> range of typical coordinate reference systems to avoid such problems?
> Something like std::numeric_limits<double>::max().

Good catch. I've solved the issue in the way you suggest in trunk (initializing the max to -inf 
and min to inf, so that Merge() doesn't need to look if the envelope is initialized).
And for 2.1, I didn't want to change the OGREnvelope[3D] initialization values, so I've fixed it 
differently (actually using code similar to 1.11 that didn't use Merge() but did it manually).

Fixed per https://trac.osgeo.org/gdal/ticket/6841

Even


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170321/5316aca6/attachment.html>