#299 PDL::GIS::Proj doesn't buidl with proj-4.8.0

other (94)

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.


  • Petr Písař

    Petr Písař - 2012-06-27

    Despite entry in 2.4.11 changelog, this is still issue. The projects.h is not in the 2.4.11 tar ball.

  • Chris Marshall

    Chris Marshall - 2012-06-27

    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.

  • Anton Leontiev

    Anton Leontiev - 2012-08-05

    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)?

  • Chris Marshall

    Chris Marshall - 2012-08-05

    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.

  • Chris Marshall

    Chris Marshall - 2012-11-17

    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.

  • Chris Marshall

    Chris Marshall - 2012-11-17

    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.

  • Petr Písař

    Petr Písař - 2012-11-18

    I guess running external commands in build process is quite normal. Aren't you afraid of calling gcc or pkg-config?

  • Chris Marshall

    Chris Marshall - 2012-11-18

    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.

  • Judd Taylor

    Judd Taylor - 2012-11-19

    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.

  • Chris Marshall

    Chris Marshall - 2013-01-02
    • priority: 5 --> 6
  • Myra

    Myra - 2013-01-04

    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.


  • Chris Marshall

    Chris Marshall - 2013-01-04

    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.

  • Chris Marshall

    Chris Marshall - 2013-02-20
    • priority: 6 --> 1
    • status: open --> open-fixed
  • Chris Marshall

    Chris Marshall - 2013-02-20

    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.

  • Chris Marshall

    Chris Marshall - 2013-02-21

    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.

  • Chris Marshall

    Chris Marshall - 2013-08-10
    • status: open-fixed --> closed-fixed
    • Group: --> critical

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks