I didn't follow the latest changes in proj4, just what I got on gdal-dev mailing list. From https://proj4.org/news.html
I see that also the proj_api.h interface has been deprecated, so this seems to require a major change. This implies to me that it would be necessary to support both old and new API as on many distibutions it will take some time to upgrade to proj4 version 6.
Do you, by chance, have any information on what is the best way to handle this transition? How do other projects tackle this task?
I found https://proj4.org/development/migration.html
Is this the latest information available? It only describes proj4 version 4 to 5 migration, but I expect that there are further changes required for version 6.
Supporting version 4 and 6 of the API together would not only require changes in the source code but also to the build systems. How is this handled in other projects?
Thanks,
Volker
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
GDAL, GRASS, PostGIS & QGIS have added support for PROJ 6 in their VCS, that may be sufficient inspiration for SAGA.
The docs on proj4.org should be current with what's in git, but may not have sufficient information for migrating to PROJ 6, I've heard complaints from other upstreams about that too.
If you have questions about using the PROJ 6 API, asking on the proj@lists.osgeo.org mailinglist is a good option. Even Rouault and Kristian Evers are available there, and have most experience with PROJ development, Even in particular is responsible for most of the changes in PROJ 6.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Olaf has added support for PROJ6 in the SAGA sources and it works fine. We would like to provide a fallback solution to also use PROJ4 (still available in the sources), but I'm struggling with a robust way to handle this in the autotools build system and it would be great to get some help.
The main question is: are there systems on which several different PROJ versions are installed? I expect this, but how is it thought to handle that in a robust way? I commited a premiliary hack to configure.ac, but it fails as soon as several versions are detected and/or you do not take care about PATH precedence.
So far I came to the conclusion that there is only "the hard way" to introduce additional flags like "--with-proj-includes" and "--with-proj-libs" to configure, as GRASS seems to do it. Do you know of a simpler (i.e. automatic) way to handle this or is this the way to go?
An related issue is PROJ5 vs PROJ6 API compatibility: the documents are not very clear about that, I only found that the projects.h header has been removed in PROJ6. Looking at the GRASS build system, it seems that only PROJ 5.1.0 is compatible with PROJ6, as they make it their requirement to use the new API. Do you have any information about that? That would require an additional version check if PROJ5 is used.
Thanks and best regards,
Volker
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If configure detects multiple versions, use the first (in order of PATH) by default and provide options for the user to specify which one to use (e.g. the one in /usr/local or /usr) for making the choice explicit.
Not sure about the API, it may be similar to the current situation where (the upcoming) PROJ 6.1.0 will contain changes to fix issues/regressions introduced in 6.0.0. The best place to ask such questions is on the proj list.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't see the related commits referenced in this issue, but I see many when browing the commits. I suspect that cherry-picking them and adding them as patches to our 2.3.1 package will be a PITA and likely to miss relevant commits not easily identified by the commit message.
If there is a pre-release of the next SAGA LTR we can update the package to that. Will that be 7.2.x or something else?
That being said, I'd prefer if Johan takes care of the saga package update, but I suspect he lacks time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
we have released 7.0.3 including the PROJ6 support. So I'm closing this ticket. I don't think the changes can be easily backported to 2.3.1, or least this does not make much sense to me.
Best regards,
Volker
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Bas,
I didn't follow the latest changes in proj4, just what I got on gdal-dev mailing list. From
https://proj4.org/news.html
I see that also the proj_api.h interface has been deprecated, so this seems to require a major change. This implies to me that it would be necessary to support both old and new API as on many distibutions it will take some time to upgrade to proj4 version 6.
Do you, by chance, have any information on what is the best way to handle this transition? How do other projects tackle this task?
I found
https://proj4.org/development/migration.html
Is this the latest information available? It only describes proj4 version 4 to 5 migration, but I expect that there are further changes required for version 6.
Supporting version 4 and 6 of the API together would not only require changes in the source code but also to the build systems. How is this handled in other projects?
Thanks,
Volker
GDAL, GRASS, PostGIS & QGIS have added support for PROJ 6 in their VCS, that may be sufficient inspiration for SAGA.
The docs on proj4.org should be current with what's in git, but may not have sufficient information for migrating to PROJ 6, I've heard complaints from other upstreams about that too.
If you have questions about using the PROJ 6 API, asking on the proj@lists.osgeo.org mailinglist is a good option. Even Rouault and Kristian Evers are available there, and have most experience with PROJ development, Even in particular is responsible for most of the changes in PROJ 6.
Hi Bas,
Olaf has added support for PROJ6 in the SAGA sources and it works fine. We would like to provide a fallback solution to also use PROJ4 (still available in the sources), but I'm struggling with a robust way to handle this in the autotools build system and it would be great to get some help.
The main question is: are there systems on which several different PROJ versions are installed? I expect this, but how is it thought to handle that in a robust way? I commited a premiliary hack to configure.ac, but it fails as soon as several versions are detected and/or you do not take care about PATH precedence.
So far I came to the conclusion that there is only "the hard way" to introduce additional flags like "--with-proj-includes" and "--with-proj-libs" to configure, as GRASS seems to do it. Do you know of a simpler (i.e. automatic) way to handle this or is this the way to go?
An related issue is PROJ5 vs PROJ6 API compatibility: the documents are not very clear about that, I only found that the projects.h header has been removed in PROJ6. Looking at the GRASS build system, it seems that only PROJ 5.1.0 is compatible with PROJ6, as they make it their requirement to use the new API. Do you have any information about that? That would require an additional version check if PROJ5 is used.
Thanks and best regards,
Volker
If
configuredetects multiple versions, use the first (in order ofPATH) by default and provide options for the user to specify which one to use (e.g. the one in/usr/localor/usr) for making the choice explicit.Not sure about the API, it may be similar to the current situation where (the upcoming) PROJ 6.1.0 will contain changes to fix issues/regressions introduced in 6.0.0. The best place to ask such questions is on the proj list.
Hi Bas,
just saw your post on gdal-dev and it reminded me that I haven't edited this ticket.
PROJ6 support has been implemented, last commit for this was https://sourceforge.net/p/saga-gis/code/ci/aa247a3dad360b23831538a411f64c89961f97fe/
So please test, if you encounter no problems I will close this ticket.
Side note: the next SAGA release is intended to become the new LTR for use with QGIS (which will upgrade their processing plugin for this release).
Best regards,
Volker
I don't see the related commits referenced in this issue, but I see many when browing the commits. I suspect that cherry-picking them and adding them as patches to our 2.3.1 package will be a PITA and likely to miss relevant commits not easily identified by the commit message.
If there is a pre-release of the next SAGA LTR we can update the package to that. Will that be 7.2.x or something else?
That being said, I'd prefer if Johan takes care of the saga package update, but I suspect he lacks time.
Hi Bas,
we have released 7.0.3 including the PROJ6 support. So I'm closing this ticket. I don't think the changes can be easily backported to 2.3.1, or least this does not make much sense to me.
Best regards,
Volker
Hi !
It works well with PROJ.5 (recently downlaoded) with Mac OS X Snow Leopard (v. 10.6.8).
Thank you !
Hi Laurent,
your screenshot shows that you are using SAGA 7.2.0 - please note that the changes made to support PROJ6 are only available since SAGA 7.3.0.
Best regards,
Volker