[gdal-dev] GDAL 2.2.0 beta 2 available

[Even Rouault]

On jeudi 27 avril 2017 10:18:13 CEST Sean Gillies wrote:
> Even,
> 
> I've sorted things out. As described in https://github.com/sgillies
> /frs-wheel-builds/issues/15, I only need to change the
> MACOSX_DEPLOYMENT_TARGET in my builds from 10.6 to 10.9 to build GDAL 2.2.0
> (and distribute Python wheels that include it). Sorry, Mountain Lion
> holdouts!
> 
> Rasterio is fine with GDAL 2.2.0beta2 except in a couple tests that check
> reprojection of a geometry that straddles the antimeridian. Whether to cut
> used to be optional, defaulting to false, but after
> https://trac.osgeo.org/gdal/changeset/35964 is true and no longer optional.

Sean,

Are you talking about a case of reprojecting a geometry expressed in a projection like UTM 
60 crossing the antimeridian to long/lat ?
If so, before with WRAPDATELINE=NO, it likely resulted in non sense. And with 
WRAPDATELINE=YES, it might sometimes be corrected after reprojection (but 
WRAPDATELINE=YES is mostly a heuristics to guess if the segment between 2 consecutive 
points was supposed to cross or not the dateline, and it might fail in some cases).

It is true now that in this case (there's also another case for polar projections), the geometry 
is always cut before doing the reprojection operation, before the processing done by 
WRAPDATELINE=YES (which should be a no-op if the cutting has been done before 
reprojection).

Do you think the new before-reprojection-geometry-splitting should be made optional ? If so, 
I'm not entirely sure the option that should condition it should be WRAPDATELINE (given 
that we also deal with polar projections), although adding more options related to that might 
confuse people...
I think the new behaviour is what people want in most, if not all, cases. And 
WRAPDATELINE=YES is now more dedicated to the cases of geometries already in long/lat 
but that for some reasons have points with longitudes < 180 and > 180.

Even

> 
> https://github.com/OSGeo/gdal/blob/trunk/gdal/NEWS#L496
> 
> 
> On Wed, Apr 26, 2017 at 1:05 PM, Even Rouault <even.rouault at spatialys.com>
> 
> wrote:
> > Sean,
> > 
> > > I'd love to be able to build 2.2.0 on this slightly out of date
> > > compiler,
> > > 
> > > but if 2.2.0 will require C++11, I'll get with the program.
> > 
> > 2.2.0 doesn't rquire C++11
> > 
> > 
> > 
> > It seems that this compiler undefines the C99 isnan() macro in all cases
> > as soon as <cmath> is included.
> > 
> > 
> > 
> > Can you revert all the changes of your tree and apply the attached patch ?
> > 
> > 
> > 
> > --without-cpp11 will probably still be needed.
> > 
> > 
> > 
> > If that doesn't work, can you send the output of the following:
> > 
> > 
> > 
> > gcc -dM -E - < /dev/null
> > 
> > 
> > 
> > Even
> > 
> > 
> > 
> > --
> > 
> > Spatialys - Geospatial professional services
> > 
> > http://www.spatialys.com


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