Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

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

critical
closed-fixed
nobody
other (94)
1
2013-08-10
2012-04-07
Chris Marshall
No

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.

Discussion

1 2 > >> (Page 1 of 2)
  • 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.

     
1 2 > >> (Page 1 of 2)