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
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
