[GRASS5] r.in.gdal

Folks,

I have updated r.in.gdal in CVS to first search in $GISBASE/lib for a
libgdal.1.1.so file, and done a simple test.

I have also prepared a shared library for linux for initial testing:

  ftp://gdal.velocet.ca/pub/outgoing/libgdal-linux-grass.tar.gz

This is more or less a normal libgdal but with the following caveats:

o libpng, libtiff, libgeotiff, libjpeg, libungif are builtin to limit
   the number of dependencies.

o libgrass support is disabled (no need for this in r.in.gdal, and it
   might cause all sorts of odd problems).

o No OGR (vector) support, since r.in.gdal wouldn't utilize it anyways.

The dependencies of this library look like this:

warmerda@gdal3[195]% ldd ~/gdal/libgdal.1.1.so
        libz.so.1 => /usr/lib/libz.so.1 (0x40198000)
        libdl.so.2 => /lib/libdl.so.2 (0x401a7000)
        libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x401aa000)
        libm.so.6 => /lib/libm.so.6 (0x401f0000)
        libc.so.6 => /lib/libc.so.6 (0x4020d000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

The only part of this I don't like is the C++ shared library. It is installed
on most modern Linux system, but some may lack it. If so, grab the following
and put it in /usr/lib or /usr/local/lib (if in your LD_LIBRARY_PATH):

  ftp://gdal.velocet.ca/pub/outgoing/libstdc++-libc6.2-2.so.3

If you update to the latest r.in.gdal from CVS you can just drop
the libgdal.1.1.so into $GISBASE/lib. If you have the last beta you can
still use by putting it somewhere in the library path, perhaps /usr/local/lib.

I would appreciate feedback from people who try out r.in.gdal with this new
shared library. If things go well it should be sufficient to add the library
to the $GISBASE/lib directory in the next binary build, and I am prepared to
build libraries for Solaris and IRIX as well.

I saw in the bugs list problems with r.in.tiff, and r.in.png. Note that
r.in.gdal reads TIFF and 24bit png files.

If all goes well with r.in.gdal, I would also like to implement an r.out.gdal
and eventually import and export programs using the OGR library for various
vector formats. A list of GDAL supported file formats can be found at:

  http://www.remotesensing.org/gdal/formats_list.html

and it includes GeoTIFF, Arc/Info Binary Grid, CEOS (including SAR), DOQ,
DTED, Eosat Fast Format, ESRI BIL (.hdr labelled), GIF, Erdas Imagine, JPEG,
PNG, Netpbm, and SDTS DEM.

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerda
and watch the world go round - Rush | Geospatial Programmer for Rent

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Hi Frank,

as being very interested in your growing GIS libraries
I have tried below improvement:

On Thu, Jan 18, 2001 at 10:34:48AM -0500, Frank Warmerdam wrote:

Folks,

I have updated r.in.gdal in CVS to first search in $GISBASE/lib for a
libgdal.1.1.so file, and done a simple test.

Yep! It is detected.

I have also prepared a shared library for linux for initial testing:

  ftp://gdal.velocet.ca/pub/outgoing/libgdal-linux-grass.tar.gz

This is more or less a normal libgdal but with the following caveats:

o libpng, libtiff, libgeotiff, libjpeg, libungif are builtin to limit
   the number of dependencies.

o libgrass support is disabled (no need for this in r.in.gdal, and it
   might cause all sorts of odd problems).

o No OGR (vector) support, since r.in.gdal wouldn't utilize it anyways.

The dependencies of this library look like this:

warmerda@gdal3[195]% ldd ~/gdal/libgdal.1.1.so
        libz.so.1 => /usr/lib/libz.so.1 (0x40198000)
        libdl.so.2 => /lib/libdl.so.2 (0x401a7000)
        libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x401aa000)
        libm.so.6 => /lib/libm.so.6 (0x401f0000)
        libc.so.6 => /lib/libc.so.6 (0x4020d000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

The only part of this I don't like is the C++ shared library. It is installed
on most modern Linux system, but some may lack it. If so, grab the following
and put it in /usr/lib or /usr/local/lib (if in your LD_LIBRARY_PATH):

  ftp://gdal.velocet.ca/pub/outgoing/libstdc++-libc6.2-2.so.3

If you update to the latest r.in.gdal from CVS you can just drop
the libgdal.1.1.so into $GISBASE/lib. If you have the last beta you can
still use by putting it somewhere in the library path, perhaps /usr/local/lib.

I would appreciate feedback from people who try out r.in.gdal with this new
shared library. If things go well it should be sufficient to add the library
to the $GISBASE/lib directory in the next binary build, and I am prepared to
build libraries for Solaris and IRIX as well.

I saw in the bugs list problems with r.in.tiff, and r.in.png. Note that
r.in.gdal reads TIFF and 24bit png files.

If all goes well with r.in.gdal, I would also like to implement an r.out.gdal
and eventually import and export programs using the OGR library for various
vector formats. A list of GDAL supported file formats can be found at:

  http://www.remotesensing.org/gdal/formats_list.html

and it includes GeoTIFF, Arc/Info Binary Grid, CEOS (including SAR), DOQ,
DTED, Eosat Fast Format, ESRI BIL (.hdr labelled), GIF, Erdas Imagine, JPEG,
PNG, Netpbm, and SDTS DEM.

Frank, just interested: do you *plan* to add HDF support? Otherwise
we would have to re-activate the HDF3.2-r.[in|out].hdf modules which
might need heavy updating.

Thanks for providing GDAL! Of course I will add it to the Linux binaries
as you requested. Only a version problem with libstdc++-libc6.2-2.so.3
may occur (here I had a slightly older version).

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Markus Neteler wrote:

> I have updated r.in.gdal in CVS to first search in $GISBASE/lib for a
> libgdal.1.1.so file, and done a simple test.

Yep! It is detected.

Excellent!

Frank, just interested: do you *plan* to add HDF support? Otherwise
we would have to re-activate the HDF3.2-r.[in|out].hdf modules which
might need heavy updating.

I hadn't been expecting to do it within the next few weeks. I presume
you mean HDF EOS support, not just regular HDF, right? If you can patch
up the existing HDF support fairly easily then you should do that. If
it needs a large chunk of work, then come back to me and I can take a
crack at doing it within GDAL instead.

Thanks for providing GDAL! Of course I will add it to the Linux binaries
as you requested. Only a version problem with libstdc++-libc6.2-2.so.3
may occur (here I had a slightly older version).

Damn. I was afraid of this. Perhaps we should push ahead to having
$GISBASE/lib added to the LD_LIBRARY_PATH within the GRASS environment
before the next beta, and putting the C++ runtime library there.

Alternatively, if anyone knows an easy way for me to link it in statically
I can try to fix up the shared library.

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerda
and watch the world go round - Rush | Geospatial Programmer for Rent

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

On Fri, Jan 19, 2001 at 04:28:13PM -0500, Frank Warmerdam wrote:

Markus Neteler wrote:
> > I have updated r.in.gdal in CVS to first search in $GISBASE/lib for a
> > libgdal.1.1.so file, and done a simple test.
>
> Yep! It is detected.

Excellent!

> Frank, just interested: do you *plan* to add HDF support? Otherwise
> we would have to re-activate the HDF3.2-r.[in|out].hdf modules which
> might need heavy updating.

I hadn't been expecting to do it within the next few weeks. I presume
you mean HDF EOS support, not just regular HDF, right? If you can patch
up the existing HDF support fairly easily then you should do that. If
it needs a large chunk of work, then come back to me and I can take a
crack at doing it within GDAL instead.

O.k., so we postpone it slightly. Perhaps it is not too difficult to
update the existing GRASS modules.

> Thanks for providing GDAL! Of course I will add it to the Linux binaries
> as you requested. Only a version problem with libstdc++-libc6.2-2.so.3
> may occur (here I had a slightly older version).

Damn. I was afraid of this. Perhaps we should push ahead to having
$GISBASE/lib added to the LD_LIBRARY_PATH within the GRASS environment
before the next beta, and putting the C++ runtime library there.

This sounds the best at time. Any idea how to do that? I guess
it is to be done in GISBASE/etc/Init.sh (hi Justin).

Alternatively, if anyone knows an easy way for me to link it in statically
I can try to fix up the shared library.

Best regards,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Hi Markus and Frank

Markus Neteler wrote:

On Fri, Jan 19, 2001 at 04:28:13PM -0500, Frank Warmerdam wrote:
> Markus Neteler wrote:
> > Thanks for providing GDAL! Of course I will add it to the Linux
> > binaries as you requested. Only a version problem with
> > libstdc++-libc6.2-2.so.3 may occur (here I had a slightly older
> > version).
>
> Damn. I was afraid of this. Perhaps we should push ahead to having
> $GISBASE/lib added to the LD_LIBRARY_PATH within the GRASS
> environment before the next beta, and putting the C++ runtime
> library there.

This sounds the best at time. Any idea how to do that? I guess
it is to be done in GISBASE/etc/Init.sh (hi Justin).

Sorry for the late reply, but do you still want this added to
LD_LIBRARY_PATH?

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Justin Hickey wrote:

Sorry for the late reply, but do you still want this added to
LD_LIBRARY_PATH?

Justin,

I did it at the time, but forgot to check it in. It's there now. Could you
glance at init.sh and verify that my approach to updating LD_LIBRARY_PATH is
acceptable?

Thanks,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerda
and watch the world go round - Rush | Geospatial Programmer for Rent

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Hi Frank

Frank Warmerdam wrote:

I did it at the time, but forgot to check it in. It's there now.
Could you glance at init.sh and verify that my approach to updating
LD_LIBRARY_PATH is acceptable?

It looks fine to me, thanks for updating it.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'