It has been reported that the PDL PROJ4 module(s)
in the core distribution fail to build with the latest
release, version 4.8.0. The error seems to be related
to the projects.h include file.
The git log message is about reverting a
fix for prij 4.8.0 support that broke the build
for previous versions of proj.
projects.h is a file in the proj4 distributio
and not the PDL distribution.
The work around for 4.8.0 proj4 support
is to copy the projects.h file from the
proj4 4.8.0 distribution to the same include
directory as the proj_api,h file. That will
allow the PDL source build to work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem is that projects.h file is for internal use in proj4 package. And people from proj4 decided to remove it from distribution (see http://trac.osgeo.org/proj/ticket/159\). Is it possible to avoid use of projects.h in PDL and use only public headers (proj_api.h)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem is that the PROJ4 developers have decided that projects.h will be an internal use only file *without* providing the ability to get the list of available projections through the public API. The only way that appears to be possible would be to run the proj command with various -l options and parse the output. Pending some sort of resolution, we're sticking with the use of projects.h.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I took a further look at this and it appears that with 3 differences,
the output from the PJ_LIST using the internal PROJ4 API and
the output of the proj -lP appear to be identical. I.e., the output
of 'proj -l' gives the list of projections which are the keys from the
PDL::GIS::Proj::load_projection_descriptions() command and those
keys are also found in the full output list from 'proj -lP'. E.g., the
'proj -l' gives:
aea : Albers Equal Area
aeqd : Azimuthal Equidistant
airy : Airy
aitoff : Aitoff
alsk : Mod. Stererographics of Alaska
apian : Apian Globular I
august : August Epicycloidal
bacon : Bacon Globular
bipc : Bipolar conic of western hemisphere
boggs : Boggs Eumorphic
bonne : Bonne (Werner lat_1=90)
...
where the names of the projections are at the
beginning of the line before the ' : ' separators.
The corresponding output from 'proj -lP' for
the projections look like this (for the case of
aeqd as a single example):
where the coordinate system is, again,
the key before the ' : ' and the rest of the
entry is exactly the output of the internal
API description we already parse to
generate the list of transforms:
pdl> p $desc->{aeqd}
Azimuthal Equidistant
Azi, Sph&Ell
lat_0 guam
Most of the work will probably be making sure
not to break the detection or build process with
changing to the new approach. I like the binary
library approach but it appears that the PROJ4
developers intend this to be the "approved"
method to get this information.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I still don't like running an external command as part of the
PDL build since it could be a potential security hole if there
were a conveniently named "bad" executable in the path.
Maybe we could hardwire a standard list of projections that
could be verified using the public API instead. I'm not
sure how much variability there would be in the projections
available from site to site.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Didn't say I was afraid, just that the change from using the library itself
to a system call of an executable does affect the integrity of the build.
That said, if we find the PROJ4 includes and library, it should be a
reasonable conclusion that the proj program has also been installed
so adding hardwired projections won't really add much protection in
the typical auto-PROJ4 install for PDL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with Chris about not wanting to use the external commands.
It's also quite common every release (of proj) that the proj command doesn't work out of the box. It's usually that some distro packager doesn't include the /usr/share/proj files, or doesn't setup the environment variable to point there properly.
At this point, the information we need can't be pulled from the "Public" API for proj, as there are no functions to support this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hope I'm not intruding, but my 2 cents worth. The projects.h file is available from http://svn.osgeo.org/metacrs/proj/trunk/proj. The copyright is open source and permissive. I downloaded the file, included it in the tarball and built pdl against proj v 4.8.0.
Would it be possible to do the same and include it in the pdl package or would that create version conflict problems?
One of the joys of using Arch Linux is learning how to make things work when they don't, being willing to do some work to get want you want, and you learn package management.
Myra
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Right now, it appears the only portable approach is to use the proj command to generate the list. My plan is to implement that capability with a fallback list based on the current projections list. Since the projections have not changed in quite a while, this should work. If a user needs a projection not from the static list, they would have the capability (and option) of generating an updated list.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The current git works around the problem by providing its own versions of the needed file when version 4.8.0 is detected. This fix is available from CPAN developers release CHM/PDL-2.4.11_010.tar.gz and on. Leaving the ticket open at lower priority as a reminder we need a "real" fix at some point.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The fix is only for PROJ4 version 4.8.0. If you are using
something more recent---i.e., the current svn version, then
you'll have the same failure that you used to get with
PROJ4 4.8.0. The Makefile.PL in the PDL/Lib/GIS/Proj/
directory could be modified to not use the special
included version if the user already has included a valid
projects.h file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Despite entry in 2.4.11 changelog, this is still issue. The projects.h is not in the 2.4.11 tar ball.
This ticket is still open.
The git log message is about reverting a
fix for prij 4.8.0 support that broke the build
for previous versions of proj.
projects.h is a file in the proj4 distributio
and not the PDL distribution.
The work around for 4.8.0 proj4 support
is to copy the projects.h file from the
proj4 4.8.0 distribution to the same include
directory as the proj_api,h file. That will
allow the PDL source build to work.
The problem is that projects.h file is for internal use in proj4 package. And people from proj4 decided to remove it from distribution (see http://trac.osgeo.org/proj/ticket/159\). Is it possible to avoid use of projects.h in PDL and use only public headers (proj_api.h)?
The problem is that the PROJ4 developers have decided that projects.h will be an internal use only file *without* providing the ability to get the list of available projections through the public API. The only way that appears to be possible would be to run the proj command with various -l options and parse the output. Pending some sort of resolution, we're sticking with the use of projects.h.
I've just opened enhancement request on the PROJ4 tracker:
http://trac.osgeo.org/proj/ticket/187
I took a further look at this and it appears that with 3 differences,
the output from the PJ_LIST using the internal PROJ4 API and
the output of the proj -lP appear to be identical. I.e., the output
of 'proj -l' gives the list of projections which are the keys from the
PDL::GIS::Proj::load_projection_descriptions() command and those
keys are also found in the full output list from 'proj -lP'. E.g., the
'proj -l' gives:
aea : Albers Equal Area
aeqd : Azimuthal Equidistant
airy : Airy
aitoff : Aitoff
alsk : Mod. Stererographics of Alaska
apian : Apian Globular I
august : August Epicycloidal
bacon : Bacon Globular
bipc : Bipolar conic of western hemisphere
boggs : Boggs Eumorphic
bonne : Bonne (Werner lat_1=90)
...
where the names of the projections are at the
beginning of the line before the ' : ' separators.
The corresponding output from 'proj -lP' for
the projections look like this (for the case of
aeqd as a single example):
aeqd : Azimuthal Equidistant
Azi, Sph&Ell
lat_0 guam
where the coordinate system is, again,
the key before the ' : ' and the rest of the
entry is exactly the output of the internal
API description we already parse to
generate the list of transforms:
pdl> p $desc->{aeqd}
Azimuthal Equidistant
Azi, Sph&Ell
lat_0 guam
Most of the work will probably be making sure
not to break the detection or build process with
changing to the new approach. I like the binary
library approach but it appears that the PROJ4
developers intend this to be the "approved"
method to get this information.
I still don't like running an external command as part of the
PDL build since it could be a potential security hole if there
were a conveniently named "bad" executable in the path.
Maybe we could hardwire a standard list of projections that
could be verified using the public API instead. I'm not
sure how much variability there would be in the projections
available from site to site.
I guess running external commands in build process is quite normal. Aren't you afraid of calling gcc or pkg-config?
Didn't say I was afraid, just that the change from using the library itself
to a system call of an executable does affect the integrity of the build.
That said, if we find the PROJ4 includes and library, it should be a
reasonable conclusion that the proj program has also been installed
so adding hardwired projections won't really add much protection in
the typical auto-PROJ4 install for PDL.
I agree with Chris about not wanting to use the external commands.
It's also quite common every release (of proj) that the proj command doesn't work out of the box. It's usually that some distro packager doesn't include the /usr/share/proj files, or doesn't setup the environment variable to point there properly.
At this point, the information we need can't be pulled from the "Public" API for proj, as there are no functions to support this.
Hope I'm not intruding, but my 2 cents worth. The projects.h file is available from http://svn.osgeo.org/metacrs/proj/trunk/proj. The copyright is open source and permissive. I downloaded the file, included it in the tarball and built pdl against proj v 4.8.0.
Would it be possible to do the same and include it in the pdl package or would that create version conflict problems?
One of the joys of using Arch Linux is learning how to make things work when they don't, being willing to do some work to get want you want, and you learn package management.
Myra
Right now, it appears the only portable approach is to use the proj command to generate the list. My plan is to implement that capability with a fallback list based on the current projections list. Since the projections have not changed in quite a while, this should work. If a user needs a projection not from the static list, they would have the capability (and option) of generating an updated list.
The current git works around the problem by providing its own versions of the needed file when version 4.8.0 is detected. This fix is available from CPAN developers release CHM/PDL-2.4.11_010.tar.gz and on. Leaving the ticket open at lower priority as a reminder we need a "real" fix at some point.
The fix is only for PROJ4 version 4.8.0. If you are using
something more recent---i.e., the current svn version, then
you'll have the same failure that you used to get with
PROJ4 4.8.0. The Makefile.PL in the PDL/Lib/GIS/Proj/
directory could be modified to not use the special
included version if the user already has included a valid
projects.h file.