[gdal-dev] report proj4 version to which gdal is linked?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] report proj4 version to which gdal is linked?

Roger Bivand
I've looked in ogr/ogrct.cpp, but cannot see that the proj4 version that is
detected internally is exposed for reporting through a function in the API.
It would be convenient if GDAL could report versions of some of its
dependencies. Checks for GDAL built with or without GEOS are now in R sf and
rgdal packages, because some drivers behave differently if GDAL was built
with or without GEOS (but not the GEOS version, which may matter for static
builds), We'd like to report the proj4 version used to build GDAL too, and
would value advice. This will become critical shortly, with the forthcoming
release of proj4 5.0.0, which uses a different API. There is going to be a
lot of muddle, so being able to check will be helpful for many. Should I
file a trac request?

Roger



-----
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: report proj4 version to which gdal is linked?

Even Rouault-2

On vendredi 24 novembre 2017 02:37:11 CET Roger Bivand wrote:

> I've looked in ogr/ogrct.cpp, but cannot see that the proj4 version that is

> detected internally is exposed for reporting through a function in the API.

> It would be convenient if GDAL could report versions of some of its

> dependencies. Checks for GDAL built with or without GEOS are now in R sf and

> rgdal packages, because some drivers behave differently if GDAL was built

> with or without GEOS (but not the GEOS version, which may matter for static

> builds), We'd like to report the proj4 version used to build GDAL too, and

> would value advice. This will become critical shortly, with the forthcoming

> release of proj4 5.0.0, which uses a different API. There is going to be a

> lot of muddle, so being able to check will be helpful for many.

 

There are 2 different notions :

- the proj version used at compile time

- the proj version used at link time

 

proj 4.X only offers the PJ_VERSION macro, so you can only detect the compile time version.

 

GDAL has currently 2 modes to support proj:

- classic mode where you build against proj headers and link the GDAL shared object against the proj shared object at build time. In that mode, currently,we could potentially report PJ_VERSION

- full dynamic mode where there's no build requirement and at runtime you dlopen proj. In that mode, currently, it is really hard to know which proj version we end up linking against (you can make some guess depending on which symbols are available...)

 

proj 5 will have compile time PROJ_VERSION_ macros, and a proj_info() function giving the version at runtime.

 

A few months before, I proposed to drop the support for the "full dynamic mode" as it makes code messy. This didn't make concensus at that time, so I dropped the ball for now. But for proj 5 support, I think we really need to get rid of the full dynamic mode.

 

If proj 5 still supports the old proj_api.h (which seems to be the direction), as soon as it will be released, we could probably make proj 5 the minimum version for a proj-enabled GDAL build (since other components of the ecosystem depending on proj 4 API will still work), so as to avoid supporting 2 different APIs. Well, maybe this is a bold move, and perhaps still supporting proj 4 classic mode will not be that hard, but I definitly don't want to have to support "proj 4 classic mode" + "proj 4 full dynamic mode" + "proj 5 classic mode".

 

> Should I

> file a trac request?

 

You may

 

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: report proj4 version to which gdal is linked?

Roger Bivand
On Fri, 24 Nov 2017, Even Rouault wrote:

> On vendredi 24 novembre 2017 02:37:11 CET Roger Bivand wrote:
>> I've looked in ogr/ogrct.cpp, but cannot see that the proj4 version that is
>> detected internally is exposed for reporting through a function in the API.
>> It would be convenient if GDAL could report versions of some of its
>> dependencies. Checks for GDAL built with or without GEOS are now in R sf and
>> rgdal packages, because some drivers behave differently if GDAL was built
>> with or without GEOS (but not the GEOS version, which may matter for static
>> builds), We'd like to report the proj4 version used to build GDAL too, and
>> would value advice. This will become critical shortly, with the forthcoming
>> release of proj4 5.0.0, which uses a different API. There is going to be a
>> lot of muddle, so being able to check will be helpful for many.
>
> There are 2 different notions :
> - the proj version used at compile time
> - the proj version used at link time
>
> proj 4.X only offers the PJ_VERSION macro, so you can only detect the
> compile time version.

In rgdal, we use:

#include <proj_api.h>

SEXP
PROJ4VersionInfo(void) {
     SEXP ans;

     PROTECT(ans=NEW_LIST(2));
     SET_VECTOR_ELT(ans, 0, NEW_CHARACTER(1));
     SET_VECTOR_ELT(ans, 1, NEW_INTEGER(1));
     SET_STRING_ELT(VECTOR_ELT(ans, 0), 0,
         COPY_TO_USER_STRING(pj_get_release()));
     INTEGER_POINTER(VECTOR_ELT(ans, 1))[0] = PJ_VERSION;

     UNPROTECT(1);

     return(ans);
}

to get both the declaration in proj_api.h and the one in pj_release.c
(because they have differed). I would have (perhaps) hoped that
pj_release.c is the runtime version, but mileage may vary ...

>
> GDAL has currently 2 modes to support proj:
> - classic mode where you build against proj headers and link the GDAL
> shared object against the proj shared object at build time. In that
> mode, currently,we could potentially report PJ_VERSION

That would help.

> - full dynamic mode where there's no build requirement and at runtime
> you dlopen proj. In that mode, currently, it is really hard to know
> which proj version we end up linking against (you can make some guess
> depending on which symbols are available...)
>

or maybe create a pointer to pj_get_release()?

> proj 5 will have compile time PROJ_VERSION_ macros, and a proj_info()
> function giving the version at runtime.
>
> A few months before, I proposed to drop the support for the "full
> dynamic mode" as it makes code messy. This didn't make concensus at that
> time, so I dropped the ball for now. But for proj 5 support, I think we
> really need to get rid of the full dynamic mode.
>
> If proj 5 still supports the old proj_api.h (which seems to be the
> direction), as soon as it will be released, we could probably make proj
> 5 the minimum version for a proj-enabled GDAL build (since other
> components of the ecosystem depending on proj 4 API will still work), so
> as to avoid supporting 2 different APIs. Well, maybe this is a bold
> move, and perhaps still supporting proj 4 classic mode will not be that
> hard, but I definitly don't want to have to support "proj 4 classic
> mode" + "proj 4 full dynamic mode" + "proj 5 classic mode".

Yes, too many modes is misuse of limited time, and the speed of (overdue
?) changes in proj4 suggests that this is wise, also in relation to the
downstream applications and packaging communities. It would be unfortunate
if major platforms remained stuck with poorly supported versions of proj4.

>
>> Should I file a trac request?
>
> You may

Thanks, I'll see what I can do with this.

Roger

>
> Even
>
>

--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: report proj4 version to which gdal is linked?

Even Rouault-2

> I would have (perhaps) hoped that

> pj_release.c is the runtime version, but mileage may vary ...

 

It is. I just missed pj_get_release()

 

--

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: report proj4 version to which gdal is linked?

Roger Bivand
On Fri, 24 Nov 2017, Even Rouault wrote:

>> I would have (perhaps) hoped that
>> pj_release.c is the runtime version, but mileage may
> vary ...
>
> It is. I just missed pj_get_release()
>

Thanks, I guess you can see a resoluion. Which gdal header is the most
logical to expose this in?

It's a bit fragile, because the string is entered manually, rather than
coming from "above" in the build tree, but at least is there. Making sure
programatically that proj knows itself what its version is whould simplify
things a lot.

Roger

>

--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: report proj4 version to which gdal is linked?

Even Rouault-2

On vendredi 24 novembre 2017 22:19:08 CET Roger Bivand wrote:

> On Fri, 24 Nov 2017, Even Rouault wrote:

> >> I would have (perhaps) hoped that

> >> pj_release.c is the runtime version, but mileage may

> >

> > vary ...

> >

> > It is. I just missed pj_get_release()

>

> Thanks, I guess you can see a resoluion. Which gdal header is the most

> logical to expose this in?

 

Would probably makes sense to add the version found at build time in

GDALVersionInfo("BUILD_INFO") in

https://github.com/OSGeo/gdal/blob/trunk/gdal/gcore/gdal_misc.cpp#L2099

 

PROJ_VERSION=x.y.z\n

 

and have a similar GDALVersionInfo("RUNTIME_INFO") for the version found at runtime (pj_get_release() / proj_info())

 

PROJ_VERSION=x.y.z\n

 

 

--

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: report proj4 version to which gdal is linked?

Roger Bivand
On Fri, 24 Nov 2017, Even Rouault wrote:

> On vendredi 24 novembre 2017 22:19:08 CET Roger Bivand wrote:
>> On Fri, 24 Nov 2017, Even Rouault wrote:
>>>> I would have (perhaps) hoped that
>>>> pj_release.c is the runtime version, but mileage may
>>>
>>> vary ...
>>>
>>> It is. I just missed pj_get_release()
>>
>> Thanks, I guess you can see a resoluion. Which gdal header is the most
>> logical to expose this in?
>
> Would probably makes sense to add the version found at build time in
> GDALVersionInfo("BUILD_INFO") in
> https://github.com/OSGeo/gdal/blob/trunk/gdal/gcore/gdal_misc.cpp#L2099
>
> PROJ_VERSION=x.y.z\n
>
> and have a similar GDALVersionInfo("RUNTIME_INFO") for the version found at runtime
> (pj_get_release() / proj_info())
>
> PROJ_VERSION=x.y.z\n
>

Thanks, that would match nicely, as rgdal already has bindings for
GDALVersionInfo() but only uses "--version" and "VERSION_NUM" so far; our
test for GDAL built with GEOS tests a fake union to detect success or
failure.

Roger

>
>

--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: report proj4 version to which gdal is linked?

Even Rouault-2

 

> Thanks, that would match nicely, as rgdal already has bindings for

> GDALVersionInfo() but only uses "--version" and "VERSION_NUM" so far; our

> test for GDAL built with GEOS tests a fake union to detect success or

> failure.

 

Was available through the C++ API with OGRGeometryFactory::haveGEOS() but I've now exposed it in GDALVersionInfo("BUILD_INFO") per

https://trac.osgeo.org/gdal/changeset/40832

 

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: report proj4 version to which gdal is linked?

Edzer Pebesma-2


On 11/25/2017 02:47 PM, Even Rouault wrote:

>  
>
>> Thanks, that would match nicely, as rgdal already has bindings for
>
>> GDALVersionInfo() but only uses "--version" and "VERSION_NUM" so far; our
>
>> test for GDAL built with GEOS tests a fake union to detect success or
>
>> failure.
>
>  
>
> Was available through the C++ API with OGRGeometryFactory::haveGEOS()

On the system I work on (Ubuntu 17.04 with ubuntugis-unstable GDAL),
haveGEOS() seems unreliable (giving false, where it is true).

The runtime check R packages rgdal and sf use is simply trying out a
Union: https://github.com/r-spatial/sf/blob/master/src/gdal.cpp#L422-L437

> but I've now exposed it in GDALVersionInfo("BUILD_INFO") per
>
> https://trac.osgeo.org/gdal/changeset/40832
>
>  
>
> Even
>
>  
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
>
>
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>

--
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48151 Muenster, Germany
Phone: +49 251 8333081
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: report proj4 version to which gdal is linked?

Edzer Pebesma-2


On 11/25/2017 05:49 PM, Edzer Pebesma wrote:
> On the system I work on (Ubuntu 17.04 with ubuntugis-unstable GDAL),
> haveGEOS() seems unreliable (giving false, where it is true).

I'm sorry, that was a wrong diagnosis of a self-caused problem.
--
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48151 Muenster, Germany
Phone: +49 251 8333081
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev