[gdal-dev] Restoring functions removed in 2.5 beta1

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] Restoring functions removed in 2.5 beta1

Sean Gillies-3
Even and all,

The Fiona and Rasterio projects won't build with the pre-release because, for better or worse, they reference and use OSRFixup, which has been removed. I've filed issue #1466 about this.

Yes, we can add shims to Fiona and Rasterio so we can support versions 2.0-2.5, but this does nothing for software that's already installed on computers. If a no-op version of OSRFixup were restored to GDAL 2.5, these projects and previously installed versions of them would likely work just fine with 2.5.

I'd be happy to do the work, once I find the commit where the function was removed.

--
Sean Gillies

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Restoring functions removed in 2.5 beta1

Even Rouault-2
Sean,

>
> The Fiona and Rasterio projects won't build with the pre-release because,
> for better or worse, they reference and use OSRFixup, which has been
> removed. I've filed issue #1466 about this.
>
> Yes, we can add shims to Fiona and Rasterio so we can support versions
> 2.0-2.5, but this does nothing for software that's already installed on
> computers. If a no-op version of OSRFixup were restored to GDAL 2.5, these
> projects and previously installed versions of them would likely work just
> fine with 2.5.

I'm not so sure restoring the functions is enough. This might give a false
impression. More testing & other changes will generally be needed because of
all the revamp that has done in that area of SRS functionnality, like changes
in axis order.

The removal was also documented when RFC 73 was approved a few months ago
https://trac.osgeo.org/gdal/wiki/rfc73_proj6_wkt2_srsbarn

We could have perhaps actually called the version 3.0.

>
> I'd be happy to do the work, once I find the commit where the function was
> removed.

in mega-commit 8e5eeb35bf76390e3134a4ea7076dab7d478ea0e

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Restoring functions removed in 2.5 beta1

Sean Gillies-3
Hi Even,

On Sun, Apr 21, 2019 at 4:09 PM Even Rouault <[hidden email]> wrote:
Sean,

>
> The Fiona and Rasterio projects won't build with the pre-release because,
> for better or worse, they reference and use OSRFixup, which has been
> removed. I've filed issue #1466 about this.
>
> Yes, we can add shims to Fiona and Rasterio so we can support versions
> 2.0-2.5, but this does nothing for software that's already installed on
> computers. If a no-op version of OSRFixup were restored to GDAL 2.5, these
> projects and previously installed versions of them would likely work just
> fine with 2.5.

I'm not so sure restoring the functions is enough. This might give a false
impression. More testing & other changes will generally be needed because of
all the revamp that has done in that area of SRS functionnality, like changes
in axis order.

I had the impression from reading RFC 73 that the data-crs axes mapping concerns would be, with a few exceptions, internal to GDAL and OGR and that things would be unchanged for Rasterio and Fiona. Specifically, the intent is that OGR_G_GetX and OGR_G_GetY (used by Fiona: https://github.com/Toblerity/Fiona/blob/master/fiona/_geometry.pyx#L123) will by default return the same values in GIS-friendly order as in 2.4. Yes?

If that's not the intent or the reality, then I'll accept that 2.5 is practically a new major version and adjust accordingly.

I remain excited about the SRS enhancements and the centralization of features in PROJ and am looking forward to getting over the hump.
 

The removal was also documented when RFC 73 was approved a few months ago
https://trac.osgeo.org/gdal/wiki/rfc73_proj6_wkt2_srsbarn

We could have perhaps actually called the version 3.0.

>
> I'd be happy to do the work, once I find the commit where the function was
> removed.

in mega-commit 8e5eeb35bf76390e3134a4ea7076dab7d478ea0e

Even



--
Sean Gillies

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Restoring functions removed in 2.5 beta1

Even Rouault-2
On lundi 22 avril 2019 09:07:30 CEST Sean Gillies wrote:

> Hi Even,
>
> On Sun, Apr 21, 2019 at 4:09 PM Even Rouault <[hidden email]>
>
> wrote:
> > Sean,
> >
> > > The Fiona and Rasterio projects won't build with the pre-release
> > > because,
> > > for better or worse, they reference and use OSRFixup, which has been
> > > removed. I've filed issue #1466 about this.
> > >
> > > Yes, we can add shims to Fiona and Rasterio so we can support versions
> > > 2.0-2.5, but this does nothing for software that's already installed on
> > > computers. If a no-op version of OSRFixup were restored to GDAL 2.5,
> >
> > these
> >
> > > projects and previously installed versions of them would likely work
> > > just
> > > fine with 2.5.
> >
> > I'm not so sure restoring the functions is enough. This might give a false
> > impression. More testing & other changes will generally be needed because
> > of
> > all the revamp that has done in that area of SRS functionnality, like
> > changes
> > in axis order.
>
> I had the impression from reading RFC 73 that the data-crs axes mapping
> concerns would be, with a few exceptions, internal to GDAL and OGR and that
> things would be unchanged for Rasterio and Fiona. Specifically, the intent
> is that OGR_G_GetX and OGR_G_GetY (used by Fiona:
> https://github.com/Toblerity/Fiona/blob/master/fiona/_geometry.pyx#L123)
> will by default return the same values in GIS-friendly order as in 2.4. Yes?

Yes, retrieving geometries from drivers shouln't change.

But if you use the OGRCoordinateTransformation class with OGRSpatialReference
objects created from scratch, they will honour EPSG axis order by default (if
using EPSG based CRS).
I think you're just in that case with:
https://github.com/Toblerity/Fiona/blob/master/fiona/_transform.pyx
To get previous behaviour you'll need to call
OSRSetAxisMappingStrategy(hSRS, OAMS_TRADITIONAL_GIS_ORDER) on the SRS object
you've created.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev