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

classic Classic list List threaded Threaded
13 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
Reply | Threaded
Open this post in threaded view
|

Re: RFC 73 (aka gdalsrsbarn) available for review

Markus Metz-3
In reply to this post by Even Rouault-2


On Thu, Jan 17, 2019 at 7: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.

Regarding WKT2, a remark from a GRASS GIS developer being a user of GDAL/PROJ:

I understand that WKT2 is long overdue and thus should be pushed as much and as early as possible. Otherwise it would take a long time and a rather long and painful transition process to switch to WKT2. My suggestion is to try to keep the painful transition process as short as possible and switch to WKT2 ASAP. People like to stick to what they have and what they know, so if something better is available, some convincing is needed.

Backwards compatibility wrt reading WKT1 needs to be maintained because already existing datasets must still be readable.

Regarding the BBOX, it should be made clear that the reported extents are a suggestion, not a limitation.

Markus

_______________________________________________
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
Hi Markus,

Thanks for your feedback

> Regarding WKT2, a remark from a GRASS GIS developer being a user of
> GDAL/PROJ:
>
> I understand that WKT2 is long overdue and thus should be pushed as much
> and as early as possible. Otherwise it would take a long time and a rather
> long and painful transition process to switch to WKT2. My suggestion is to
> try to keep the painful transition process as short as possible and switch
> to WKT2 ASAP. People like to stick to what they have and what they know, so
> if something better is available, some convincing is needed.

So you would be in favor of making OSRExportToWkt() default to WKT2 ?
(probably WKT2:2018 while we are at it ? Not just the output of gdalinfo /
ogrinfo utilities.
I was shy in doing so, because it will likely require updating a good deal of
GDAL autotests, but oh well...

What annoys me a bit more is the case of XML files like GDAL VRT, OGR VRT or
.aux.xml that contains serialized SRS and that I wanted to be backward
compatible with older GDAL versions as much as possible.

>
> Backwards compatibility wrt reading WKT1 needs to be maintained because
> already existing datasets must still be readable.

Yes this is of course done. Export to older WKT versions will likely still be
needed for some formats too

> Regarding the BBOX, it should be made clear that the reported extents are a
> suggestion, not a limitation.

The semantics is a bit fuzzy. The WKT standard mentions "Extent describes the
spatial and/or temporal applicability of a CRS, datum, datum ensemble,
coordinate operation or Bound CRS". For a CRS, you can go beyond depending on
the numeric stability of the implementation of the projection method (in case
of a projected CRS). For a coordinate operation, if it involves a grid, the
BBOX should be interpreted in a rather strict way (that's what PROJ master
does internally when computing the most appropriate coordinate transformation
given all the constraints it is given)

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

Markus Metz-3


On Tue, Jan 22, 2019 at 10:30 PM Even Rouault <[hidden email]> wrote:

>
> Hi Markus,
>
> Thanks for your feedback
>
> > Regarding WKT2, a remark from a GRASS GIS developer being a user of
> > GDAL/PROJ:
> >
> > I understand that WKT2 is long overdue and thus should be pushed as much
> > and as early as possible. Otherwise it would take a long time and a rather
> > long and painful transition process to switch to WKT2. My suggestion is to
> > try to keep the painful transition process as short as possible and switch
> > to WKT2 ASAP. People like to stick to what they have and what they know, so
> > if something better is available, some convincing is needed.
>
> So you would be in favor of making OSRExportToWkt() default to WKT2 ?
> (probably WKT2:2018 while we are at it ? Not just the output of gdalinfo /
> ogrinfo utilities.

Yes, no half-hearted changes, make WKT2 the default wherever possible.

> I was shy in doing so, because it will likely require updating a good deal of
> GDAL autotests, but oh well...

These tests need to be updated at some stage anyway, when WKT2 becomes the default. OTOH, it is also a question of balancing the workload for the developer(s)...
>
> What annoys me a bit more is the case of XML files like GDAL VRT, OGR VRT or
> .aux.xml that contains serialized SRS and that I wanted to be backward
> compatible with older GDAL versions as much as possible.

I guess for the time being there needs to be a switch to select WKT1 or WKT2. With WKT2 being the default, some backward compatibility switch for WKT1 would be needed. You have already described "an enhanced version of exportToWkt() [that] accepts options to specify the exact WKT version used, ...". Maybe a generic config option would help users to switch back to WKT1?
>

> > Regarding the BBOX, it should be made clear that the reported extents are a
> > suggestion, not a limitation.
>
> The semantics is a bit fuzzy. The WKT standard mentions "Extent describes the
> spatial and/or temporal applicability of a CRS, datum, datum ensemble,
> coordinate operation or Bound CRS". For a CRS, you can go beyond depending on
> the numeric stability of the implementation of the projection method (in case
> of a projected CRS). For a coordinate operation, if it involves a grid, the
> BBOX should be interpreted in a rather strict way (that's what PROJ master
> does internally when computing the most appropriate coordinate transformation
> given all the constraints it is given)

The "fuzziness" seems appropriate since numeric instability is usually occurring gradually and not suddenly when you leave the BBOX. Regarding grids, a strict interpretation makes sense AFAICT. For CRS, users must decide (as they already do) about the risk of numeric instability. For example, Germany is covered by two UTM zones, but even official datasets are happily mapped country-wide into one UTM zone, with the definition of a UTM zone being pretty clear. Maybe with the help of a suggested BBOX users become more aware that a selected CRS is not the best choice.

Markus


_______________________________________________
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
In reply to this post by Even Rouault-2
On vendredi 25 janvier 2019 11:59:55 CET Sean Gillies wrote:
> Hi Even,
>
> What will the impact be on spatial referencing stored in new datasets? For
> example, will users with GDAL 2.5 run gdal_translate and write WKT2 into a
> GeoTIFF, thereby creating data that can't be opened using GDAL 2.4?
>

Hi Sean,

re-adding the list, as it is of general interest.

GeoTIFF doesn't use WKT internally ([1]), so this will have no impact, and
datasets should be interoperable between GDAL < or >= 2.5. More generally,
after exchanges with a few people, I've decided not to change the global
behaviour of the exportToWKT() method: it will still export WKT1 for now. So
the formats that currently rely on WKT to store their SRS (including GDAL and
OGR .vrt, .aux.xml side car) will be little impacted ([2]). In a few years
when GDAL >= 2.5 is more widespread, we might reconsider this choice.

I've reflected those changes in:
https://trac.osgeo.org/gdal/wiki/rfc73_proj6_wkt2_srsbarn?
action=diff&version=5&old_version=4

Command line utilities gdalinfo, ogrinfo and gdalsrsinfo will report WKT2 by
default however as a hint that things have changed. gdalinfo and ogrinfo will
gain a "-wkt_format wkt1" switch to fallback to current behaviour. gdalsrsinfo
has already a switch to select the WKT variant), as this should have less
impact.

Even

[1] Except as an extension of a few SRS that can't be encoded with GeoTIFF
keys. In that case, GDAL uses a ESRI specific trick that consists in exporting
the SRS as a ESRI WKT1 string. That behaviour will be unchanged.

[2] I write "little" and not "not" on purpose since the WKT1 export will not
be strictly identical to previous versions. In particular AXIS, compliant with
the ordering of the defining authority, will be output

--
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

Darafei "Komяpa" Praliaskouski
In reply to this post by Even Rouault-2
Hello,

I would like to learn more about geographic 3D CRS. There is ad-hoc solution in PostGIS ("geography") to handle 3D geographies, and I would like to learn about alternative ways of signaling that calculations are to be done on curved surface.

On Wed, Jan 9, 2019 at 6:23 PM Even Rouault <[hidden email]> 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

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


--
Darafei Praliaskouski

_______________________________________________
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
Darafei,

A Geographic 3D CRS is a CRS, that is based on a geodetic reference frame
(geodetic datum), and has a coordinate system with 3 axis: latitude, longitude
and ellipsoidal height. For example EPSG:4979 is the code for the Geographic
3D CRS corresponding to "WGS 84" (EPSG:4326 is the corresponding Geographic 2D
CRS).

This is what is described in OGC 08-015r2 "Abstract Specification Topic 2
Spatial referencing by coordinates"
https://portal.opengeospatial.org/files/?artifact_id=39049 
in "B.1.2.1 Principal subtypes of coordinate reference system" a) under the
older term of "geodetic CRS using 3D ellipsoidal coodinates".
The newer revision of this document (expected for public release in the next
weeks/months) will use the term "geographic 3D CRS".

Even

> Hello,
>
> I would like to learn more about geographic 3D CRS. There is ad-hoc
> solution in PostGIS ("geography") to handle 3D geographies, and I would
> like to learn about alternative ways of signaling that calculations are to
> be done on curved surface.
>
> On Wed, Jan 9, 2019 at 6:23 PM Even Rouault <[hidden email]>
>
> 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
> >
> > 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


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