[gdal-dev] GDAL 2.5.0 beta1 available

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

[gdal-dev] GDAL 2.5.0 beta1 available

Even Rouault-2
Hi,

I have prepared the GDAL/OGR 2.5.0 Beta 1 release.  It will hopefully directly
followed by a RC1 next week if things go well.

GDAL 2.5.0 *requires* PROJ >= 6.0, and if using external libgeotiff,
libgeotiff >= 1.5.0
In case you didn't follow recent developments, a revamp has been done in the
area of coordinate reference systems, which may impact downstream users & code
of GDAL. Consult
https://github.com/OSGeo/gdal/blob/master/gdal/MIGRATION_GUIDE.TXT
and
https://trac.osgeo.org/gdal/wiki/rfc73_proj6_wkt2_srsbarn

The source is available at:

    http://download.osgeo.org/gdal/2.5.0/gdal-2.5.0beta1.tar.xz
    http://download.osgeo.org/gdal/2.5.0/gdal-2.5.0beta1.tar.gz
    http://download.osgeo.org/gdal/2.5.0/gdal250beta1.zip

A snapshot of the Python autotest suite can be downloaded from:

    http://download.osgeo.org/gdal/2.5.0/gdalautotest-2.5.0beta1.tar.gz
    http://download.osgeo.org/gdal/2.5.0/gdalautotest-2.5.0beta1.zip

The GRASS plugin is available at

    http://download.osgeo.org/gdal/2.5.0/gdal-grass-2.5.0beta1.tar.gz

The NEWS is available at :
      https://raw.githubusercontent.com/OSGeo/gdal/master/gdal/NEWS

New bugs found should be filed in GitHub.

GDAL developers and users are encouraged to treat the next week as the prime
time for bug finding and fixing.

I have not yet created the release/2.5 branch from current master, so be
careful of what you commit in master.

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: GDAL 2.5.0 beta1 available

Greg Troxel-2
Even Rouault <[hidden email]> writes:

> GDAL 2.5.0 *requires* PROJ >= 6.0, and if using external libgeotiff,

I would expect then that packaging systems will hold off on this,
because I don't think we've reached the point that the collateral damage
of upgrading proj to 6 is ok.

With any luck I'm wrong and most of the proj-using packages have had a
release that works on 6, but it seems that there are a lot of packages
not yet able to cope.

(Which is all fine; packaging systems can stay on 2.4.x for a while.)


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

Re: GDAL 2.5.0 beta1 available

Sebastiaan Couwenberg
On 4/19/19 4:08 PM, Greg Troxel wrote:

> Even Rouault <[hidden email]> writes:
>> GDAL 2.5.0 *requires* PROJ >= 6.0, and if using external libgeotiff,
>
> I would expect then that packaging systems will hold off on this,
> because I don't think we've reached the point that the collateral damage
> of upgrading proj to 6 is ok.
>
> With any luck I'm wrong and most of the proj-using packages have had a
> release that works on 6, but it seems that there are a lot of packages
> not yet able to cope.

It's not as bad as it seems. If you set the accept deprecation flag,
most packages that still use proj_api.h build successfully with PROJ 6.

See: https://lists.debian.org/debian-gis/2019/04/msg00004.html
(and the follow-ups)

The ones that still use projects.h are somewhat hopeless, they tend to
be dead upstream, so are candidates for removal.

The biggest concerns are cartopy, R sf & lwgeom, SAGA, and VTK. I've
seen no progress for the R packages, nor anything tangible for VTK
(although it can be built with its embedded copy of libproj4 3.2).

The cartopy test failures may be (partially) fixed with PROJ 6.1.0 like
the test failures with the RDNAP datumgrid, but I expect more changes
will be required to get all tests to pass.

Once the SAGA changes are available in a future release, it will likely
not be compatible with QGIS, but such is the fate of processing modules.
I stopped caring about anything other that GRASS when it comes to QGIS,
and even for GRASS I'll drop the support when it breaks.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: GDAL 2.5.0 beta1 available

Even Rouault-2
In reply to this post by Greg Troxel-2
Greg,

> I would expect then that packaging systems will hold off on this,
> because I don't think we've reached the point that the collateral damage
> of upgrading proj to 6 is ok.

Packaging systems with an experimental staging area should be able to package
it hopefully, and add it to the other packages supporting PROJ 6 already.

>
> With any luck I'm wrong and most of the proj-using packages have had a
> release that works on 6, but it seems that there are a lot of packages
> not yet able to cope.

I understand your concern, but what would have be supposed to do: wait for
others to upgrade to PROJ 6 as well and defer until they did :-) ?
We're tracing the road away by adopting PROJ 6 too. Projects which don't
follow the trend are doomed to be left aside ultimately.

Sorry, supporting older PROJ versions wasn't really wishable from a GDAL
maintainability point of view. What happened is a deep change. A lot of code
has been """moved"""" to PROJ: instanciation of CRS from the EPSG database,
WKT1 support, ESRI WKT support and PROJ string import/export. Actually, all
that code has been deleted from GDAL and rewritten in a completely different
way in PROJ. Supporting older PROJ versions in GDAL 2.5 would mean maintaining
a lot of ancient code, that behaves in subtle different ways. Would be a mess
to have the test suite working in both mode, etc. GDAL is a complicated and
big enough beast like it is already.

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: GDAL 2.5.0 beta1 available

Greg Troxel-2
Even Rouault <[hidden email]> writes:

>> I would expect then that packaging systems will hold off on this,
>> because I don't think we've reached the point that the collateral damage
>> of upgrading proj to 6 is ok.
>
> Packaging systems with an experimental staging area should be able to package
> it hopefully, and add it to the other packages supporting PROJ 6 already.

True, but that's separate from what is in the mainstream distribution.

>> With any luck I'm wrong and most of the proj-using packages have had a
>> release that works on 6, but it seems that there are a lot of packages
>> not yet able to cope.
>
> I understand your concern, but what would have be supposed to do: wait for
> others to upgrade to PROJ 6 as well and defer until they did :-) ?
> We're tracing the road away by adopting PROJ 6 too. Projects which don't
> follow the trend are doomed to be left aside ultimately.
>
> Sorry, supporting older PROJ versions wasn't really wishable from a GDAL
> maintainability point of view. What happened is a deep change. A lot of code
> has been """moved"""" to PROJ: instanciation of CRS from the EPSG database,
> WKT1 support, ESRI WKT support and PROJ string import/export. Actually, all
> that code has been deleted from GDAL and rewritten in a completely different
> way in PROJ. Supporting older PROJ versions in GDAL 2.5 would mean maintaining
> a lot of ancient code, that behaves in subtle different ways. Would be a mess
> to have the test suite working in both mode, etc. GDAL is a complicated and
> big enough beast like it is already.

I can certainly see your point that supporting 5 and 6 in the same
release is too much.  I didn't really mean to sound like "you should not
have done this".  I was just trying to point out that the 6-only status
of 2.5.0 is likely going to lead to quite delayed adoption in packaging
systems.

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

Re: GDAL 2.5.0 beta1 available

Sebastiaan Couwenberg
On 4/19/19 4:40 PM, Greg Troxel wrote:
> I was just trying to point out that the 6-only status
> of 2.5.0 is likely going to lead to quite delayed adoption in packaging
> systems.

Can you share an overview of the PROJ 6 status in NetBSD?

Since NetBSD doesn't have most of the problematic packages or hasn't
patched them as heavily as in Debian, I think that you should be able to
move to PROJ 6 much sooner than other distributions.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: GDAL 2.5.0 beta1 available

Even Rouault-2
In reply to this post by Even Rouault-2
On vendredi 19 avril 2019 07:42:31 CEST Simon Eves wrote:
> Does this mean there won’t be a 2.4.2?

I'll issuing a few extra 2.4.x maintenance bugfix releases this year, but this
is a courtesy that will eventually stop.

People needing longer support, and potentially backport of features in the 2.4
series, are free to contact their favorite service provider.

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: GDAL 2.5.0 beta1 available

Edzer Pebesma-2
In reply to this post by Sebastiaan Couwenberg


On 4/19/19 4:22 PM, Sebastiaan Couwenberg wrote:
> The biggest concerns are cartopy, R sf & lwgeom, SAGA, and VTK. I've
> seen no progress for the R packages, nor anything tangible for VTK
> (although it can be built with its embedded copy of libproj4 3.2).

Thanks - the R packages sf, lwgeom and rgdal have been updated; github
versions work, we'll be submitting CRAN version in the next few days.

I updated the wiki status pages.
--
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

pEpkey.asc (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GDAL 2.5.0 beta1 available

James Klassen-2
In reply to this post by Even Rouault-2
On 4/19/19 9:52 AM, Even Rouault wrote:

> On vendredi 19 avril 2019 07:42:31 CEST Simon Eves wrote:
>> Does this mean there won’t be a 2.4.2?
> I'll issuing a few extra 2.4.x maintenance bugfix releases this year, but this
> is a courtesy that will eventually stop.
>
> People needing longer support, and potentially backport of features in the 2.4
> series, are free to contact their favorite service provider.
>
> Even
>
Just curious, there seems to be an implicit assumption that proj4/5 and
proj6 (or GDAL 2.4 and 2.5 for that matter) can't be installed side by
side.  Why is that? Shouldn't they have different .so major versions? 
Then wouldn't applications that haven't been updated yet continue to
function with the Proj/GDAL version they were built against?

I understand this is a little messy for awhile, but why would this
fundamentally be any different than a distro packaging multiple OpenSSL
versions or Qt versions to keep all the applications happy?

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

Re: GDAL 2.5.0 beta1 available

Even Rouault-2
On vendredi 19 avril 2019 14:31:17 CEST Jim Klassen wrote:

> On 4/19/19 9:52 AM, Even Rouault wrote:
> > On vendredi 19 avril 2019 07:42:31 CEST Simon Eves wrote:
> >> Does this mean there won’t be a 2.4.2?
> >
> > I'll issuing a few extra 2.4.x maintenance bugfix releases this year, but
> > this is a courtesy that will eventually stop.
> >
> > People needing longer support, and potentially backport of features in the
> > 2.4 series, are free to contact their favorite service provider.
> >
> > Even
>
> Just curious, there seems to be an implicit assumption that proj4/5 and
> proj6 (or GDAL 2.4 and 2.5 for that matter) can't be installed side by
> side.  Why is that? Shouldn't they have different .so major versions?

Most binary distributions only ship one version, for conveniency/reduced work
load/etc., but yes you can use as many PROJ + GDAL versions in different
locations of your system of course

What becomes messy is when you have quasi-diamond situations like :

A depends on B on C
B depends on PROJ < 6
C depends on PROJ >= 6

Things are bound to explode at runtime due to symbol clashes.
Except that for the sake of my own development needs I was in that situation
so you can use that trick:
https://trac.osgeo.org/gdal/wiki/BuildingOnUnixGDAL25dev

--
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: GDAL 2.5.0 beta1 available

Sebastiaan Couwenberg
In reply to this post by James Klassen-2
On 4/19/19 9:31 PM, Jim Klassen wrote:
> Shouldn't they have different .so major versions?

They do:

 * PROJ
   4.9.3: SOVERSION 12
   5.0.0: SOVERSION 13
   5.1.0: SOVERSION 14
   6.0.0: SOVERSION 15

 * libgeotiff
   1.4.3: SOVERSION 2
   1.5.0: SOVERSION 5

 * libgdal
   2.4.0: SOVERSION 20
   2.5.0: SOVERSION 26

See also:

 https://abi-laboratory.pro/index.php?view=timeline&l=proj
 https://abi-laboratory.pro/index.php?view=timeline&l=gdal
 https://abi-laboratory.pro/index.php?view=timeline&l=libgeotiff

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: GDAL 2.5.0 beta1 available

Greg Troxel-2
In reply to this post by Sebastiaan Couwenberg
Sebastiaan Couwenberg <[hidden email]> writes:

> On 4/19/19 4:40 PM, Greg Troxel wrote:
>> I was just trying to point out that the 6-only status
>> of 2.5.0 is likely going to lead to quite delayed adoption in packaging
>> systems.
>
> Can you share an overview of the PROJ 6 status in NetBSD?

In pkgsrc, there is currently pkgsrc/geograph/proj as 5.2.0.  This
package name is what pkgsrc considers to be the currently-packaged
version, and what everything that depends on proj depends on.  This
package is marked (in a comment) as not allowed to be updated to 6 until
I as package manger think the fallout is manageable.

In wip/proj, there is 6.0.0.  wip is technically not part of pkgsrc, but
people can install from there and then rebuild whatever they like.  I've
been doing this in order to test if things work with 6.  (packages in
pkgsrc proper are not allowed to depend on wip/.  wip is a combination
of what others might call "testing", and a place where pretty much
anyone can get write acess to place packages.)

Already quite a few more things work with proj 6 than when I started
this process.  I do not have an up-to-date list of what's trouble.

It's probably time to install proj 6 and try to build everything that
depends on proj again.

> Since NetBSD doesn't have most of the problematic packages or hasn't
> patched them as heavily as in Debian, I think that you should be able to
> move to PROJ 6 much sooner than other distributions.

I agree with your assessment.

Overall, I think we're making pretty good progress.
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev