Open sebastic opened 6 years ago
In 2012, project.h became "internal". However, that did not offer all the things I needed. Maybe 5.0.0 has repaired that: I'll have to check.
The new typedef collision is horrible, because I do not have control on either header file. I have to dive into this to see whether there is a work-around. ASAP.
5.0.0 is not final yet, and the developers are very receptive to feedback. If there is something you need in the new API I'm sure they'll help get it implemented.
Note that PDL has exactly the same issue, so there is quite a bit of demand to make Proj 5.0.0 also work for Perl projects.
5.0.0 is not final yet, and the developers are very receptive to feedback. If there is something you need in the new API I'm sure they'll help get it implemented.
Note that PDL has exactly the same issue, so there is quite a bit of demand to make Proj 5.0.0 also work for Perl projects.
I did not know that PDL had a connection to proj4 as well.
Looking back at the code, my memory tells me that it only has to do with being able to get names defined in the library: struct PJ_LIST pj_get_list_ref() struct PJ_ELLPS pj_get_ellps_ref() struct PJ_UNITS pj_get_units_ref() struct PJ_DATUM pj_get_datums_ref()
Access to these tables is very useful to be able to give some help to the users. For instance, to create option menus in graphical applications. I have no idea whether anyone is using it for real.
I see that PDL::GIS::Proj also does this:
my @a = split(/\n/, echo | proj -v $params
);
to get some info.
It is only a small part of projects.h, so I may also copy that code into my Proj.xs Of course, that needs to be maintained for all libproj4 releases.
Or, not my preference, I could collect that data at compile-time from command-line scripts and insert that in the code.
You may be able to help-out here. rc2 is a bit late to move defs from private to public. -- Regards, MarkOv
drs Mark A.C.J. Overmeer MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Copying the code is probably not a good idea, too maintenance intensive. Although proj releases are not very frequent.
If the changes you need for Geo::Proj4 are too late for Proj 5.0.0, they could be implemented in the next release.
What help do you need from me? My role is mostly as the maintainer of the various Debian packages like proj, libgeo-proj4-perl & pdl.
I've forwarded your comments to the proj list, see:
http://lists.maptools.org/pipermail/proj/2018-February/007976.html
Copying the code is probably not a good idea, too maintenance intensive. Although proj releases are not very frequent.
Some bad ideas are the only option ;-)
If the changes you need for Geo::Proj4 are too late for Proj 5.0.0, they could be implemented in the next release.
The XS can include proj4 library version dependent parts.
What help do you need from me? My role is mostly as the maintainer of the various Debian packages like proj, libgeo-proj4-perl & pdl.
Forwarding the question to the proj4 mailinglist (and passing back the conclusion of the responses) is really helping. Thanks. -- MarkOv
drs Mark A.C.J. Overmeer MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
In principle we shouldn’t do API changes now, but on the other hand this is the first time the code is properly tested against other libraries so some adjustments can be necessary.
First off, the new API has the following functions:
const PJ_OPERATIONS *proj_list_operations(void); const PJ_ELLPS *proj_list_ellps(void); const PJ_UNITS *proj_list_units(void); const PJ_PRIME_MERIDIANS *proj_list_prime_meridians(void);
Which does the same thing as the
pj_get_*_ref()
functions you mention. Except that there is no function for getting the list of datums. The reason being that the+datum
parameter is “classic” PROJ functionality which will be phased out eventually (we are moving away from the WGS84 hub datum which+datum
is based on).So the simple answer is to use the new API. Unfortunately you will have the same problem since we also have a UV typedef in the new API. So at least I think we should change that in order to not clash with other libraries. Unless there is any objections to this, I will rename the types XY, LP, UV, XXYZ, LPZ, UVZ to PJ_XY, PJ_LP, PJ_UV, PJ_XYZ, PJ_LPZ, PJ_UVZ.
Another solution to the problem would be to move the mentioned functions to proj_api.h. I am reluctant to do that. I want an incentive to move to the new API so the transition happens as fast as possible.
How does that work for you?
First off, the new API has the following functions:
const PJ_OPERATIONS *proj_list_operations(void); const PJ_ELLPS *proj_list_ellps(void); const PJ_UNITS *proj_list_units(void); const PJ_PRIME_MERIDIANS *proj_list_prime_meridians(void);
Ok, it's simple to create a proj4 version specific name. I want to stay compatible with a few versions of libproj4.
Except that there is no function for getting the list of datums. The reason being that the
+datum
parameter is “classic” PROJ functionality which will be phased out eventually (we are moving away from the WGS84 hub datum which+datum
is based on).
"we are moving" means future. We are living now. I would like to have a deprecation cycle for this.
I will rename the types XY, LP, UV, XXYZ, LPZ, UVZ to PJ_XY, PJ_LP, PJ_UV, PJ_XYZ, PJ_LPZ, PJ_UVZ.
Excellent. -- Regards, MarkOv
Mark Overmeer MSc MARKOV Solutions
drs Mark A.C.J. Overmeer MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Note that PDL has exactly the same issue, so there is quite a bit of demand to make Proj 5.0.0 also work for Perl projects.
Can you get us on page http://proj4.org/development/bindings.html ? -- MarkOv
Mark Overmeer MSc MARKOV Solutions
Mark@Overmeer.net solutions@overmeer.net
@markov2 I am looking into fixing this. We don't want this release to break anything for current users of the library (except for a few minor details announced in the release notes). This problem has just been overlooked. We are going to break things with the next major version release though.
I suggest you subscribe to the mailing list to keep updated in the future. I expect us to run into several similar issues since we don't get very much feedback from users of the library. Your help in avoiding such problems would be appreciated.
Can you get us on page http://proj4.org/development/bindings.html ?
You are welcome to submit a pull request with the addition.
The removal of the old APIs in proj is documented in the NEWS file:
DEPRECATIONS
o The projects.h header and the functions related to it is considered deprecated from version 5.0.0 and onwards.
!!! PROJECTS.H WILL BE REMOVED FROM THE LIBRARY !!! !!! WITH VERSION 6.0.0 !!!
[...]
o The proj_api.h header and the functions related to it is consided deprecated from version 5.0.0 and onwards.
!!! PROJ_API.H WILL BE REMOVED FROM THE LIBRARY !!! !!! WITH VERSION 7.0.0 !!!
Keeping support for the proj v4.x releases in Geo::Proj4 for some time makes sense. Support for the new API should be added for users of proj v5.x.
I suggest you subscribe to the mailing list to keep updated in the future. I expect us to run into several similar issues since we don't get very much feedback from users of the library. Your help in avoiding such problems would be appreciated.
Can you get us on page http://proj4.org/development/bindings.html ? You are welcome to submit a pull request with the addition.
I am not a user of the library myself, at the moment. I took over maintenance in 2005, because I needed fixes to the original code. But I haven't been using libproj4 myself since 2010, or so.
So many other projects ask for my attention, that I will not get involved on the mailinglist or github here.
On the other hand: on regular basis I have contact with users of my module on CPAN (usually they do not get the lib to compile) As long as there are users, I will try to keep the Perl interface stable. -- Regards, MarkOv
Mark Overmeer MSc MARKOV Solutions
Mark@Overmeer.net solutions@overmeer.net
With the renamed typedef in proj (https://github.com/OSGeo/proj.4/commit/9c75d794177276189d0a2809bc462291e1a070d3) Geo::Proj4 not longer fails to build.
That resolves this issue for the most part. Geo::Proj4 still needs to be updated to use the new API.
PROJ 6.0.0 has been released and removes projects.h
which is used by Geo::Proj4.
proj_api.h
is also deprecated in PROJ 6.0.0 and will be removed in PROJ 7.0.0 (scheduled for March 2020).
When using proj_api.h
with PROJ 6.0.0 -DACCEPT_USE_OF_DEPRECATED_PROJ_API_H=1
needs to be added to CFLAGS
to prevent a compiler error.
Geo::Proj4 should be updated to (also) support the proj.h
API.
Using the embedded copy of PROJ 4.8.0 is not desirable.
The Alien::Proj4 package might be of use here, at least in the short term and for the version 4 bindings. https://github.com/PDLPorters/Alien-Proj4
If the system version of proj4 is >=5 then Alien::Proj4 will build a local version, visible only to the consumers of that package (all thanks to Alien::Build). Alien::Build will use a detected system library by default, so there will be issues where it is built against a system proj v4 and a user later updates to a more recent version. It might therefore be worth trying to enforce a share install by Alien::Proj4.
The PDL issue noted in https://github.com/markov2/perl5-Geo-Proj4/issues/1#issuecomment-364363537 has been addressed in the PDLA fork by using Alien::Proj4.
https://github.com/PDLPorters/pdla-gis
There is also Alien::proj which is on CPAN and does not (yet) lock to a specific version. Github repo is at https://github.com/shawnlaffan/perl-alien-proj4
Still no progress, eh?
We're going to start the proj transition in Debian soon. That will also trigger the removal of Geo::Proj4 (and its reverse dependencies like Geo::Point) from Debian, as discussed in:
Still no progress, eh?
Tried to find time to get it done, but did not find enough of it. I need to support all de versions of proj from one module on CPAN, but the libproj do not have that compatibility by themselves.
So: the plan is there, the tasks is complex, the time too limited. I'll report when I have it working. -- MarkOv
drs Mark A.C.J. Overmeer MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
You can use https://github.com/markov2/perl5-Geo-Proj4/pull/4 as base for you work. It builds but tests do not pass. I followed only the syntax. Probably it needs more love and understanding to Proj I don't have.
The issue is that the library has structurally changed completely, from 2D into 4D and such. There is no simple repair.
In that case keeping Geo-Proj4 for Proj 4 only and forking it for Proj 6, let's say Geo-Proj6, would be more reasonable.
I suggest to drop the version from the project name like PROJ has done.
There are many reasons why that is not possible... for one: Geo::Proj is already in use by an other module (accidentally also owned by me ;-)
My current plan is to set Geo::Proj5 and Geo::Proj6 (and Geo::Proj7) next to another, and keep Geo::Proj as the abstract interface, which roles it currently has as well.
In preparation of the upcoming Proj 5.0.0 release, the libgeo-proj4-perl package was rebuilt with Proj 5.0.0-rc2. Unfortunately it failed to build:
projects.h
is an internal API that Geo::Proj4 shouldn't use, this along with the other old APIs will be removed from the upcoming releases. See the NEWS file details.