[GRASS5] auto-locate EPSG

Hi,

the new auto-locate EPSG file isn't working for me.

Installed from Debian's proj package in:
/usr/share/proj/epsg

but clicking "Use EPSG values" points to non-existant /usr/local/share/...

I don't see any log messages in config.log or ./configure output.

Do I have to use --with-proj-includes= ?
(it has been fine without it up to now)

./configure
...
checking for location of External PROJ.4 includes...
checking for proj_api.h... yes
checking External PROJ.4 version... 449
checking for location of External PROJ.4 library...
checking for pj_get_def in -lproj... yes
checking for nad2bin... /usr/bin/nad2bin

?
Hamish

On Wed, Apr 26, 2006 at 09:55:53PM +1200, Hamish wrote:

Hi,

the new auto-locate EPSG file isn't working for me.

Mea culpa.

Installed from Debian's proj package in:
/usr/share/proj/epsg

but clicking "Use EPSG values" points to non-existant /usr/local/share/...

I don't see any log messages in config.log or ./configure output.

Please check:

grep PROJSHARE include/Make/Platform.make
PROJSHARE = /usr/local/share/proj

configure now defines via hack (I didn't receive an answer how
to do it properly) where the PROJ software is installed.

See configure.in, line 583 ff.

Do I have to use --with-proj-includes= ?
(it has been fine without it up to now)

Behaviour *should* not change. Apparently the
$PROJINC
test fails on your machine.

./configure
...
checking for location of External PROJ.4 includes...
checking for proj_api.h... yes
checking External PROJ.4 version... 449
checking for location of External PROJ.4 library...
checking for pj_get_def in -lproj... yes
checking for nad2bin... /usr/bin/nad2bin

It should be easy to fix, but I don't have a Debian test
environment.

Markus

> the new auto-locate EPSG file isn't working for me.

..

Please check:

grep PROJSHARE include/Make/Platform.make
PROJSHARE = /usr/local/share/proj

$ grep PROJSHARE include/Make/Platform.make
PROJSHARE = /usr/local/share/proj
$ ls /usr/local/share/proj
ls: /usr/local/share/proj: No such file or directory

configure now defines via hack (I didn't receive an answer how
to do it properly) where the PROJ software is installed.

See configure.in, line 583 ff.

> Do I have to use --with-proj-includes= ?
> (it has been fine without it up to now)

Behaviour *should* not change. Apparently the
$PROJINC
test fails on your machine.

this one: ?

# Define share/proj/ directory for epsg code file
PROJSHARE=
if test -n "$PROJINC"; then
        PROJSHARE=/usr/share/proj
else
        PROJSHARE=/usr/local/share/proj
fi

is $PROJINC only set if I used --with-proj-includes ??

If not, what sets it?

Hamish

On Thu, Apr 27, 2006 at 12:32:52AM +1200, Hamish wrote:

> > the new auto-locate EPSG file isn't working for me.
..
> Please check:
>
> grep PROJSHARE include/Make/Platform.make
> PROJSHARE = /usr/local/share/proj

$ grep PROJSHARE include/Make/Platform.make
PROJSHARE = /usr/local/share/proj
$ ls /usr/local/share/proj
ls: /usr/local/share/proj: No such file or directory

> configure now defines via hack (I didn't receive an answer how
> to do it properly) where the PROJ software is installed.
>
> See configure.in, line 583 ff.
>
> > Do I have to use --with-proj-includes= ?
> > (it has been fine without it up to now)
>
> Behaviour *should* not change. Apparently the
> $PROJINC
> test fails on your machine.

this one: ?

# Define share/proj/ directory for epsg code file
PROJSHARE=
if test -n "$PROJINC"; then
        PROJSHARE=/usr/share/proj
else
        PROJSHARE=/usr/local/share/proj
fi

is $PROJINC only set if I used --with-proj-includes ??

No idea.

Maybe it should be -z instead of -n?

Markus

> > > the new auto-locate EPSG file isn't working for me.
> ..
> > configure now defines via hack (I didn't receive an answer how
> > to do it properly) where the PROJ software is installed.
> >
> > See configure.in, line 583 ff.
> >
> > > Do I have to use --with-proj-includes= ?
> > > (it has been fine without it up to now)
> >
> > Behaviour *should* not change. Apparently the
> > $PROJINC
> > test fails on your machine.
>
> this one: ?
>
> # Define share/proj/ directory for epsg code file
> PROJSHARE=
> if test -n "$PROJINC"; then
> PROJSHARE=/usr/share/proj
> else
> PROJSHARE=/usr/local/share/proj
> fi
>
>
> is $PROJINC only set if I used --with-proj-includes ??

No idea.

Maybe it should be -z instead of -n?

I don't know much about configure, are those tests bash compatible?

If so I would guess the above is testing for whatever
"--with-proj-includes=" was set to. This is not auto-detected; if the
includes and libs are in standard paths /usr/include, ld.so.conf,
the conftests will work without that being set.

So the above just checks to see if you set --with-proj-includes and
arbitrarily starts setting a epsg path based on that. :confused:

better: (if it works)

# Define share/proj/ directory for epsg code file
PROJSHARE=
if test -n "$PROJINC"; then
   PROJSHARE="$PROJINC/../share/proj"
else
   for testdir in /usr /usr/local ; do
      if test -d $testdir/share/proj ; then
         PROJSHARE=$testdir/share/proj
         break
      fi
   done
fi

"$PROJINC/../share/proj" could be better evaluated? use $PROJLIB ?

where does epsg get stored on a Mac, Cygwin, windows native, etc?

how does PROJ4 know where to find it if PROJ_LIB isn't set?

?

Hamish

> > > > the new auto-locate EPSG file isn't working for me.
> > ..
> > > configure now defines via hack (I didn't receive an answer how
> > > to do it properly) where the PROJ software is installed.
> > >
> > > See configure.in, line 583 ff.

..

# Define share/proj/ directory for epsg code file
PROJSHARE=
if test -n "$PROJINC"; then
   PROJSHARE="$PROJINC/../share/proj"
else
   for testdir in /usr /usr/local ; do
      if test -d $testdir/share/proj ; then
         PROJSHARE=$testdir/share/proj
         break
      fi
   done
fi

"$PROJINC/../share/proj" could be better evaluated? use $PROJLIB ?

where does epsg get stored on a Mac, Cygwin, windows native, etc?

how does PROJ4 know where to find it if PROJ_LIB isn't set?

The above test sets it correctly for me (file is in /usr/share/proj/)

If none of those tests find it, default to /usr/local/share/proj as
a hint?

Could someone quickly explain to me the relationship between configure.in
and configure?

thanks,
Hamish

Hamish wrote:

the new auto-locate EPSG file isn't working for me.
           

..
       

configure now defines via hack (I didn't receive an answer how
to do it properly) where the PROJ software is installed.

See configure.in, line 583 ff.
         

..

# Define share/proj/ directory for epsg code file
PROJSHARE=
if test -n "$PROJINC"; then
  PROJSHARE="$PROJINC/../share/proj"
else
  for testdir in /usr /usr/local ; do
     if test -d $testdir/share/proj ; then
        PROJSHARE=$testdir/share/proj
        break
     fi
  done
fi

"$PROJINC/../share/proj" could be better evaluated? use $PROJLIB ?

where does epsg get stored on a Mac, Cygwin, windows native, etc?

how does PROJ4 know where to find it if PROJ_LIB isn't set?
   
The above test sets it correctly for me (file is in /usr/share/proj/)

If none of those tests find it, default to /usr/local/share/proj as
a hint?

Yes, that should be ok.

Could someone quickly explain to me the relationship between configure.in
and configure?

configure is autogenerated from configure.in by autoconf-2.13
So, the file configure.in has to be worked on, not configure.
Unfortunately a macro seems to be
missing for the .../share/ stuff, that's why this damn hack is needed.

Markus

Markus Neteler wrote:

configure is autogenerated from configure.in by autoconf-2.13
So, the file configure.in has to be worked on, not configure.
Unfortunately a macro seems to be
missing for the .../share/ stuff, that's why this damn hack is needed.

So do we need a LOC_ARG_WITH_SHARE macro to go with the
LOC_ARG_WITH_{INC,LIB} macros? I.e.:

aclocal.m4:

  AC_DEFUN(LOC_ARG_WITH_SHARE,[
  AC_ARG_WITH($1-share,
  LOC_PAD([ --with-$1-share=DIRS])[$2 data files are in DIRS])
  ])

configure.in:

  LOC_ARG_WITH_SHARE(proj, External PROJ.4)

--
Glynn Clements <glynn@gclements.plus.com>

On Thu, Apr 27, 2006 at 07:08:02PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> configure is autogenerated from configure.in by autoconf-2.13
> So, the file configure.in has to be worked on, not configure.
> Unfortunately a macro seems to be
> missing for the .../share/ stuff, that's why this damn hack is needed.

So do we need a LOC_ARG_WITH_SHARE macro to go with the
LOC_ARG_WITH_{INC,LIB} macros? I.e.:

aclocal.m4:

  AC_DEFUN(LOC_ARG_WITH_SHARE,[
  AC_ARG_WITH($1-share,
  LOC_PAD([ --with-$1-share=DIRS])[$2 data files are in DIRS])
  ])

configure.in:

  LOC_ARG_WITH_SHARE(proj, External PROJ.4)

Thanks for your help! Do we probably also need to define

LOC_CHECK_SHARE_PATH(proj,External PROJ.4,PROJSHARE)

LOC_CHECK_SHARE(epsg,External PROJ.4,$PROJSHARE)

If not, I don't know how to figure out PROJSHARE (which I then need in
include/Make/Platform.make[.in]. If yes, would you mind to write those?

thanks

Markus

If not, I don't know how to figure out PROJSHARE (which I then need in
include/Make/Platform.make[.in]. If yes, would you mind to write
those?

does proj come with anything like "gdal-config --prefix" ?

Does Glynn's aclocal.m4 patch requre the user to have set --with-proj-*=
?

I would guess most people leave those blank for proj currently, so
parsing it to set default EPSG would only be used by the big packagers.
If true, the "hack" would be one step better in that regard as it
would catch the 90% of folks who use /usr or /usr/local as proj's
prefix.

??
Hamish

Markus Neteler wrote:

> > configure is autogenerated from configure.in by autoconf-2.13
> > So, the file configure.in has to be worked on, not configure.
> > Unfortunately a macro seems to be
> > missing for the .../share/ stuff, that's why this damn hack is needed.
>
> So do we need a LOC_ARG_WITH_SHARE macro to go with the
> LOC_ARG_WITH_{INC,LIB} macros? I.e.:
>
> aclocal.m4:
>
> AC_DEFUN(LOC_ARG_WITH_SHARE,[
> AC_ARG_WITH($1-share,
> LOC_PAD([ --with-$1-share=DIRS])[$2 data files are in DIRS])
> ])

Actually, this needs to be a single directory, unless the code which
locates the file can handle a list of directories. So:

  AC_DEFUN(LOC_ARG_WITH_SHARE,[
  AC_ARG_WITH($1-share,
  LOC_PAD([ --with-$1-share=DIR])[$2 data files are in DIR])
  ])

Note that, unlike headers/libraries, where the compiler/linker has a
default search path, the default value (the empty string) isn't much
use; the option has to be specified explicitly for the file to be
found.

> configure.in:
>
> LOC_ARG_WITH_SHARE(proj, External PROJ.4)

Thanks for your help! Do we probably also need to define

LOC_CHECK_SHARE_PATH(proj,External PROJ.4,PROJSHARE)

Definitely; it's needed to actually read the option value.

LOC_CHECK_SHARE(epsg,External PROJ.4,$PROJSHARE)

Probably a good idea, although the file isn't needed until run-time
(AFAIK), so the test isn't critical.

Also, if it's possible to use GRASS at all without that file, it
should use the 4th argument to generate a warning (the default is a
fatal error), e.g.:

  LOC_CHECK_SHARE(epsg,External PROJ.4,$PROJSHARE,[
  AC_MSG_WARN([*** Unable to locate PROJ data files.])
  ])

If not, I don't know how to figure out PROJSHARE (which I then need in
include/Make/Platform.make[.in]. If yes, would you mind to write those?

  AC_DEFUN(LOC_CHECK_SHARE_PATH,[
  AC_MSG_CHECKING(for location of $2 data files)
  case "$with_$1_share" in
  y | ye | yes | n | no)
    AC_MSG_ERROR([*** You must supply a directory to --with-$1-share.])
    ;;
  esac
  AC_MSG_RESULT($with_$1_share)
  
  if test -n "$with_$1_share" ; then
      if test -d "$with_$1_share"; then
          $3="$$3 -I$dir"
      else
          AC_MSG_ERROR([*** $2 data directory $dir does not exist.])
      fi
  fi
  ])

  AC_DEFUN(LOC_CHECK_SHARE,[
  AC_CHECK_FILE($3/$1, , ifelse($4,,[
      AC_MSG_ERROR([*** Unable to locate $2 data files.])
  ], $4))
  ])

--
Glynn Clements <glynn@gclements.plus.com>

Glynn,

I tried to add you suggestions bug autoconf gives me bad
news. Apparently I made something wrong.

Attached a opatch with your suggestions - may I ask you
to try it (at least autoconf-2.13) and then submit?
Hamish is elected beta tester for Debian :slight_smile:

thanks
Markus

On Fri, Apr 28, 2006 at 06:26:29PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> > > configure is autogenerated from configure.in by autoconf-2.13
> > > So, the file configure.in has to be worked on, not configure.
> > > Unfortunately a macro seems to be
> > > missing for the .../share/ stuff, that's why this damn hack is needed.
> >
> > So do we need a LOC_ARG_WITH_SHARE macro to go with the
> > LOC_ARG_WITH_{INC,LIB} macros? I.e.:
> >
> > aclocal.m4:
> >
> > AC_DEFUN(LOC_ARG_WITH_SHARE,[
> > AC_ARG_WITH($1-share,
> > LOC_PAD([ --with-$1-share=DIRS])[$2 data files are in DIRS])
> > ])

Actually, this needs to be a single directory, unless the code which
locates the file can handle a list of directories. So:

  AC_DEFUN(LOC_ARG_WITH_SHARE,[
  AC_ARG_WITH($1-share,
  LOC_PAD([ --with-$1-share=DIR])[$2 data files are in DIR])
  ])

Note that, unlike headers/libraries, where the compiler/linker has a
default search path, the default value (the empty string) isn't much
use; the option has to be specified explicitly for the file to be
found.

> > configure.in:
> >
> > LOC_ARG_WITH_SHARE(proj, External PROJ.4)
>
> Thanks for your help! Do we probably also need to define
>
> LOC_CHECK_SHARE_PATH(proj,External PROJ.4,PROJSHARE)

Definitely; it's needed to actually read the option value.

> LOC_CHECK_SHARE(epsg,External PROJ.4,$PROJSHARE)

Probably a good idea, although the file isn't needed until run-time
(AFAIK), so the test isn't critical.

Also, if it's possible to use GRASS at all without that file, it
should use the 4th argument to generate a warning (the default is a
fatal error), e.g.:

  LOC_CHECK_SHARE(epsg,External PROJ.4,$PROJSHARE,[
  AC_MSG_WARN([*** Unable to locate PROJ data files.])
  ])

> If not, I don't know how to figure out PROJSHARE (which I then need in
> include/Make/Platform.make[.in]. If yes, would you mind to write those?

  AC_DEFUN(LOC_CHECK_SHARE_PATH,[
  AC_MSG_CHECKING(for location of $2 data files)
  case "$with_$1_share" in
  y | ye | yes | n | no)
    AC_MSG_ERROR([*** You must supply a directory to --with-$1-share.])
    ;;
  esac
  AC_MSG_RESULT($with_$1_share)
  
  if test -n "$with_$1_share" ; then
      if test -d "$with_$1_share"; then
          $3="$$3 -I$dir"
      else
          AC_MSG_ERROR([*** $2 data directory $dir does not exist.])
      fi
  fi
  ])

  AC_DEFUN(LOC_CHECK_SHARE,[
  AC_CHECK_FILE($3/$1, , ifelse($4,,[
      AC_MSG_ERROR([*** Unable to locate $2 data files.])
  ], $4))
  ])

--
Glynn Clements <glynn@gclements.plus.com>

--
Markus Neteler <neteler itc it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

(attachments)

projshare.diff (2.09 KB)

On Fri, 2006-04-28 at 18:26 +0100, Glynn Clements wrote:

  AC_DEFUN(LOC_CHECK_SHARE_PATH,[
  AC_MSG_CHECKING(for location of $2 data files)
  case "$with_$1_share" in
  y | ye | yes | n | no)
    AC_MSG_ERROR([*** You must supply a directory to --with-$1-share.])
    ;;
  esac
  AC_MSG_RESULT($with_$1_share)
  
  if test -n "$with_$1_share" ; then
      if test -d "$with_$1_share"; then
          $3="$$3 -I$dir"

                  ^^^^^^^^^^^^^^^
???

would this be more appropriate?:
              if test -d "$with_$1_share" = 1; then
                  AC_MSG_ERROR(...)
              fi

      else
          AC_MSG_ERROR([*** $2 data directory $dir does not exist.])
      fi
  fi
  ])

  AC_DEFUN(LOC_CHECK_SHARE,[
  AC_CHECK_FILE($3/$1, , ifelse($4,,[
      AC_MSG_ERROR([*** Unable to locate $2 data files.])
  ], $4))
  ])

I committed some of this last night and sent Markus a patch for
LOC_CHECK_SHARE_PATH() to test.

--
Brad Douglas <rez touchofmadness com> KB8UYR
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785

Brad Douglas wrote:

> AC_DEFUN(LOC_CHECK_SHARE_PATH,[
> AC_MSG_CHECKING(for location of $2 data files)
> case "$with_$1_share" in
> y | ye | yes | n | no)
> AC_MSG_ERROR([*** You must supply a directory to --with-$1-share.])
> ;;
> esac
> AC_MSG_RESULT($with_$1_share)
>
> if test -n "$with_$1_share" ; then
> if test -d "$with_$1_share"; then
> $3="$$3 -I$dir"
                  ^^^^^^^^^^^^^^^
???

Oops; that should just be:

          $3="$dir"

--
Glynn Clements <glynn@gclements.plus.com>

Markus Neteler wrote:

I tried to add you suggestions bug autoconf gives me bad
news. Apparently I made something wrong.

There were some bugs in the macros in my email.

Attached a opatch with your suggestions - may I ask you
to try it (at least autoconf-2.13) and then submit?
Hamish is elected beta tester for Debian :slight_smile:

I've committed the changes. Everything appears to work insofar as the
specified directory gets passed to the projshare.sed script.

--
Glynn Clements <glynn@gclements.plus.com>

On Sat, Apr 29, 2006 at 05:50:35PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> I tried to add you suggestions bug autoconf gives me bad
> news. Apparently I made something wrong.

There were some bugs in the macros in my email.

> Attached a opatch with your suggestions - may I ask you
> to try it (at least autoconf-2.13) and then submit?
> Hamish is elected beta tester for Debian :slight_smile:

I've committed the changes. Everything appears to work insofar as the
specified directory gets passed to the projshare.sed script.

Glynn,

I have tested it, but it seems to fail:

checking for location of External PROJ.4 data files...
checking for /epsg... no
configure: warning: *** Unable to locate PROJ data files.
checking for nad2bin... /usr/local/bin/nad2bin

I have things in /usr/local/... and usually do not use any
parameters for proj.
Maybe /usr/local/share needs to be predefined somewhere to catch that?
As far as I understand the code
$with_proj_share
is not defined in this case - subsequently PROJSHARE is not
predefined.

Nice, soon we'll have this long standing problem of hard-coded
path being removed.

Markus

On Sat, Apr 29, 2006 at 06:59:26PM +0200, Markus Neteler wrote:

On Sat, Apr 29, 2006 at 05:50:35PM +0100, Glynn Clements wrote:
>
> Markus Neteler wrote:
>
> > I tried to add you suggestions bug autoconf gives me bad
> > news. Apparently I made something wrong.
>
> There were some bugs in the macros in my email.
>
> > Attached a opatch with your suggestions - may I ask you
> > to try it (at least autoconf-2.13) and then submit?
> > Hamish is elected beta tester for Debian :slight_smile:
>
> I've committed the changes. Everything appears to work insofar as the
> specified directory gets passed to the projshare.sed script.

Glynn,

I have tested it, but it seems to fail:

checking for location of External PROJ.4 data files...
checking for /epsg... no
configure: warning: *** Unable to locate PROJ data files.
checking for nad2bin... /usr/local/bin/nad2bin

I have things in /usr/local/... and usually do not use any
parameters for proj.
Maybe /usr/local/share needs to be predefined somewhere to catch that?

I guess that
$PROJLIB/../share
should be predefined (will catch most cases).

Markus

As far as I understand the code
$with_proj_share
is not defined in this case - subsequently PROJSHARE is not
predefined.

Nice, soon we'll have this long standing problem of hard-coded
path being removed.

Markus

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

> I have things in /usr/local/... and usually do not use any
> parameters for proj.
> Maybe /usr/local/share needs to be predefined somewhere to catch
> that?

back to the hardcoded /usr/local/share ...
If you are going to hardcode something, at least scan a little to cover
the other common cases, (add osx? fink? cygwin?)

# Define share/proj/ directory for epsg code file
PROJSHARE=
if test -n "$PROJINC"; then
   PROJSHARE="$PROJINC/../share/proj"
else
   for testdir in /usr /usr/local ; do
      if test -d $testdir/share/proj ; then
         PROJSHARE=$testdir/share/proj
         break
      fi
   done
fi
# if unset default to /usr/local/share/proj as a hint
if [ -z "$PROJSHARE" ] ; then
  PROJSHARE=/usr/local/share/proj
fi

I guess that
$PROJLIB/../share
should be predefined (will catch most cases).

but that means you have to use --with-proj-libs=/usr/local/lib to
get $PROJLIB defined? AFAIK it isn't autodetected, it just either is in
the search path or requires a custom setting. So back to the same
problem.

is there a `dirname, pwd, eval` combo that can change local/lib/../share
into local/share ?

Hamish

Hamish

> I've committed the changes. Everything appears to work insofar as
> the specified directory gets passed to the projshare.sed script.

Works as above for me on Debian (/usr/share/proj/epsg), with no
--with-proj-* :

checking for location of External PROJ.4 includes...
checking for proj_api.h... yes
checking External PROJ.4 version... 449
checking for location of External PROJ.4 library...
checking for pj_get_def in -lproj... yes
checking for location of External PROJ.4 data files...
checking for /epsg... no
configure: warning: *** Unable to locate PROJ data files.

            ^^^ $PROJSHARE/epsg when $PROJSHARE defaults to ""

and the GUI "/epsg" looks for the file in:

(the GUI could be altered to use a default if $epsgpath="" ?)

If I add
  --with-proj-share=/usr/share/proj
to the ./configure line it finds it:

checking for location of External PROJ.4 includes...
checking for proj_api.h... yes
checking External PROJ.4 version... 449
checking for location of External PROJ.4 library...
checking for pj_get_def in -lproj... yes
checking for location of External PROJ.4 data files... /usr/share/proj
checking for /usr/share/proj/epsg... yes

.. and the EPSG code browse button works correctly.

Setting --with-proj-share will be ok for packagers on a set platform who
build from a script (e.g. DebianGIS team, Lorenzo's OSX,...) but won't
do much for the typical custom build. Maybe the "warning: ***" line will
encourage folks to set it.

Autodetection is nice..

As this seems like a run-time setable thing: if you put a custom path in
the GUI it should remember it and not just instantly reset to
the default (wrong) path.

Once you do find it and bring up the list, there's a big "Select" button
that doesn't do anything as far as I can tell besides return().
You can't even highlight the code number for cut & paste.

Hamish

> Maybe /usr/local/share needs to be predefined somewhere to catch
> that?

I guess that
$PROJLIB/../share
should be predefined (will catch most cases).

except if you didn't use --with-proj-share=, you probably didn't use
--with-proj-libs= either and the result will be the same.

Worse actually, it parses to: PROJSHARE=/../share

Hamish