[GRASSLIST:7170] crop of raster - once again

Axel_Orth · June 15, 2005, 1:57pm

Hey,
I had some success with cropping my raster maps with borders of municipalities (available as vector - converted to raster) and thought I figured out how it works.

But now I try do do the same with some other data and strange things happen:

import raster map "MAP" - import vector "V" - do raster conversation with vector and get the raster map "V_rast"
set the region: g.region rast=V_rast zoom=V_rast
create the mask: g.copy V_rast,MASK
create new map based on the existing map while only the area of the mask is taken into consideration: r.mapcalc MAP_crop=MAP

Problem: the resulting map MAP_crop is just a colored rectangle - the size of the rectangle is equal to the bounding box of V_rast

By chance I made some errors and somehow got the result i wanted:
instead of the r.mapcalc command shown above I did:

r.mapcalc
MAP_crop=MAP end -> syntax error
r.mapcalc MAP_crop=MAP

MAP looks now exactly the way I wanted. When I leave GRASS, start again then MAP looks like I had when imported it.

I have no clue what's this is all about and hope someone has a idea.

Regards
Axel

Ian_MacMillan1 · June 15, 2005, 5:45pm

Axel, you might try
r.mapcalc MASK='if(V_rast=0, null(), 1)'

I am not sure if this will work, but it is worth a try.

G'luck,
-Ian

On Jun 15, 2005, at 6:57 AM, Axel Orth wrote:

Hey,
I had some success with cropping my raster maps with borders of municipalities (available as vector - converted to raster) and thought I figured out how it works.

But now I try do do the same with some other data and strange things happen:

import raster map "MAP" - import vector "V" - do raster conversation with vector and get the raster map "V_rast"
set the region: g.region rast=V_rast zoom=V_rast
create the mask: g.copy V_rast,MASK
create new map based on the existing map while only the area of the mask is taken into consideration: r.mapcalc MAP_crop=MAP

Problem: the resulting map MAP_crop is just a colored rectangle - the size of the rectangle is equal to the bounding box of V_rast

By chance I made some errors and somehow got the result i wanted:
instead of the r.mapcalc command shown above I did:

r.mapcalc
MAP_crop=MAP end -> syntax error
r.mapcalc MAP_crop=MAP

MAP looks now exactly the way I wanted. When I leave GRASS, start again then MAP looks like I had when imported it.

I have no clue what's this is all about and hope someone has a idea.

Regards
Axel

Axel_Orth · June 15, 2005, 6:45pm

Ian MacMillan schrieb:

Axel, you might try
r.mapcalc MASK='if(V_rast=0, null(), 1)'

I am not sure if this will work, but it is worth a try.

G'luck,
-Ian

On Jun 15, 2005, at 6:57 AM, Axel Orth wrote:

Hey,
I had some success with cropping my raster maps with borders of municipalities (available as vector - converted to raster) and thought I figured out how it works.

But now I try do do the same with some other data and strange things happen:

import raster map "MAP" - import vector "V" - do raster conversation with vector and get the raster map "V_rast"
set the region: g.region rast=V_rast zoom=V_rast
create the mask: g.copy V_rast,MASK
create new map based on the existing map while only the area of the mask is taken into consideration: r.mapcalc MAP_crop=MAP

Problem: the resulting map MAP_crop is just a colored rectangle - the size of the rectangle is equal to the bounding box of V_rast

By chance I made some errors and somehow got the result i wanted:
instead of the r.mapcalc command shown above I did:

r.mapcalc
MAP_crop=MAP end -> syntax error
r.mapcalc MAP_crop=MAP

MAP looks now exactly the way I wanted. When I leave GRASS, start again then MAP looks like I had when imported it.

I have no clue what's this is all about and hope someone has a idea.

Regards
Axel

Hey Ian,
thank you for the suggestion.
I used that command between g.copy V_rast,MASK and r.mapcalc MAP_crop=MAP but that did not change anything.
Have I been supposed to use it that way? I don't work much with GRASS but the command looks like it is about making sure that just pixel that contain information are taken to create the mask. Is that right?

As it did not work out I looked at the MASK after your command and it looked like this: see mask_2.gif - the result of r.mapcalc MAP_crop=MAP looks also that way. Without your command, the MASK looks like: mask.gif - this it the way the mask has to look. This outline should become the new border for the cropped map.

I hope the pictures make things a little easier to understand.

Regards
Axel

(attachments)

H_B · June 16, 2005, 2:09am

I had some success with cropping my raster maps with borders of
municipalities (available as vector - converted to raster) and thought
I figured out how it works.

But now I try do do the same with some other data and strange things
happen:

import raster map "MAP" - import vector "V" - do raster conversation
with vector and get the raster map "V_rast"
set the region: g.region rast=V_rast zoom=V_rast
create the mask: g.copy V_rast,MASK
create new map based on the existing map while only the area of the
mask is taken into consideration: r.mapcalc MAP_crop=MAP

Problem: the resulting map MAP_crop is just a colored rectangle - the
size of the rectangle is equal to the bounding box of V_rast

By chance I made some errors and somehow got the result i wanted:
instead of the r.mapcalc command shown above I did:

r.mapcalc
MAP_crop=MAP end -> syntax error
r.mapcalc MAP_crop=MAP

MAP looks now exactly the way I wanted. When I leave GRASS, start
again then MAP looks like I had when imported it.

I have no clue what's this is all about and hope someone has a idea.

perhaps the resolution is wrong before you run v.to.rast.

r.info V_rast
?

g.region rast=MAP
v.to.rast ...
g.copy V_rast,MASK
g.region rast=V_rast zoom=V_rast
r.mapcalc MAP_crop=MAP
g.remove MASK

Also note v.to.rast only works on features with categories, etc..

Hamish

Axel_Orth · June 16, 2005, 6:53am

Ian MacMillan schrieb:

I guess I don't understand your problem, it looks like you have the area inside the masked boundary as a cropped map, assumably with just one value for all the pixels. This isn't what you wanted?

-ian

On Jun 15, 2005, at 1:50 PM, Axel Orth wrote:

Ian MacMillan schrieb:

Hmm, this sounds like weird behavior with the mask function, which version of grass are you using? Another possibility in the meantime is this:
r.mapcalc MAP_crop = 'if(isnull(MASK), null(), MAP)'

-Ian

On Jun 15, 2005, at 11:42 AM, Axel Orth wrote:

Axel Orth schrieb:

Ian MacMillan schrieb:

Axel, you might try
r.mapcalc MASK='if(V_rast=0, null(), 1)'

I am not sure if this will work, but it is worth a try.

G'luck,
-Ian

On Jun 15, 2005, at 6:57 AM, Axel Orth wrote:

Hey,
I had some success with cropping my raster maps with borders of municipalities (available as vector - converted to raster) and thought I figured out how it works.

But now I try do do the same with some other data and strange things happen:

import raster map "MAP" - import vector "V" - do raster conversation with vector and get the raster map "V_rast"
set the region: g.region rast=V_rast zoom=V_rast
create the mask: g.copy V_rast,MASK
create new map based on the existing map while only the area of the mask is taken into consideration: r.mapcalc MAP_crop=MAP

Problem: the resulting map MAP_crop is just a colored rectangle - the size of the rectangle is equal to the bounding box of V_rast

By chance I made some errors and somehow got the result i wanted:
instead of the r.mapcalc command shown above I did:

r.mapcalc
MAP_crop=MAP end -> syntax error
r.mapcalc MAP_crop=MAP

MAP looks now exactly the way I wanted. When I leave GRASS, start again then MAP looks like I had when imported it.

I have no clue what's this is all about and hope someone has a idea.

Regards
Axel

Hey Ian,
thank you for the suggestion.
I used that command between g.copy V_rast,MASK and r.mapcalc MAP_crop=MAP but that did not change anything.
Have I been supposed to use it that way? I don't work much with GRASS but the command looks like it is about making sure that just pixel that contain information are taken to create the mask. Is that right?

As it did not work out I looked at the MASK after your command and it looked like this: see mask_2.gif - the result of r.mapcalc MAP_crop=MAP looks also that way. Without your command, the MASK looks like: mask.gif - this it the way the mask has to look. This outline should become the new border for the cropped map.

I hope the pictures make things a little easier to understand.

Regards
Axel

sorry, forgot the pictures
<mask_2.gif><mask.gif>

Hey,
I am using GRASS 6.1.cvs running on windows xp via cygwin. I think I got it from https://www.geographie.uni-freiburg.de/~mlechner/CygwinGRASS/

I used your new command instead of my original r.mapcalc and the result was as follows:
MAP_crop: see MAP_crop.gif
So the new command did not change anything.
I need the cropped map outside of GRASS so I can just export the map while the MASK is still there and get a fitting result. But it would be better if the problem can be solved.

Regards
Axel

<MAP_crop.gif>

I have to admit that I did not understand the problem when I posted the first question.
But due to the discussion things are more clear now.

I want a map that looks like: intended.gif
I have a rectangular map and the mask to crop it to look that way.
When I display the map and the mask is active, I get the result you see in the attachment. I am also able to export it. Everything is fine.
BUT
I think r.mapcalc cropped_map=map should give me that result as a new raster file and when I use that command the map becomes pink.

SO it is not such a big problem but still a little bit strange.

Regards
Axel

(attachments)

H_B · June 16, 2005, 11:10pm

On Thu, 16 Jun 2005 08:53:18 +0200
Axel Orth <axel_orth@gmx.de> wrote:

I think r.mapcalc cropped_map=map should give me that result as a new
raster file and when I use that command the map becomes pink.

SO it is not such a big problem but still a little bit strange.

Idea: r.mapcalc doesn't copy the color map along with the data.
Does the range of data etc shown with r.info look consistent?
How about r.univar?

Try this to copy the color map from the original to the new after
r.mapcalc:

r.colors cropped_map rast=map

Hamish

Thomas_Colson · June 17, 2005, 1:47pm

Any idea what could be causing this plethora of compile errors? Platform
is FC4 64 Bit, gdal version is 1.2.5, fftw is 2.1.5...

./configure --with-proj-includes=/usr/local/lib
--with-tcltk-includes=/usr/local/lib --without-postgres --with-freetype
--with-gdal --with-x --enable-largefile --enable-64bit --enable-w11
--with-opengl-libs=/usr/X11R6/lib64
--with-freetype-includes=/usr/include/freetype2 --with-blas --with-cxx

then make results in:

Following modules are missing the 'description.html' file in src code:
v.parallel
v.split
----------------------------------------------------------------------
GRASS GIS compilation log
-------------------------
Started compilation: Fri Jun 17 09:32:05 EDT 2005
Errors in:
/grass6/lib/gmath
/grass6/lib/imagery
/grass6/lib/rst/interp_float
/grass6/display/drivers/XDRIVER/XDRIVER24
/grass6/display/d.mon/pgms
/grass6/imagery/i.class
/grass6/imagery/i.cluster
/grass6/imagery/i.gensig
/grass6/imagery/i.gensigset
/grass6/imagery/i.group
/grass6/imagery/i.his.rgb
/grass6/imagery/i.maxlik
/grass6/imagery/i.ortho.photo/libes
/grass6/imagery/i.ortho.photo/menu
/grass6/imagery/i.ortho.photo/photo.2image
/grass6/imagery/i.ortho.photo/photo.2target
/grass6/imagery/i.ortho.photo/photo.camera
/grass6/imagery/i.ortho.photo/photo.elev
/grass6/imagery/i.ortho.photo/photo.init
/grass6/imagery/i.ortho.photo/photo.rectify
/grass6/imagery/i.ortho.photo/photo.target
/grass6/imagery/i.points
/grass6/imagery/i.rectify
/grass6/imagery/i.rgb.his
/grass6/imagery/i.smap/shapiro
/grass6/imagery/i.target
/grass6/imagery/i.vpoints
/grass6/imagery/i.cca
/grass6/imagery/i.fft
/grass6/imagery/i.ifft
/grass6/imagery/i.pca
/grass6/imagery/i.zc
/grass6/ps/ps.map
/grass6/raster/r.param.scale
/grass6/raster/r.resamp.rst
/grass6/raster/r.in.gdal
/grass6/raster/r.surf.fractal
/grass6/raster/r.surf.gauss
/grass6/raster/r.surf.random
/grass6/raster/r.terraflow
/grass6/vector/v.kernel
/grass6/vector/v.surf.rst
Finished compilation: Fri Jun 17 09:32:34 EDT 2005
(In case of errors please change into the directory with error and run
'make')

cd lib
make
/usr/bin/ld: cannot find -lgrass_gmath
collect2: ld returned 1 exit status

cd rst
make
/usr/bin/ld: cannot find -lgrass_gmath
collect2: ld returned 1 exit status
make[1]: *** [/grass6/dist./lib/libgrass_interpfl.6.1.cvs.so] Error 1
make[1]: Leaving directory `/grass6/lib/rst/interp_float'

cd raster
make
/usr/bin/ld: cannot find -lgrass_gmath
collect2: ld returned 1 exit status

cd ps
make
/usr/bin/ld: cannot find -lgrass_I
collect2: ld returned 1 exit status
make[1]: *** [/grass6/dist./bin/ps.map] Error 1
make[1]: Leaving directory `/grass6/ps/ps.map'

...and so forth.

What's frustrating...is I blew away the OS last night and
reformatted...thinking that I had a trashed OS install 'cuz I was getting
the same errors.....

grass source is latest from CVS.

Thomas_Colson · June 17, 2005, 2:40pm

Yeah, I kinda figured that a great deal of stuff wasn't being built as it
should. So how do you correct the error on the stuff that should be built,
but isn't being built? How can an "out of box" install of Grass6 on a new
install of Fedora have so many library problems? I'd like to think I spent
a great deal of time making sure all the correct versions of the
dependancies were installed prior to the grass build, but it seems like
there are some undocumented secret dependancies....

some libraries did't build, so anything that needs them will fail.

cd lib/gmath
make
gcc -shared -o
/grass6/dist.x86_64-unknown-linux-gnu/lib/libgrass_gmath.6.1.cvs.so
-Wl,--export-dynamic -L/grass6/dist.x86_64-unknown-linux-gnu/lib
-Wl,-rpath-link,/grass6/dist.x86_64-unknown-linux-gnu/lib
OBJ.x86_64-unknown-linux-gnu/brent.o OBJ.x86_64-unknown-linux-gnu/dalloc.o
OBJ.x86_64-unknown-linux-gnu/del2g.o OBJ.x86_64-unknown-linux-gnu/eigen.o
OBJ.x86_64-unknown-linux-gnu/eigen_tools.o
OBJ.x86_64-unknown-linux-gnu/fft.o OBJ.x86_64-unknown-linux-gnu/gauss.o
OBJ.x86_64-unknown-linux-gnu/getg.o OBJ.x86_64-unknown-linux-gnu/ialloc.o
OBJ.x86_64-unknown-linux-gnu/jacobi.o OBJ.x86_64-unknown-linux-gnu/la.o
OBJ.x86_64-unknown-linux-gnu/lu.o OBJ.x86_64-unknown-linux-gnu/max_pow2.o
OBJ.x86_64-unknown-linux-gnu/mult.o OBJ.x86_64-unknown-linux-gnu/rand1.o
OBJ.x86_64-unknown-linux-gnu/svd.o -lgrass_gis -lgrass_datetime -lz
-lfftw -lm && ln -sf libgrass_gmath.6.1.cvs.so
/grass6/dist.x86_64-unknown-linux-gnu/lib/libgrass_gmath.so
/usr/bin/ld: /usr/local/lib/libfftw.a(fftwnd.o): relocation R_X86_64_32
against `a local symbol' can not be used when making a shared object;
recompile with -fPIC
/usr/local/lib/libfftw.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: ***
[/grass6/dist.x86_64-unknown-linux-gnu/lib/libgrass_gmath.6.1.cvs.so]
Error 1

make distclean
?

Hamish

Any idea what could be causing this plethora of compile errors? Platform
is FC4 64 Bit, gdal version is 1.2.5, fftw is 2.1.5...

./configure --with-proj-includes=/usr/local/lib
--with-tcltk-includes=/usr/local/lib --without-postgres --with-freetype
--with-gdal --with-x --enable-largefile --enable-64bit --enable-w11
--with-opengl-libs=/usr/X11R6/lib64
--with-freetype-includes=/usr/include/freetype2 --with-blas --with-cxx

then make results in:

Following modules are missing the 'description.html' file in src code:
v.parallel
v.split
----------------------------------------------------------------------
GRASS GIS compilation log
-------------------------
Started compilation: Fri Jun 17 09:32:05 EDT 2005
Errors in:
/grass6/lib/gmath
/grass6/lib/imagery
/grass6/lib/rst/interp_float
/grass6/display/drivers/XDRIVER/XDRIVER24
/grass6/display/d.mon/pgms
/grass6/imagery/i.class
/grass6/imagery/i.cluster
/grass6/imagery/i.gensig
/grass6/imagery/i.gensigset
/grass6/imagery/i.group
/grass6/imagery/i.his.rgb
/grass6/imagery/i.maxlik
/grass6/imagery/i.ortho.photo/libes
/grass6/imagery/i.ortho.photo/menu
/grass6/imagery/i.ortho.photo/photo.2image
/grass6/imagery/i.ortho.photo/photo.2target
/grass6/imagery/i.ortho.photo/photo.camera
/grass6/imagery/i.ortho.photo/photo.elev
/grass6/imagery/i.ortho.photo/photo.init
/grass6/imagery/i.ortho.photo/photo.rectify
/grass6/imagery/i.ortho.photo/photo.target
/grass6/imagery/i.points
/grass6/imagery/i.rectify
/grass6/imagery/i.rgb.his
/grass6/imagery/i.smap/shapiro
/grass6/imagery/i.target
/grass6/imagery/i.vpoints
/grass6/imagery/i.cca
/grass6/imagery/i.fft
/grass6/imagery/i.ifft
/grass6/imagery/i.pca
/grass6/imagery/i.zc
/grass6/ps/ps.map
/grass6/raster/r.param.scale
/grass6/raster/r.resamp.rst
/grass6/raster/r.in.gdal
/grass6/raster/r.surf.fractal
/grass6/raster/r.surf.gauss
/grass6/raster/r.surf.random
/grass6/raster/r.terraflow
/grass6/vector/v.kernel
/grass6/vector/v.surf.rst
Finished compilation: Fri Jun 17 09:32:34 EDT 2005
(In case of errors please change into the directory with error and run
'make')

cd lib
make
/usr/bin/ld: cannot find -lgrass_gmath
collect2: ld returned 1 exit status

cd rst
make
/usr/bin/ld: cannot find -lgrass_gmath
collect2: ld returned 1 exit status
make[1]: *** [/grass6/dist./lib/libgrass_interpfl.6.1.cvs.so] Error 1
make[1]: Leaving directory `/grass6/lib/rst/interp_float'

cd raster
make
/usr/bin/ld: cannot find -lgrass_gmath
collect2: ld returned 1 exit status

cd ps
make
/usr/bin/ld: cannot find -lgrass_I
collect2: ld returned 1 exit status
make[1]: *** [/grass6/dist./bin/ps.map] Error 1
make[1]: Leaving directory `/grass6/ps/ps.map'

...and so forth.

What's frustrating...is I blew away the OS last night and
reformatted...thinking that I had a trashed OS install 'cuz I was getting
the same errors.....

grass source is latest from CVS.

--
Thomas Colson
Center For Earth Observation
North Carolina State University
Raleigh, NC
(919)515 3434
(919)673 8023
tom_colson@ncsu.edu

Glynn_Clements1 · June 17, 2005, 6:02pm

Thomas Colson wrote:

Yeah, I kinda figured that a great deal of stuff wasn't being built as it
should. So how do you correct the error on the stuff that should be built,
but isn't being built? How can an "out of box" install of Grass6 on a new
install of Fedora have so many library problems? I'd like to think I spent
a great deal of time making sure all the correct versions of the
dependancies were installed prior to the grass build, but it seems like
there are some undocumented secret dependancies....

some libraries did't build, so anything that needs them will fail.

cd lib/gmath
make
gcc -shared -o
/grass6/dist.x86_64-unknown-linux-gnu/lib/libgrass_gmath.6.1.cvs.so

[snip]

/usr/bin/ld: /usr/local/lib/libfftw.a(fftwnd.o): relocation R_X86_64_32
against `a local symbol' can not be used when making a shared object;
recompile with -fPIC

It appears that /usr/local/lib/libfftw.a has been built without the
-fPIC switch, which means that it can only be linked directly into an
executable, not into a shared library. GRASS needs FFTW to be usable
by shared libraries.

Can FFTW be built as a shared library on x86-64? That would be the
simplest solution. Otherwise try adding -fPIC when building FFTW, e.g.

CFLAGS='-g -02 -fPIC' ./configure ...

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

Thomas_Colson · June 18, 2005, 1:49am

Ok, thanks for the tip.

Starting fresh again, on ANOTHER machine.

installed fftw 2.1.5 using -g -O2 -fPIC -D_FILE_OFFSET_BITS=64

The fftw test work fine..

Installed gdal

gdalinfo --version
GDAL 1.2.5.0, released 2004/11/22

tcl/tk 8.4.9, proj4.4.9

reran ldconfig, libgdal.so.1 is in usr/local/lib,

gcc -dumpversion
4.0.0
gcc -dumpmachine
x86_64-redhat-linux (Fedora Core 4)

Same errors! On make (Grass 6.0.0) I get:

Errors in:
/grass/grass-6.0.0/lib/gmath
/grass/grass-6.0.0/lib/imagery
/grass/grass-6.0.0/lib/rst/interp_float
/grass/grass-6.0.0/imagery/i.class
/grass/grass-6.0.0/imagery/i.cluster
/grass/grass-6.0.0/imagery/i.gensig
/grass/grass-6.0.0/imagery/i.gensigset
/grass/grass-6.0.0/imagery/i.group
/grass/grass-6.0.0/imagery/i.his.rgb
/grass/grass-6.0.0/imagery/i.maxlik
/grass/grass-6.0.0/imagery/i.ortho.photo/libes
/grass/grass-6.0.0/imagery/i.ortho.photo/menu
/grass/grass-6.0.0/imagery/i.ortho.photo/photo.2image
/grass/grass-6.0.0/imagery/i.ortho.photo/photo.2target
/grass/grass-6.0.0/imagery/i.ortho.photo/photo.camera
/grass/grass-6.0.0/imagery/i.ortho.photo/photo.elev
/grass/grass-6.0.0/imagery/i.ortho.photo/photo.init
/grass/grass-6.0.0/imagery/i.ortho.photo/photo.rectify
/grass/grass-6.0.0/imagery/i.ortho.photo/photo.target
/grass/grass-6.0.0/imagery/i.points
/grass/grass-6.0.0/imagery/i.rectify
/grass/grass-6.0.0/imagery/i.rgb.his
/grass/grass-6.0.0/imagery/i.smap/shapiro
/grass/grass-6.0.0/imagery/i.target
/grass/grass-6.0.0/imagery/i.vpoints
/grass/grass-6.0.0/imagery/i.cca
/grass/grass-6.0.0/imagery/i.fft
/grass/grass-6.0.0/imagery/i.ifft
/grass/grass-6.0.0/imagery/i.pca
/grass/grass-6.0.0/imagery/i.zc
/grass/grass-6.0.0/ps/ps.map
/grass/grass-6.0.0/raster/r.grow2
/grass/grass-6.0.0/raster/r.param.scale
/grass/grass-6.0.0/raster/r.resamp.rst
/grass/grass-6.0.0/raster/r.in.gdal
/grass/grass-6.0.0/raster/r.surf.fractal
/grass/grass-6.0.0/raster/r.surf.gauss
/grass/grass-6.0.0/raster/r.surf.random
/grass/grass-6.0.0/vector/v.kernel
/grass/grass-6.0.0/vector/v.surf.rst

and:

cd gmath
make
gcc -I/grass/grass-6.0.0/include
-I/grass/grass-6.0.0/dist.x86_64-unknown-linux-gnu/include/grass -g -O2
-Wall -Wconversion -Wno-implicit-int -fPIC -DPACKAGE=\""grasslibs"\"
-DPACKAGE=\""grasslibs"\" -I/grass/grass-6.0.0/include
-I/grass/grass-6.0.0/dist.x86_64-unknown-linux-gnu/include/grass \
-o OBJ.x86_64-unknown-linux-gnu/del2g.o -c del2g.c
In file included from del2g.c:23:
numerical.h:47: error: array type has incomplete element type
del2g.c: In function ‘del2g’:
del2g.c:34: warning: passing argument 1 of ‘G_malloc’ with different width
due to prototype
del2g.c:35: warning: passing argument 1 of ‘G_malloc’ with different width
due to prototype
make: *** [OBJ.x86_64-unknown-linux-gnu/del2g.o] Error 1

and:

cd ps
make
make[1]: Entering directory `/grass/grass-6.0.0/ps/ps.map'
gcc -Wl,--export-dynamic
-L/grass/grass-6.0.0/dist.x86_64-unknown-linux-gnu/lib
-I/usr/local/include -DPACKAGE=\""grassmods"\" -o
/grass/grass-6.0.0/dist.x86_64-unknown-linux-gnu/bin/ps.map
OBJ.x86_64-unknown-linux-gnu/box.o
OBJ.x86_64-unknown-linux-gnu/chk_scale.o
OBJ.x86_64-unknown-linux-gnu/comment.o
OBJ.x86_64-unknown-linux-gnu/distance.o
OBJ.x86_64-unknown-linux-gnu/do_geogrid.o
OBJ.x86_64-unknown-linux-gnu/do_grid.o
OBJ.x86_64-unknown-linux-gnu/do_header.o
OBJ.x86_64-unknown-linux-gnu/do_labels.o
OBJ.x86_64-unknown-linux-gnu/do_masking.o
OBJ.x86_64-unknown-linux-gnu/do_plt.o
OBJ.x86_64-unknown-linux-gnu/do_psfiles.o
OBJ.x86_64-unknown-linux-gnu/do_scalebar.o
OBJ.x86_64-unknown-linux-gnu/do_vectors.o
OBJ.x86_64-unknown-linux-gnu/eps.o OBJ.x86_64-unknown-linux-gnu/error.o
OBJ.x86_64-unknown-linux-gnu/fit_map.o
OBJ.x86_64-unknown-linux-gnu/get_font.o
OBJ.x86_64-unknown-linux-gnu/getgrid.o
OBJ.x86_64-unknown-linux-gnu/get_scalebar.o
OBJ.x86_64-unknown-linux-gnu/gprims.o OBJ.x86_64-unknown-linux-gnu/input.o
OBJ.x86_64-unknown-linux-gnu/key_data.o
OBJ.x86_64-unknown-linux-gnu/main.o
OBJ.x86_64-unknown-linux-gnu/makeprocs.o
OBJ.x86_64-unknown-linux-gnu/map_info.o
OBJ.x86_64-unknown-linux-gnu/map_setup.o
OBJ.x86_64-unknown-linux-gnu/mtextbox.o
OBJ.x86_64-unknown-linux-gnu/outl_io.o
OBJ.x86_64-unknown-linux-gnu/parse_list.o
OBJ.x86_64-unknown-linux-gnu/ps_clrtbl.o
OBJ.x86_64-unknown-linux-gnu/ps_colors.o
OBJ.x86_64-unknown-linux-gnu/ps_fclrtbl.o
OBJ.x86_64-unknown-linux-gnu/ps_header.o
OBJ.x86_64-unknown-linux-gnu/ps_map.o
OBJ.x86_64-unknown-linux-gnu/ps_outline.o
OBJ.x86_64-unknown-linux-gnu/ps_raster.o
OBJ.x86_64-unknown-linux-gnu/ps_vareas.o
OBJ.x86_64-unknown-linux-gnu/ps_vlegend.o
OBJ.x86_64-unknown-linux-gnu/ps_vlines.o
OBJ.x86_64-unknown-linux-gnu/ps_vpoints.o
OBJ.x86_64-unknown-linux-gnu/r_cell.o
OBJ.x86_64-unknown-linux-gnu/r_colortable.o
OBJ.x86_64-unknown-linux-gnu/read_cfg.o
OBJ.x86_64-unknown-linux-gnu/r_group.o
OBJ.x86_64-unknown-linux-gnu/r_header.o
OBJ.x86_64-unknown-linux-gnu/r_info.o
OBJ.x86_64-unknown-linux-gnu/r_labels.o
OBJ.x86_64-unknown-linux-gnu/r_paper.o
OBJ.x86_64-unknown-linux-gnu/r_plt.o OBJ.x86_64-unknown-linux-gnu/r_rgb.o
OBJ.x86_64-unknown-linux-gnu/r_text.o
OBJ.x86_64-unknown-linux-gnu/r_vareas.o
OBJ.x86_64-unknown-linux-gnu/r_vlegend.o
OBJ.x86_64-unknown-linux-gnu/r_vlines.o
OBJ.x86_64-unknown-linux-gnu/r_vpoints.o
OBJ.x86_64-unknown-linux-gnu/r_wind.o OBJ.x86_64-unknown-linux-gnu/scale.o
OBJ.x86_64-unknown-linux-gnu/scan_gis.o
OBJ.x86_64-unknown-linux-gnu/scan_misc.o
OBJ.x86_64-unknown-linux-gnu/scan_ref.o
OBJ.x86_64-unknown-linux-gnu/session.o
OBJ.x86_64-unknown-linux-gnu/show_scale.o
OBJ.x86_64-unknown-linux-gnu/symbol.o
OBJ.x86_64-unknown-linux-gnu/textbox.o OBJ.x86_64-unknown-linux-gnu/vect.o
OBJ.x86_64-unknown-linux-gnu/vector.o OBJ.x86_64-unknown-linux-gnu/yesno.o
-lgrass_vect -lgrass_dig2 -lgrass_dgl -lgrass_rtree -lgrass_linkm
-lgrass_dbmiclient -lgrass_dbmibase -L/usr/local/lib -lgdal -lgrass_gproj
-lproj -L/usr/local/lib -lgdal -lgrass_symb -lgrass_gis -lgrass_datetime
-lz -lgrass_datetime -lgrass_I -lgrass_vask -lncurses -lbsd-compat
-lgrass_gmath -lfftw -lm -lm -lz
/usr/bin/ld: cannot find -lgrass_I
collect2: ld returned 1 exit status
make[1]: *** [/grass/grass-6.0.0/dist.x86_64-unknown-linux-gnu/bin/ps.map]
Error 1
make[1]: Leaving directory `/grass/grass-6.0.0/ps/ps.map'

I'm assuming that the failed build of gmath is creating all the other
errors? What could be causing this? Is there anywork around to getting
these libraries to build somehow?

Thomas Colson wrote:

Yeah, I kinda figured that a great deal of stuff wasn't being built as
it
should. So how do you correct the error on the stuff that should be
built,
but isn't being built? How can an "out of box" install of Grass6 on a
new
install of Fedora have so many library problems? I'd like to think I
spent
a great deal of time making sure all the correct versions of the
dependancies were installed prior to the grass build, but it seems like
there are some undocumented secret dependancies....

some libraries did't build, so anything that needs them will fail.

cd lib/gmath
make
gcc -shared -o
/grass6/dist.x86_64-unknown-linux-gnu/lib/libgrass_gmath.6.1.cvs.so

[snip]

/usr/bin/ld: /usr/local/lib/libfftw.a(fftwnd.o): relocation R_X86_64_32
against `a local symbol' can not be used when making a shared object;
recompile with -fPIC

It appears that /usr/local/lib/libfftw.a has been built without the
-fPIC switch, which means that it can only be linked directly into an
executable, not into a shared library. GRASS needs FFTW to be usable
by shared libraries.

Can FFTW be built as a shared library on x86-64? That would be the
simplest solution. Otherwise try adding -fPIC when building FFTW, e.g.

CFLAGS='-g -02 -fPIC' ./configure ...

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

--
Thomas Colson
Center For Earth Observation
North Carolina State University
Raleigh, NC
(919)515 3434
(919)673 8023
tom_colson@ncsu.edu

Thomas_Colson · June 18, 2005, 3:35am

tried that. Tried ./configure --without-fftw AND --without-gdal (or
with-gdal=no...interesting enough, either of the disable gdal syntaxes
still bombs with "Can't find GDAL")

Same errors. Could this be due to the version of GCC (4.0)? Or the version
of Fedora? Unfortunately, getting FC3 working on my hardware is harder
than getting grass to work (Dual Xeon 3.6, 256 MB vid card, hardware
RAID...) and FC4 works perfectly out of the box. The precompiled binaries
at mappinghacks.com of course are not applicable to my distro of linux
(worked great on a FC3 laptop install with Grass 6.1).

I'm getting pretty desperate here....I MUST get this working sometime this
weekend. Basically, the only thing I need working is v.in.ascii and
r.surf.rst (and NVIZ...hence...a GUI). The goal here is speedy
interpolation of LIDAR elevation points into DEMs using spline, ideally
with libraries optimized for large file support and the 64 bit
architecture.

Or....is 6.0.0 compatible with fftw 3.0 yet?

I would guess everything else fails becasue gmath fails.

If you don't need the i.fft modules for satellite imagery processing,
just configure grass without it:

./configure --without-fftw

only a couple of modules use it.

(good to get it fixed though if it is a bug)

Hamish

--
Thomas Colson
Center For Earth Observation
North Carolina State University
Raleigh, NC
(919)515 3434
(919)673 8023
tom_colson@ncsu.edu

H_B · June 18, 2005, 5:19am

tried that. Tried ./configure --without-fftw AND --without-gdal (or
with-gdal=no...interesting enough, either of the disable gdal syntaxes
still bombs with "Can't find GDAL")

GDAL is not optional in GRASS 6. --without-gdal should be removed but
--with-gdal=where/it/is must stay.

Same errors. Could this be due to the version of GCC (4.0)? Or the

Does FC4 provide a gcc-3.3 package, even if not used by default?

cd gmath
make

[...]

In file included from del2g.c:23:
numerical.h:47: error: array type has incomplete element type

looking at the CVS record for lib/gmath/numerical.h we see Brad put
in a GCC4 fix for that file 3 weeks ago.

http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/gmath/numerical.h

How old's your 6.1 snapshot?

version of Fedora? Unfortunately, getting FC3 working on my hardware
is harder than getting grass to work (Dual Xeon 3.6, 256 MB vid card,
hardware RAID...) and FC4 works perfectly out of the box. The
precompiled binaries at mappinghacks.com of course are not applicable
to my distro of linux (worked great on a FC3 laptop install with Grass
6.1).

I'm getting pretty desperate here....I MUST get this working sometime
this weekend. Basically, the only thing I need working is v.in.ascii
and r.surf.rst (and NVIZ...hence...a GUI). The goal here is speedy
interpolation of LIDAR elevation points into DEMs using spline,
ideally with libraries optimized for large file support and the 64 bit
architecture.

(try for yourself first, but be warned:)
Apparently v.in.ascii is broken this weekend. Try a snapshot from a few
weeks back. If you can't find one, grab from the cvs using a specific
date, e.g. I know it was ok on 17 May. (cvs checkout -D datespec)
See the CVS page for info: http://grass.ibiblio.org/devel/cvs.php

but then, some of Brad's 64bit & GCC4 fixes have come in only this month.

So if v.in.ascii doesn't work for you, you'll have to use an old CVS
snapshot and merge in any GCC4 fixes since then. ? catch 22..

After generating the surface you can copy the mapset to another computer
for NVIZ. Just worry about the surface. You're not going to get very far
without lib/gmath, so focus on that first. I expect v.in.ascii will be
working soon (but I'm not working on it).

Or....is 6.0.0 compatible with fftw 3.0 yet?

Nope.

best of luck,
Hamish

Glynn_Clements1 · June 18, 2005, 8:11am

Thomas Colson wrote:

cd gmath
make
gcc -I/grass/grass-6.0.0/include
-I/grass/grass-6.0.0/dist.x86_64-unknown-linux-gnu/include/grass -g -O2
-Wall -Wconversion -Wno-implicit-int -fPIC -DPACKAGE=\""grasslibs"\"
-DPACKAGE=\""grasslibs"\" -I/grass/grass-6.0.0/include
-I/grass/grass-6.0.0/dist.x86_64-unknown-linux-gnu/include/grass \
-o OBJ.x86_64-unknown-linux-gnu/del2g.o -c del2g.c
In file included from del2g.c:23:
numerical.h:47: error: array type has incomplete element type

Odd.

Try removing the following lines from lib/gmath/numeric.h:

  /* jacobi.c */
  #define MC 50
  extern char outputfile[50];
  extern char groupname[50], subgroup[50], signame[50];

These declarations don't appear to be used anywhere. They probably
relate to having extracted the code in jacobi.c from elsewhere.

I'm assuming that the failed build of gmath is creating all the other
errors?

Probably.

What could be causing this?

The above error regarding line 47 of numerical.h. line 47 appears
empty, but the jacobi.c section is the closest match,

Is there anywork around to getting these libraries to build somehow?

Eliminate the numerical.h error.

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

Glynn_Clements1 · June 18, 2005, 8:13am

Thomas Colson wrote:

tried that. Tried ./configure --without-fftw AND --without-gdal (or
with-gdal=no...interesting enough, either of the disable gdal syntaxes
still bombs with "Can't find GDAL")

GDAL is a non-optional dependency in 6.x. The --with-gdal switch can
be used to specify a specific gdal-config script, but --with-gdal=no
(for which --without-gdal is an alias) isn't legal.

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

Glynn_Clements1 · June 18, 2005, 8:16am

Hamish wrote:

> tried that. Tried ./configure --without-fftw AND --without-gdal (or
> with-gdal=no...interesting enough, either of the disable gdal syntaxes
> still bombs with "Can't find GDAL")

GDAL is not optional in GRASS 6. --without-gdal should be removed but
--with-gdal=where/it/is must stay.

autoconf-generated configure scripts automatically accept
--without-foo as an alias for --with-foo=no.

However, the error message could be clarified, e.g.

  if test "$with_gdal" = "no" ; then
    AC_MSG_ERROR(GDAL is a non-optional dependency)
  else

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

Thomas_Colson · June 18, 2005, 3:57pm

6.1 snapshot...a few hours? Just updated. Same errors with 6.0 and 6.1....

I'll try that fix tomorrow morning...

Replying to list so answers can be searchable in archive for those blazing
a trail behind me.

tried that. Tried ./configure --without-fftw AND --without-gdal (or
with-gdal=no...interesting enough, either of the disable gdal syntaxes
still bombs with "Can't find GDAL")

GDAL is not optional in GRASS 6. --without-gdal should be removed but
--with-gdal=where/it/is must stay.

Same errors. Could this be due to the version of GCC (4.0)? Or the

Does FC4 provide a gcc-3.3 package, even if not used by default?

cd gmath
make

[...]

In file included from del2g.c:23:
numerical.h:47: error: array type has incomplete element type

looking at the CVS record for lib/gmath/numerical.h we see Brad put
in a GCC4 fix for that file 3 weeks ago.

http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/gmath/numerical.h

How old's your 6.1 snapshot?

version of Fedora? Unfortunately, getting FC3 working on my hardware
is harder than getting grass to work (Dual Xeon 3.6, 256 MB vid card,
hardware RAID...) and FC4 works perfectly out of the box. The
precompiled binaries at mappinghacks.com of course are not applicable
to my distro of linux (worked great on a FC3 laptop install with Grass
6.1).

I'm getting pretty desperate here....I MUST get this working sometime
this weekend. Basically, the only thing I need working is v.in.ascii
and r.surf.rst (and NVIZ...hence...a GUI). The goal here is speedy
interpolation of LIDAR elevation points into DEMs using spline,
ideally with libraries optimized for large file support and the 64 bit
architecture.

(try for yourself first, but be warned:)
Apparently v.in.ascii is broken this weekend. Try a snapshot from a few
weeks back. If you can't find one, grab from the cvs using a specific
date, e.g. I know it was ok on 17 May. (cvs checkout -D datespec)
See the CVS page for info: http://grass.ibiblio.org/devel/cvs.php

but then, some of Brad's 64bit & GCC4 fixes have come in only this month.

So if v.in.ascii doesn't work for you, you'll have to use an old CVS
snapshot and merge in any GCC4 fixes since then. ? catch 22..

After generating the surface you can copy the mapset to another computer
for NVIZ. Just worry about the surface. You're not going to get very far
without lib/gmath, so focus on that first. I expect v.in.ascii will be
working soon (but I'm not working on it).

Or....is 6.0.0 compatible with fftw 3.0 yet?

Nope.

best of luck,
Hamish

--
Thomas Colson
Center For Earth Observation
North Carolina State University
Raleigh, NC
(919)515 3434
(919)673 8023
tom_colson@ncsu.edu

H_B · June 19, 2005, 3:37am

> cd gmath
> make
> gcc -I/grass/grass-6.0.0/include
> -I/grass/grass-6.0.0/dist.x86_64-unknown-linux-gnu/include/grass -g -O2
> -Wall -Wconversion -Wno-implicit-int -fPIC -DPACKAGE=\""grasslibs"\"
> -DPACKAGE=\""grasslibs"\" -I/grass/grass-6.0.0/include
> -I/grass/grass-6.0.0/dist.x86_64-unknown-linux-gnu/include/grass \
> -o OBJ.x86_64-unknown-linux-gnu/del2g.o -c del2g.c
> In file included from del2g.c:23:
> numerical.h:47: error: array type has incomplete element type

Odd.

Try removing the following lines from lib/gmath/numeric.h:

  /* jacobi.c */
  #define MC 50
  extern char outputfile[50];
  extern char groupname[50], subgroup[50], signame[50];

...

> What could be causing this?

The above error regarding line 47 of numerical.h. line 47 appears
empty, but the jacobi.c section is the closest match,

Note that in the 6.0.0 source (inferred from the above gcc command) line 47
read as follows:

extern struct Command_keys Command_keys;

This is the line Brad removed 3 weeks ago. The CVS commit comment is
"Remove unused Command_keys for GCC4 compatibility."

http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/gmath/numerical.h.diff?r1=2.0&r2=2.1&diff_format=u

I postulate that the problem is already fixed?

Thomas wrote:

In file included from del2g.c:23:
numerical.h:47: error: array type has incomplete element type

..

6.1 snapshot...a few hours? Just updated.

..

Same errors with 6.0 and 6.1....

Do you still see the error in numerical.h line 47 using the latest CVS??

Hamish

Glynn_Clements1 · June 19, 2005, 4:11am

Hamish wrote:

> > What could be causing this?
>
> The above error regarding line 47 of numerical.h. line 47 appears
> empty, but the jacobi.c section is the closest match,

Note that in the 6.0.0 source (inferred from the above gcc command) line 47
read as follows:

extern struct Command_keys Command_keys;

Ah, that is a far more likely candidate.

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

Thomas_Colson · June 19, 2005, 10:59pm

Removing

Try removing the following lines from lib/gmath/numeric.h:

        /* jacobi.c */
        #define MC 50
        extern char outputfile[50];
        extern char groupname[50], subgroup[50], signame[50];

From numeric.h seemed to do the trick, in 6.0.0 and 6.1 "unstable" (latest

CVS).

thanks for all your replies....look forward to my incessant complaining
about v.in.ascii soon.......

> cd gmath
> make
> gcc -I/grass/grass-6.0.0/include
> -I/grass/grass-6.0.0/dist.x86_64-unknown-linux-gnu/include/grass -g
-O2
> -Wall -Wconversion -Wno-implicit-int -fPIC
-DPACKAGE=\""grasslibs"\"
> -DPACKAGE=\""grasslibs"\" -I/grass/grass-6.0.0/include
> -I/grass/grass-6.0.0/dist.x86_64-unknown-linux-gnu/include/grass \
> -o OBJ.x86_64-unknown-linux-gnu/del2g.o -c del2g.c
> In file included from del2g.c:23:
> numerical.h:47: error: array type has incomplete element type

Odd.

Try removing the following lines from lib/gmath/numeric.h:

  /* jacobi.c */
  #define MC 50
  extern char outputfile[50];
  extern char groupname[50], subgroup[50], signame[50];

...

> What could be causing this?

The above error regarding line 47 of numerical.h. line 47 appears
empty, but the jacobi.c section is the closest match,

Note that in the 6.0.0 source (inferred from the above gcc command) line
47
read as follows:

extern struct Command_keys Command_keys;

This is the line Brad removed 3 weeks ago. The CVS commit comment is
"Remove unused Command_keys for GCC4 compatibility."

http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/gmath/numerical.h.diff?r1=2.0&r2=2.1&diff_format=u

I postulate that the problem is already fixed?

Thomas wrote:

In file included from del2g.c:23:
numerical.h:47: error: array type has incomplete element type

..

6.1 snapshot...a few hours? Just updated.

..

Same errors with 6.0 and 6.1....

Do you still see the error in numerical.h line 47 using the latest CVS??

Hamish

--
Thomas Colson
Center For%2