[gdal-dev] RFC 73 (aka gdalsrsbarn) available for review

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

[gdal-dev] RFC 73 (aka gdalsrsbarn) available for review

Even Rouault-2
Hi,

RFC 73 "Integration of PROJ6 for WKT2, late binding capabilities, time-support
and unified CRS database" is available for your review at:

https://trac.osgeo.org/gdal/wiki/rfc73_proj6_wkt2_srsbarn

The proposed implementation is at:
https://github.com/OSGeo/gdal/pull/1185

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: RFC 73 (aka gdalsrsbarn) available for review

Even Rouault-2
On mercredi 9 janvier 2019 16:23:44 CET Even Rouault wrote:
> Hi,
>
> RFC 73 "Integration of PROJ6 for WKT2, late binding capabilities,
> time-support and unified CRS database" is available for your review at:
>
> https://trac.osgeo.org/gdal/wiki/rfc73_proj6_wkt2_srsbarn
>

No remarks ? Do people need a bit more time to review ?

Actually I have a question on which I'd like to get some feedback. In the
current state of the work, gdalinfo and ogrinfo will display the SRS in WKT1
when possible (consequence of "OGRSpatialReference::exportToWkt() without
options will report WKT 1 for CRS compatibles of this representation, and
otherwise use WKT 2:2015 (typically for Geographic 3D CRS)" mentionned in
"Default WKT version").
I was wondering if we couldn't default to WKT2:2015 in all cases for those
utilities. One small benefit of this is that for SRS built from EPSG code, the
WKT would include the area of use, which makes it easier to locate things.,
like

PROJCRS["RT38 5 gon O",
    BASEGEODCRS["RT38",
        DATUM["Stockholm 1938",
            ELLIPSOID["Bessel 1841",6377397.155,299.1528128,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]]],
    CONVERSION["Sweden zone 5 gon O",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",22.5582777777778,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",1,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",1500000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["northing (X)",north,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["easting (Y)",east,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    AREA["Sweden - 5 gon E"],
    BBOX[65.24,21.34,68.58,24.17],
    ID["EPSG",3030]]
       
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: RFC 73 (aka gdalsrsbarn) available for review

Even Rouault-2
On lundi 14 janvier 2019 12:42:08 CET Even Rouault wrote:
> On mercredi 9 janvier 2019 16:23:44 CET Even Rouault wrote:
> > Hi,
> >
> > RFC 73 "Integration of PROJ6 for WKT2, late binding capabilities,
> > time-support and unified CRS database" is available for your review at:
> >
> > https://trac.osgeo.org/gdal/wiki/rfc73_proj6_wkt2_srsbarn
>
> No remarks ? Do people need a bit more time to review ?

I intend to submit it to voting beginning of next week. Last chance for
expressing your remarks.

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: RFC 73 (aka gdalsrsbarn) available for review

andrew.bell.ia@gmail.com
What is the logic behind the PROJ symbol renaming?  I remember terrible things about previous symbol renaming efforts.  Is the expectation that PROJ will be statically linked in GDAL for some reason?

On Thu, Jan 17, 2019 at 1:27 PM Even Rouault <[hidden email]> wrote:
On lundi 14 janvier 2019 12:42:08 CET Even Rouault wrote:
> On mercredi 9 janvier 2019 16:23:44 CET Even Rouault wrote:
> > Hi,
> >
> > RFC 73 "Integration of PROJ6 for WKT2, late binding capabilities,
> > time-support and unified CRS database" is available for your review at:
> >
> > https://trac.osgeo.org/gdal/wiki/rfc73_proj6_wkt2_srsbarn
>
> No remarks ? Do people need a bit more time to review ?

I intend to submit it to voting beginning of next week. Last chance for
expressing your remarks.

Even

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


--
Andrew Bell
[hidden email]

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

Re: RFC 73 (aka gdalsrsbarn) available for review

Even Rouault-2
On jeudi 17 janvier 2019 13:45:27 CET Andrew Bell wrote:
> What is the logic behind the PROJ symbol renaming?

First, it is purely optional and require active decision of the user to build
PROJ that way. This is only meant to be used by people wanting to mix GDAL
master + PROJ master + GDAL dependencies built with against old PROJ version.
This is useful in particular for CI purposes where I want to be able to pull
GDAL dependencies built against PROJ 4.9.x.
This is meant at managing the transition before all the stack is built against
PROJ 6

> I remember terrible
> things about previous symbol renaming efforts.

Really ? Well, they eventually "solved" quite severe issues during the libtiff
3 -> 4 transition.

> Is the expectation that
> PROJ will be statically linked in GDAL for some reason?

No

--
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: RFC 73 (aka gdalsrsbarn) available for review

andrew.bell.ia@gmail.com

On Thu, Jan 17, 2019 at 2:09 PM Even Rouault <[hidden email]> wrote:
On jeudi 17 janvier 2019 13:45:27 CET Andrew Bell wrote:
> What is the logic behind the PROJ symbol renaming?

First, it is purely optional and require active decision of the user to build
PROJ that way. This is only meant to be used by people wanting to mix GDAL
master + PROJ master + GDAL dependencies built with against old PROJ version.
This is useful in particular for CI purposes where I want to be able to pull
GDAL dependencies built against PROJ 4.9.x.
This is meant at managing the transition before all the stack is built against
PROJ 6

I guess this just sounds like a development/test issue rather than something that should be exposed for users.

> I remember terrible
> things about previous symbol renaming efforts.

Really ? Well, they eventually "solved" quite severe issues during the libtiff
3 -> 4 transition.

I remember hitting a GDAL with statically-linked libtiff that had renamed symbols or some such.  It caused problems.

--
Andrew Bell
[hidden email]

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

Re: RFC 73 (aka gdalsrsbarn) available for review

Even Rouault-2
> I guess this just sounds like a development/test issue rather than
> something that should be exposed for users.

Mostly. But I can imagine it can be also useful for people tracking GDAL
master in production, but not wanting to rebuild their whole GIS stack. Beyond
time and pain to do it, updating to PROJ 6 will break a number of existing
packages whose it is a dependency, and which are not necessarily ready yet for
PROJ 6. Thus this solution enables early testing and use of GDAL master.
That's what one of the use cases I had in mind when developing this.

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