[GRASS-user] Compiling winGRASS with OSGEO4w- #2

[Helmut Kudrnovsky]

Hi Luisa,

>Hi,
>Back again with this issue. Thanks Helmut and Antonio for your help but so
>far I haven't manage to compile GRASS using OSGEO4W. (and it seems that
>neither Antonio)
>Since Glynn told me that I might have some issues with newer versions I
>decided to use older versions of prebuilt and MinGW packages.
[...]
>Ok So the problem now is: libgrass_rowio.dll. How can I debug this dll and
>How can I create it? And what might be happening?
>This was a HUGE IMPROVE :)
>
>Thank you
>Luisa

I've done a completly new installation of my osgeo4w-installation on my 
WinVista32-box to get the latest osgeo4w-setup and followed the 
wiki (http://trac.osgeo.org/grass/wiki/CompileOnWindows#Pre-builtBinaries) for 
installing
all dependencies, prebuilt libraries and utilities etc.

I've choosen the way with TortoiseSVN to get a completly new svn-checkout at 
revision 42566
(see the wiki B) Graphical user interface based:
Alternatively, get TortoiseSVN, a plugin for Windows 
Explorer, which can be used for managing the local source tree.) in 
C:\OSGeo4W\usr\src\grass64svn.

I can't reproduce your error, Grass64 is compiling fine and I'm able to start 
Grass64 in 
C:\OSGeo4W\apps\grass\bin (in the osgeo4w-msys-shell) by grass64 -wx.

so I would suggest a completely new setup of the compiling-environment 
following the
wiki (http://trac.osgeo.org/grass/wiki/CompileOnWindows).

maybe there was any error in the setup of the compiling-environment.

HTH
Helmut
___
WEB.DE DSL ab 19,99 Euro/Monat. Bis zu 150,- Euro Startguthaben und
50,- Euro Geldprämie inklusive! https://freundschaftswerbung.web.de


smime.p7s
Description: S/MIME Cryptographic Signature
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] NVIZ help: fly keeps resetting/jumping back to center.

[Ken Kwasnicki]

Yes, I my slackware can run
32bit apps. I tried recompiling grass without the --enable-64bit option
but still had the same nviz problem , although i expect i'm still
compiling to 64bit.  

However, I've looked at the togl_flythrough.c code and found the
problem.  Or at least found a change the fixes this on my system.

I had added some debug output to mouse_valuator just to show the
thisTime value, initially I just wanted to see if I would even see the
output from a printf statement when running nviz.  What I noticed was
that the "seconds" value for thisTime was not incrementing, only the
decimal part was changing, which I guess is why the view would return
to its original position after a 1 second lapse.

in the function "this_time" the time values are being cast to float
which is maxing out so i changed them to double which is the return
value anyway.
so, i changed this line [320]:
    return ((float)tv.tv_sec + ((float)tv.tv_usec / 100.0));
to:
    return ((double)tv.tv_sec + ((double)tv.tv_usec / 100.0));

and that appears to have fixed the problem.  the same change may need
to be made for the MINGW32 version of the code, but I left that alone.

i've made this change in my download of the 6.4.0RC6 version of the
code but for now I'll leave it up to you, or others to make this change
as I'm currently not set up to submit code.

thanks!
ken


On 06/15/2010 12:53 PM, Maris Nartiss wrote:

  Hello,
at first - You can compile 32bit version on 64bit machine (if it's
possible on Slackware).

Second - once I took a look at code. It was not good, still I didn't
managed to find the root cause.
Fly mode is TCL/C hybrid.
TCL part is here:
http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/visualization/nviz/scripts
(flythrough.tcl)
Some support is located in nviz/src/ (togl_flythrough.c)
Main rendering is done by OGSF lib/ogsf

OGSF should be fine, problem is somewhere in nviz part. Probably in
C/TCL interaction.

Good luck.
If You need some help with coding, feel free to as at grass-dev ML. We
are short on resources and thys any help is wecomed.

Maris.


2010/6/15, Ken Kwasnicki :
  
  
Hi Maris,
Thanks for the reply!  Too bad. I guess I'll have to install on a 32bit
system.  For what it's worth my system is Slackware 13.0 64bit and also
Nvidia driver, so nothing really new to add to the bug report other than the
variance in linux distribution.

Any speculation where this bug might occur in the nviz code?  Just in case
I'm feeling ambitious enough to take a crack at debugging it.

Thanks,
Ken


On 06/15/2010 12:14 AM, Maris Nartiss wrote:


  
Known issue, currently no fix.

http://trac.osgeo.org/grass/ticket/46

Maris.


2010/6/14, Kwas :

  
  

Helo,
I've used NVIZ in the past and not had this problem but after rebuilding
Grass/Nviz for a new system (Slackware 13 64bit)  I now find when I try
to
"fly" to move the landscape it keeps resetting back to its originall
position after a few frames.ie: it will start to move in the
direction
of my mouse motion but then keeps jumping back so that I am unable to
zoom
in or position the view where I want.

Has anybody seen this problem before or know what I should do to fix it?
Appreciate any assistance.
Thanks,
Ken
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/NVIZ-help-fly-keeps-resetting-jumping-back-to-center-tp5178852p5178852.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user



  
  

  

  
  
  



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] NVIZ help: fly keeps resetting/jumping back to center.

[Maris Nartiss]

Hello,
at first - You can compile 32bit version on 64bit machine (if it's
possible on Slackware).

Second - once I took a look at code. It was not good, still I didn't
managed to find the root cause.
Fly mode is TCL/C hybrid.
TCL part is here:
http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/visualization/nviz/scripts
(flythrough.tcl)
Some support is located in nviz/src/ (togl_flythrough.c)
Main rendering is done by OGSF lib/ogsf

OGSF should be fine, problem is somewhere in nviz part. Probably in
C/TCL interaction.

Good luck.
If You need some help with coding, feel free to as at grass-dev ML. We
are short on resources and thys any help is wecomed.

Maris.


2010/6/15, Ken Kwasnicki :
> Hi Maris,
> Thanks for the reply!  Too bad. I guess I'll have to install on a 32bit
> system.  For what it's worth my system is Slackware 13.0 64bit and also
> Nvidia driver, so nothing really new to add to the bug report other than the
> variance in linux distribution.
>
> Any speculation where this bug might occur in the nviz code?  Just in case
> I'm feeling ambitious enough to take a crack at debugging it.
>
> Thanks,
> Ken
>
>
> On 06/15/2010 12:14 AM, Maris Nartiss wrote:
>>
>> Known issue, currently no fix.
>>
>> http://trac.osgeo.org/grass/ticket/46
>>
>> Maris.
>>
>>
>> 2010/6/14, Kwas :
>>
>>>
>>> Helo,
>>> I've used NVIZ in the past and not had this problem but after rebuilding
>>> Grass/Nviz for a new system (Slackware 13 64bit)  I now find when I try
>>> to
>>> "fly" to move the landscape it keeps resetting back to its originall
>>> position after a few frames.ie: it will start to move in the
>>> direction
>>> of my mouse motion but then keeps jumping back so that I am unable to
>>> zoom
>>> in or position the view where I want.
>>>
>>> Has anybody seen this problem before or know what I should do to fix it?
>>> Appreciate any assistance.
>>> Thanks,
>>> Ken
>>> --
>>> View this message in context:
>>> http://osgeo-org.1803224.n2.nabble.com/NVIZ-help-fly-keeps-resetting-jumping-back-to-center-tp5178852p5178852.html
>>> Sent from the Grass - Users mailing list archive at Nabble.com.
>>> ___
>>> grass-user mailing list
>>> grass-user@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>>
>>
>>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Error using r.mapcalc

[Pedro Roma]

Hi

I tried to use r.mapcalc in my GRASS6.4.RC5 in Linux and I got this error at
terminal:
syntax error, unexpected '-', expecting NAME or STRING
Parse error

And the following in command output window:
Traceback (most recent call last):
  File "/usr/local/grass-6.4.0svn/etc/wxpython/wxgui.py",
line 473, in OnRunCmd

self.goutput.RunCmd(cmd, switchPage=False)
  File "/usr/local/grass-6.4.0svn/etc/wxpython/gui_modules/g
output.py", line 354, in RunCmd

menuform.GUI().ParseCommand(cmdlist, parentframe=self)
  File "/usr/local/grass-6.4.0svn/etc/wxpython/gui_modules/m
enuform.py", line 1828, in ParseCommand

xml.sax.parseString(getInterfaceDescription(cmd[0]),
  File "/usr/local/grass-6.4.0svn/etc/wxpython/gui_modules/m
enuform.py", line 1764, in getInterfaceDescription

raise IOError, _("Unable to fetch interface description for
command '%s'.") % cmd
IOError
:
Unable to fetch interface description for command
'r.mapcalc'.


Then I runned r.mapcalc at my GRASS OSGEO4w installation and I got the
following error:
Traceback (most recent call last):
  File "C:/osgeo4w/apps/grass/grass-6.4.0svn/etc/wxpython/wx
gui.py", line 473, in OnRunCmd

self.goutput.RunCmd(cmd, switchPage=False)
  File "C:\osgeo4w\apps\grass\grass-6.4.0svn\etc\wxpython\gu
i_modules\goutput.py", line 354, in RunCmd

menuform.GUI().ParseCommand(cmdlist, parentframe=self)
  File "C:\osgeo4w\apps\grass\grass-6.4.0svn\etc\wxpython\gu
i_modules\menuform.py", line 1863, in ParseCommand

xml.sax.parseString(getInterfaceDescription(cmd[0]).decode(e
nc).split('\n',1)[1].replace('', '\n', 1).encode("utf-8"),
  File "C:\osgeo4w\apps\grass\grass-6.4.0svn\etc\wxpython\gu
i_modules\menuform.py", line 1802, in
getInterfaceDescription

raise IOError, _("Unable to fetch interface description for
command '%s'.") % cmd
IOError
:
Unable to fetch interface description for command
'r.mapcalc'.

>From http://grass.itc.it/grass64/binary/mswindows/native/ I installed
WinGRASS6.4RC6-1 and I got exacly the same error.

Can anyone tell me if this is expected to happen? or if there is some sort
of "fix" for this?

Thanks

Best regards,
Pedro
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] NVIZ help: fly keeps resetting/jumping back to center.

[Ken Kwasnicki]

Hi Maris,
Thanks for the reply!  Too bad. I guess I'll have to install on a 32bit
system.  For what it's worth my system is Slackware 13.0 64bit and also
Nvidia driver, so nothing really new to add to the bug report other
than the variance in linux distribution.

Any speculation where this bug might occur in the nviz code?  Just in
case I'm feeling ambitious enough to take a crack at debugging it.

Thanks,
Ken


On 06/15/2010 12:14 AM, Maris Nartiss wrote:

  Known issue, currently no fix.

http://trac.osgeo.org/grass/ticket/46

Maris.


2010/6/14, Kwas :
  
  

Helo,
I've used NVIZ in the past and not had this problem but after rebuilding
Grass/Nviz for a new system (Slackware 13 64bit)  I now find when I try to
"fly" to move the landscape it keeps resetting back to its originall
position after a few frames.ie: it will start to move in the direction
of my mouse motion but then keeps jumping back so that I am unable to zoom
in or position the view where I want.

Has anybody seen this problem before or know what I should do to fix it?
Appreciate any assistance.
Thanks,
Ken
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/NVIZ-help-fly-keeps-resetting-jumping-back-to-center-tp5178852p5178852.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


  
  
  



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: Compiling winGRASS with OSGEO4w- #2

[Luisa Peña]

Hi,
Back again with this issue. Thanks Helmut and Antonio for your help but so
far I haven't manage to compile GRASS using OSGEO4W. (and it seems that
neither Antonio)
Since Glynn told me that I might have some issues with newer versions I
decided to use older versions of prebuilt and MinGW packages.

1- From oSGEO4W I installed the packages listed in step5 and 6
2- Runned msys and created osgeo4W folder and the fstab
3- Edited fstab
4- DOwnloaded the following packages (Since Antonio tried with newer and it
didn't work I decided to get the ones that are linked with Wiki):
- *msysCORE-1.0.11-bin* ==>
http://downloads.sourceforge.net/mingw/msysCORE-1.0.11-bin.tar.gz
- *bin-utils ==> *
http://downloads.sourceforge.net/mingw/binutils-2.19.1-mingw32-bin.tar.gz
- *gcc-core* ==>
http://downloads.sourceforge.net/mingw/gcc-core-3.4.5-20060117-3.tar.gz
- *gcc-g++* ==>
http://downloads.sourceforge.net/mingw/gcc-g%2B%2B-3.4.5-20060117-3.tar.gz
- *mingw32-make* ==>
http://downloads.sourceforge.net/mingw/mingw32-make-3.81-20080326-3.tar.gz
-  *mingwRuntime*==>
http://downloads.sourceforge.net/mingw/mingwrt-3.15.2-mingw32-dev.tar.gz
- *mingwutils*==>
http://downloads.sourceforge.net/mingw/mingw-utils-0.3.tar.gz
- *w32api ==> *
http://downloads.sourceforge.net/mingw/w32api-3.13-mingw32-dev.tar.gz

5- Then I unpacked them to c:\osgeo4w

6- Downloaed Make from
http://downloads.sourceforge.net/mingw/make-3.81-MSYS-1.0.11-2.tar.bz2

7- Unpacked it to c:\osgeo4w\apps\msys

8- Downloaded the following pre-built binaries:
-* Bison* ==> http://downloads.sourceforge.net/gnuwin32/bison-2.1-bin.zip
- *Bison-deps* ==>
http://downloads.sourceforge.net/gnuwin32/bison-2.1-dep.zip
- *Flex ==> http://downloads.sourceforge.net/gnuwin32/flex-2.5.4a-1-bin.zip*
- *gettext-bin ==>
http://downloads.sourceforge.net/gnuwin32/gettext-0.14.4-bin.zip*
- *gettext-lib ==>
http://downloads.sourceforge.net/gnuwin32/gettext-0.14.4-lib.zip*
*- libiconv ==>
http://downloads.sourceforge.net/gnuwin32/libiconv-1.9.2-1-lib.zip*
- *libintl-bin ==>
http://downloads.sourceforge.net/gnuwin32/libintl-0.14.4-bin.zip*
- *llibintl-lib ==>
http://downloads.sourceforge.net/gnuwin32/libintl-0.14.4-lib.zip*
- *regex == > http://downloads.sourceforge.net/gnuwin32/regex-2.7-bin.zip*
- *bc ==>
http://sourceforge.net/projects/gnuwin32/files/bc/1.06-2/bc-1.06-2-bin.zip/download
 *
- *readline ==>
http://sourceforge.net/projects/gnuwin32/files/readline/5.0-1/readline-5.0-1-bin.zip/download
*
*
*
9- Unpack it yo c:\osgeo4 I overwritted all files even if some file was
newer... Is this ok? (iconv.h and m4.exe)

10- Reboot the PC

11- Extracted latest GRASS snapshot into C:\osgeo4w\usr\src

12- Using Msys I entered in GRASS source

13- run ./mswindows/osgeo4w/package.sh &>log.log (I suppose I don't need to
change anything right? not even in Platform.make or grass.mkae)
13.1- First attempt: It stopped at
checking for location of OpenGL includes...
checking for GL/gl.h... yes
checking for GL/glu.h... yes
checking for location of OpenGL library...
checking for OpenGL library... ./configure: line 11435:  3840 Segmentation
fault  (core dumped) ( eval $ac_link ) 2>&5
configure: error: *** Unable to locate OpenGL library.

13.2- Second attempt: Without changing anything it passed over the OpenGL
and found library... (HOW can this happen? because I didn't change
anything...)

Tue Jun 15 17:08:27 GMTDT 2010: STARTING cleanup
Tue Jun 15 17:08:45 GMTDT 2010: END

Ok I had erros in:
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/raster/r.mapcalc
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/raster/r.mfilter
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/raster/r.mfilter.fp
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/raster/r.thin

14.1- running make in r.mapcalc folder I get this error:
c:\osgeo4w\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe:
cannot find -lgrass_rowio
collect2: ld returned 1 exit status
make: ***
[/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/dist.i686-pc-mingw32/bin/r.mapcalc.exe]
Error 1

14.2- running make in r.mfilter
make: *** No rule to make target
`/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/dist.i686-pc-mingw32/lib/libgrass_rowio.dll',
needed by
`/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/dist.i686-pc-mingw32/bin/r.mfilter.exe'.
 Stop.

14.3- Running make in r.mfilter
make: *** No rule to make target
`/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/dist.i686-pc-mingw32/lib/libgrass_rowio.dll',
needed by
`/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/dist.i686-pc-mingw32/bin/r.mfilter.exe'.
 Stop.

14.4- running make in r.thin
make: *** No rule to make target
`/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/dist.i686-pc-mingw32/lib/libgrass_rowio.dll',
needed by
`/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/dist.i686-pc-mingw32/bin/r.thin.exe'.
 Stop.

Ok So the problem now is: libgrass_rowio.dll. How can I debug this dll and
How can I create it? And 

Re: [GRASS-user] Compiling GRAS on Windows- Log and error

[Glynn Clements]

Luisa Peña wrote:

> Hi Glynn. As you saw from previous messages, my problem now is with
> libgrass_display.dll.
> 
> I saw a message that you sent to ML regarding this problem. Can it be
> related with prebinaries and MinGW packages version?

Maybe. Everything stems from the linker crashing while trying to build
libgrass_psdriver. This is required by libgrass_raster, which is
required by all d.* modules (and also by libgrass_display).

The psdriver library hasn't changed much recently, so it's more likely
to be an issue with the specific version of MSys' binutils.

-- 
Glynn Clements 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.mapcalc r.mapcalculator question

[Micha Silver]

On 15/06/2010 16:45, Dr. Manfred Redslob wrote:

Am Dienstag, den 15.06.2010, 06:39 -0700 schrieb varunvarma:
   

Hi, I am a new user to GRASS and have run into a problem while processing
rasters

I have 2 raster files (TIFFs) which I have loaded with GRASS in QGIS 1.0.2
Kore. The rasters contain values of 0 and 1 and represent 2 time steps. What
I wanted to do is either a simple addition of the 2 rasters or apply an OR
operator between them. For this I used the r.mapcalc and r.mapcalculator
tool. However, the cell size of the resulting raster is increased from 250m
to 2500m which leads to loss of fine scale information.

Does anyone know why this is happening and what I could do to maintain the
fine scale information?

Thank you
 

Hi however,

please check the actual resolution with g.region -p. Is the result
res=2500? If so, set region with g.region -ap res=250 or with g.region
rast=inputrasterfile. You can controll it again with  g.region -p. After
this settings run r.mapcalc again.

Regards,

Manfred

   
In addition, to do the same thing within QGIS, you can use the "Edit 
current region" button on the GRASS toolbar. Just enter the value you 
need in the N-S resolution and E-W text boxes.


Another note: I might suggest you upgrade to a newer version of QGIS.  
Version 1.4 (and soon to be released 1.5) have many improvements and bug 
fixes.

Regards


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

This mail was received via Mail-SeCure System.


   



--
Micha Silver
http://www.surfaces.co.il/
Arava Development Co.  +972-52-3665918

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.mapcalc r.mapcalculator question

[Dr. Manfred Redslob]

Am Dienstag, den 15.06.2010, 06:39 -0700 schrieb varunvarma:
> Hi, I am a new user to GRASS and have run into a problem while processing
> rasters
> 
> I have 2 raster files (TIFFs) which I have loaded with GRASS in QGIS 1.0.2
> Kore. The rasters contain values of 0 and 1 and represent 2 time steps. What
> I wanted to do is either a simple addition of the 2 rasters or apply an OR
> operator between them. For this I used the r.mapcalc and r.mapcalculator
> tool. However, the cell size of the resulting raster is increased from 250m
> to 2500m which leads to loss of fine scale information.
> 
> Does anyone know why this is happening and what I could do to maintain the
> fine scale information?
> 
> Thank you

Hi however,

please check the actual resolution with g.region -p. Is the result
res=2500? If so, set region with g.region -ap res=250 or with g.region
rast=inputrasterfile. You can controll it again with  g.region -p. After
this settings run r.mapcalc again.

Regards,

Manfred


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: Compiling winGRASS with OSGEO4w- #2

[Helmut Kudrnovsky]

Hi,

> In my previous email I used GRASS6.4.0RC6 to compile with OSGEO4w now, 
following Luisa email, I tried with latest snapshot and I got errors in 
the following modules:
[...]

I've built the WinGrass64RC6-Installer, downloadable under 

http://grass.osgeo.org/grass64/binary/mswindows/native/WinGRASS-6.4.0RC6-1-Setup.exe,

in my osgeo4w-tree (following the wiki: 
http://trac.osgeo.org/grass/wiki/CompileOnWindows wiki).

at this time there was no error.

I can try a fresh svn-checkout of Grass64 later on.

Helmut
___
GRATIS für alle WEB.DE Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de


smime.p7s
Description: S/MIME Cryptographic Signature
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.mapcalc r.mapcalculator question

[varunvarma]

Hi, I am a new user to GRASS and have run into a problem while processing
rasters

I have 2 raster files (TIFFs) which I have loaded with GRASS in QGIS 1.0.2
Kore. The rasters contain values of 0 and 1 and represent 2 time steps. What
I wanted to do is either a simple addition of the 2 rasters or apply an OR
operator between them. For this I used the r.mapcalc and r.mapcalculator
tool. However, the cell size of the resulting raster is increased from 250m
to 2500m which leads to loss of fine scale information.

Does anyone know why this is happening and what I could do to maintain the
fine scale information?

Thank you
-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/r-mapcalc-r-mapcalculator-question-tp5181949p5181949.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: Compiling winGRASS with OSGEO4w- #2

[António Rocha]

Greetings

In my previous email I used GRASS6.4.0RC6 to compile with OSGEO4w now, 
following Luisa email, I tried with latest snapshot and I got errors in 
the following modules:

Errors in:
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/lib/db/sqlp
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/db/drivers/dbf
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/db/drivers/postgres
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/db/drivers/ogr
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.barscale
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.colorlist
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.colors
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.colortable
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.erase
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.extend
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.extract
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.font
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.frame
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.geodesic
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.graph
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.grid
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.his
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.histogram
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.info
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.legend
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.linegraph
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.mapgraph
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.measure
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.menu
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.mon/cmd
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.mon/pgms
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.nviz
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.paint.labels
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.path
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.profile
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.rast
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.rast.arrow
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.rast.num
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.rgb
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.rhumbline
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.save
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.text.new
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.thematic.area
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.title
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.vect
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.vect.chart
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.what.rast
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.what.vect
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.where
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/display/d.zoom
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/general/g.mapset
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/imagery/i.ask
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/raster/r.le/r.le.setup
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/raster/r.le/r.le.trace
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/raster/r.mapcalc
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/raster/r.profile
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/raster/wildfire/r.spread
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/vector/v.label
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/vector/v.digit
/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/vector/v.label.sa

It seems that I'm missing the following DLL:
- libgrass_display.dll

Just like you Luisa. Anyone has an idea of what might be happening here?

Thank you
Antonio


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 5197 (20100615) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Re: v.rast.stats

[Micha Silver]

On 15/06/2010 14:35, Sandile Gumede wrote:
Hi
If I run g.region rast=rainfall -p, I get:

OK, what you've done here is change the current region to match the
raster "rainfall".
Can you now try: 
v.rast.stats -c vect=catchments rast=rainfall pref=precip

 

projection: 3 (Latitude-Longitude)
zone:   0
datum:  wgs84
ellipsoid:  wgs84
north:  33:40:46.49916S
south:  34:20:55.49928S
west:   18:17:55.50036E
east:   19:10:16.50036E
nsres:  0:00:05.01875
ewres:  0:00:02.18125
rows:   480
cols:   1440
cells:  691200
  
and If I run r.univar rainfall, I get the following output:
  
 100%
total null and non-null cells: 691200
total null cells: 0
  
Of the non-null cells:
--
n: 691200
minimum: 0
maximum: 3094
range: 3094
mean: 22.0228
mean of absolute values: 22.0228
standard deviation: 76.1639
variance: 5800.94
variation coefficient: 345.841 %
sum: 15222164
  
  
  
  On Tue, Jun 15, 2010 at 12:22 PM, Hamish 
wrote:
  
Micha wrote:
> The only unusual thing I notice above is that the resolution
settings
> for the raster are different N-S and E-W. This came from the
original
> tiff (see below) which also has rectangular pixels,


that is perfectly normal for a lat/lon map away from the equator.
longitude scales a cos(lat).


> (the v.rast.stats module creates a temp raster at the *current
region's
> resolution* settings, which might be different from this rainfall
> raster's rectangular resolution...)


the results of:

g.region -p rast=mapname
r.univar mapname


could help.


Hamish




  
  
  
  
-- 
Kind Regards
TS Gumede
CSIR, Meraka Institute
072 258 1650
  
  
This mail was received via Mail-SeCure System.



-- 
Micha Silver
http://www.surfaces.co.il/
Arava Development Co.  +972-52-3665918



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Re: v.rast.stats

[Sandile Gumede]

Hi
If I run g.region rast=rainfall -p, I get:

projection: 3 (Latitude-Longitude)
zone:   0
datum:  wgs84
ellipsoid:  wgs84
north:  33:40:46.49916S
south:  34:20:55.49928S
west:   18:17:55.50036E
east:   19:10:16.50036E
nsres:  0:00:05.01875
ewres:  0:00:02.18125
rows:   480
cols:   1440
cells:  691200

and If I run r.univar rainfall, I get the following output:

 100%
total null and non-null cells: 691200
total null cells: 0

Of the non-null cells:
--
n: 691200
minimum: 0
maximum: 3094
range: 3094
mean: 22.0228
mean of absolute values: 22.0228
standard deviation: 76.1639
variance: 5800.94
variation coefficient: 345.841 %
sum: 15222164



On Tue, Jun 15, 2010 at 12:22 PM, Hamish  wrote:

> Micha wrote:
> > The only unusual thing I notice above is that the resolution settings
> > for the raster are different N-S and E-W. This came from the original
> > tiff (see below) which also has rectangular pixels,
>
> that is perfectly normal for a lat/lon map away from the equator.
> longitude scales a cos(lat).
>
>
> > (the v.rast.stats module creates a temp raster at the *current region's
> > resolution* settings, which might be different from this rainfall
> > raster's rectangular resolution...)
>
> the results of:
>
> g.region -p rast=mapname
> r.univar mapname
>
>
> could help.
>
>
> Hamish
>
>
>
>


-- 
Kind Regards
TS Gumede
CSIR, Meraka Institute
072 258 1650
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Compiling winGRASS with OSGEO4w- #3

[António Rocha]

ot:
make: *** No rule to make target 
`/osgeo4w/usr/src/grass-6.4.0RC6/dist.i686-pc-mingw32/lib/libgrass_gproj.dll', 
needed by 
`/osgeo4w/usr/src/grass-6.4.0RC6/dist.i686-pc-mingw32/bin/r.in.gdal.exe'.  
Stop.


and if I do at r.mapcalc I get:
bison -y -b y -d mapcalc.y
c:\osgeo4w/share/bison/yacc.c:158: m4: Warning: Excess arguments to 
built-in `_m4_popdef' ignored
c:\osgeo4w/share/bison/yacc.c:1071: m4: Warning: Excess arguments to 
built-in `_m4_popdef' ignored

NONE:0: m4: ERROR: EOF in string
make OBJ.i686-pc-mingw32
make[1]: Entering directory 
`/osgeo4w/usr/src/grass-6.4.0RC6/raster/r.mapcalc'

make[1]: `OBJ.i686-pc-mingw32' is up to date.
make[1]: Leaving directory 
`/osgeo4w/usr/src/grass-6.4.0RC6/raster/r.mapcalc'
gcc -I/osgeo4w/usr/src/grass-6.4.0RC6/dist.i686-pc-mingw32/include 
-I/c/OSGeo4W/apps/gdal-16/include -I/c/OSGeo4W/include -g -O2  
-I/c/OSGeo4W/apps/gdal-16/include -I/c/OSGeo4W/include 
-DPACKAGE=\""grassmods"\"  
-I/osgeo4w/usr/src/grass-6.4.0RC6/dist.i686-pc-mingw32/include -o 
OBJ.i686-pc-mingw32/y.tab.o -c y.tab.c

flex -t mapcalc.l > lex.yy.c
make OBJ.i686-pc-mingw32
make[1]: Entering directory 
`/osgeo4w/usr/src/grass-6.4.0RC6/raster/r.mapcalc'

make[1]: `OBJ.i686-pc-mingw32' is up to date.
make[1]: Leaving directory 
`/osgeo4w/usr/src/grass-6.4.0RC6/raster/r.mapcalc'
gcc -I/osgeo4w/usr/src/grass-6.4.0RC6/dist.i686-pc-mingw32/include 
-I/c/OSGeo4W/apps/gdal-16/include -I/c/OSGeo4W/include -g -O2  
-I/c/OSGeo4W/apps/gdal-16/include -I/c/OSGeo4W/include 
-DPACKAGE=\""grassmods"\"  
-I/osgeo4w/usr/src/grass-6.4.0RC6/dist.i686-pc-mingw32/include -o 
OBJ.i686-pc-mingw32/lex.yy.o -c lex.yy.c

mapcalc.l:18:19: y.tab.h: No such file or directory
mapcalc.l: In function `yylex':
mapcalc.l:111: error: `yylval' undeclared (first use in this function)
mapcalc.l:111: error: (Each undeclared identifier is reported only once
mapcalc.l:111: error: for each function it appears in.)
mapcalc.l:112: error: `FLOAT' undeclared (first use in this function)
mapcalc.l:118: error: `DOUBLE' undeclared (first use in this function)
mapcalc.l:131: error: `INTEGER' undeclared (first use in this function)
mapcalc.l:141: error: `VARNAME' undeclared (first use in this function)
mapcalc.l:141: error: `NAME' undeclared (first use in this function)
mapcalc.l:148: error: `VARSTRING' undeclared (first use in this function)
mapcalc.l:148: error: `STRING' undeclared (first use in this function)
mapcalc.l:167: error: `LOGAND2' undeclared (first use in this function)
mapcalc.l:168: error: `LOGAND' undeclared (first use in this function)
mapcalc.l:169: error: `BITAND' undeclared (first use in this function)
mapcalc.l:171: error: `LOGOR2' undeclared (first use in this function)
mapcalc.l:172: error: `LOGOR' undeclared (first use in this function)
mapcalc.l:173: error: `BITOR' undeclared (first use in this function)
mapcalc.l:175: error: `LSH' undeclared (first use in this function)
mapcalc.l:176: error: `RSHU' undeclared (first use in this function)
mapcalc.l:177: error: `RSH' undeclared (first use in this function)
mapcalc.l:179: error: `GT' undeclared (first use in this function)
mapcalc.l:180: error: `GE' undeclared (first use in this function)
mapcalc.l:181: error: `LT' undeclared (first use in this function)
mapcalc.l:182: error: `LE' undeclared (first use in this function)
mapcalc.l:184: error: `EQ' undeclared (first use in this function)
mapcalc.l:185: error: `NE' undeclared (first use in this function)
make: *** [OBJ.i686-pc-mingw32/lex.yy.o] Error 1

- What can I do to fix this errors?

- Please, if someone has OSGEO4W installation, can someone provide me 
the versions of pre-built binaties and minGWpackages because I can't 
compile in MS-Windows and I really need it



Thanks
Antonio



__ Information from ESET NOD32 Antivirus, version of virus signature 
database 5197 (20100615) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Connecting vector points with the same category number

[Hamish]

Aldo wrote:
> having a vector point map with many different category values, is
> there a way to construct a vector map with lines connecting
> the points with the same category number ? 

at least part of this can be solved by v.distance output=:
   output   Name for output vector map containing lines connecting nearest 
elements



Hamish


  
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Connecting vector points with the same category number

[Aldo Clerici]

Dear GRASSusers,

having a vector point map with many different category values, is there a
way to construct a vector map with lines connecting  the points with the
same category number ?

 

Many thanks in advance.

A. Clerici 

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Re: v.rast.stats

[Hamish]

Micha wrote:
> The only unusual thing I notice above is that the resolution settings
> for the raster are different N-S and E-W. This came from the original
> tiff (see below) which also has rectangular pixels,

that is perfectly normal for a lat/lon map away from the equator.
longitude scales a cos(lat).


> (the v.rast.stats module creates a temp raster at the *current region's
> resolution* settings, which might be different from this rainfall
> raster's rectangular resolution...)

the results of:

g.region -p rast=mapname
r.univar mapname


could help.


Hamish


  
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: v.rast.stats

[Micha Silver]

Hello Sandile
(Please keep messages on the list- maybe others can help...)


On 15/06/2010 10:52, Sandile Gumede wrote:
Hi
  
Below is the output of r.info
rainfall
  
Type of Map:  raster   Number of Categories:
1020    
    Data Type:   
CELL   
    Rows:
480    
    Columns: 
1440   
    Total Cells: 
691200 
 Projection:
Latitude-Longitude  
 N: 33:40:46.49916S    S: 34:20:55.49928S   Res:
0:00:05.01875   
 E: 19:10:16.50036E    W: 18:17:55.50036E   Res:
0:00:02.18125   
    Range of data:    min = 0  max =
1020    
  

The only unusual thing I notice above is that the resolution settings
for the raster are different N-S and E-W. This came from the original
tiff (see below) which also has rectangular pixels, and your use of the
"-o" option when importing. 
I wonder if that's what is causing your problems with v.rast.stats??
(the v.rast.stats module creates a temp raster at the *current region's
resolution* settings, which might be different from this rainfall
raster's rectangular resolution...)

Please give us the output of g.region -p. 

Perhaps someone with more experience can answer: If v.rast.stats runs
using a raster with resolution different from the current region
settings what will happen?

Regards,
Micha

  
  
    Data
Description:    
 generated by
r.in.gdal  

  
   
Comments:   
  
 r.in.gdal -o -e input="/home/tgumede1/grassdata/TRMMLast03HRS.tif"
output="rainfall" target="SRTMDEM"
  
  
  
And also the output of gdalinfo for the rainfall data:
  
Driver: GTiff/GeoTIFF
Files: TRMMLast03HRS.tif
Size is 1440, 480
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
    SPHEROID["WGS 84",6378137,298.2572235630016,
    AUTHORITY["EPSG","7030"]],
    AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (18.2987500,-33.67958310002)
Pixel Size = (0.00060590278,-0.001394097291667)
Metadata:
  AREA_OR_POINT=Area
 
TIFFTAG_DOCUMENTNAME=/TRMMRT/Pool/merged/gis/image/3B42RT.2010032900.03hr.tif
  TIFFTAG_IMAGEDESCRIPTION=IDL TIFF file
  TIFFTAG_SOFTWARE=IDL 6.1, Research Systems, Inc.
  TIFFTAG_DATETIME=2010:03:29 04:53:11
  TIFFTAG_XRESOLUTION=100
  TIFFTAG_YRESOLUTION=100
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  18.2987501, -33.6795831) 
Lower Left  (  18.2987501, -34.3487498) 
Upper Right (  19.1712501, -33.6795831) 
Lower Right (  19.1712501, -34.3487498) 
Center  (  18.7350001, -34.0141665) 
Band 1 Block=256x256 Type=UInt16, ColorInterp=Gray
  
  
  
  2010/6/15 Micha Silver 
  

On 15/06/2010 09:51, Sandile Gumede wrote:
if I run r.info
-g rainfall, I get:
  
north=-33.679583
south=-34.34875
east=19.17125
west=18.29875
  
and if I run v.info
-g catchments, I get:
  
north=-33.6795831
south=-34.3487498
east=19.1712501
west=18.2987501
top=0.00
bottom=0.00
  


OK, now we see that the regions are identical.
I'd like to see also the full output of 
r.info
rainfall
(it will give the max-min values of the raster) and also the output of 
gdalinfo rainfall.tif (the original tiff file)
Perhaps then we can understand where the -NULL values are from?


 

  
  2010/6/13 Micha Silver 
  
(back on the ML)

Hi Sandile:
The error is popping up, apparently, because of the strange "-NULL"
value. What is -NULL??
Can you display the rainfall raster? Does it look OK (some value
everywhere?)

Perhaps run a check on the original rainfall.tif with gdalinfo to see
what range of values it is showing? Then do r.info rainfall to show
what range the GRASS raster has.

-- 
Micha



On 13/06/2010 12:13, Sandile Gumede wrote: 


  
  Hi, 
  
Whats wrong with the rainfall data (rainfall.tif) if you get a DBMI-DBF
driver error when running v.rast.stats
vector=catchments
raster=rainfall
colprefix=precip?
  
SQL parser error: syntax error, unexpected NULL_VALUE processing 'NULL'
in statement:
UPDATE catchments SET precip_cf_=-NULL WHERE cat=2
Error in db_execute_immediate()
  
ERROR: Error while executing: 'UPDATE catchments SET precip_cf_=-

Re: [GRASS-user] Compiling GRAS on Windows- Log and error

[Luisa Peña]

Hi Glynn. As you saw from previous messages, my problem now is with
libgrass_display.dll.

I saw a message that you sent to ML regarding this problem. Can it be
related with prebinaries and MinGW packages version?
Here goes my versions of pre-built binaries:
BC- 1.06.2-bin
Bison- 2.1-bin
Bison-2.1-dep-bin
flex- 2.5.4a-1-bin
gettext-0.14.4-bin
gettext-0.14.4-bin
libiconv-1.9.2-1-bin
libintl-0.14.4-bin
libintl-0.14.4-lib
readline-5.0-1-bin
regex2.7-bin

Make Update version: make-3.81-MSYS-1.0.11-2

MinGW packages:
- temp bugfix - DIDN'T USED
- msysCORE-1.0.11-bin
- binutils-2.19.1-mingw32-bin
- gcc-core-3.4.5-20060117-3
- gcc-g++-3.4.5-20060117-3
- mingw32-make-3.81-20080326-3
- mingwrt-3.15.2-mingw32-dev
- mingw-utils-0.3

Anything that might be causing this problem? Or shoudl I use a older
snapshot of GRASS?

- w32api-3.13-mingw32-dev
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: Compiling winGRASS with OSGEO4w- #2

[António Rocha]

Hi Luisa and Hamish and the rest

While I was reading your log file I realized two things:
1- You only have a problem with libgrass_display.dll
2- GRASS cannot find -lgrass_raster

This is the "creation of libgrass_display.dll:
gcc -shared -o 
/c/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/dist.i686-pc-mingw32/lib/libgrass_display.6.4.0svn.dll 
-L/c/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/dist.i686-pc-mingw32/lib 
-Wl,--export-dynamic,--enable-runtime-pseudo-reloc  
-L/c/OSGeo4W/apps/gdal-16/lib -L/c/OSGeo4W/lib 
OBJ.i686-pc-mingw32/cnversions.o OBJ.i686-pc-mingw32/color_list.o 
OBJ.i686-pc-mingw32/draw.o OBJ.i686-pc-mingw32/draw2.o 
OBJ.i686-pc-mingw32/get_win.o OBJ.i686-pc-mingw32/ident_win.o 
OBJ.i686-pc-mingw32/list.o OBJ.i686-pc-mingw32/popup.o 
OBJ.i686-pc-mingw32/raster.o OBJ.i686-pc-mingw32/raster2.o 
OBJ.i686-pc-mingw32/setup.o OBJ.i686-pc-mingw32/symbol.o 
OBJ.i686-pc-mingw32/tran_colr.o OBJ.i686-pc-mingw32/window.o -lgrass_gis 
-lgrass_datetime -lxdr -liberty -lws2_32-lz   -lintl  -lgrass_raster 
-lgrass_pngdriver -lgrass_driver -lgrass_gis -lgrass_datetime -lxdr 
-liberty -lws2_32-lz   -lintl  -lfreetype  -liconv  -lgrass_gis 
-lgrass_datetime -lxdr -liberty -lws2_32-lz   -lintl  -lpng  -lz
-lgrass_psdriver -lgrass_driver -lgrass_gis -lgrass_datetime -lxdr 
-liberty -lws2_32-lz   -lintl  -lfreetype  -liconv  -lgrass_gis 
-lgrass_datetime -lxdr -liberty -lws2_32-lz   -lintl   
-lgrass_driver -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32
-lz   -lintl  -lfreetype  -liconv  -lgrass_gis -lgrass_datetime -lxdr 
-liberty -lws2_32-lz   -lintl   
../../lib/gis/OBJ.i686-pc-mingw32/dllmain.o && \
   (cd 
/c/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/dist.i686-pc-mingw32/lib; 
ln -f -s libgrass_display.6.4.0svn.dll 
/c/osgeo4w/usr/src/grass-6.4.svn_src_snapshot_2010_06_12/dist.i686-pc-mingw32/lib/libgrass_display.dll)
c:\OSGeo4W\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: 
cannot find -lgrass_raster

collect2: ld returned 1 exit status
make[3]: ***

can it be some old library or package that was installed?


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 5196 (20100614) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: v.rast.stats

[Micha Silver]

On 15/06/2010 09:51, Sandile Gumede wrote:
if I run r.info
-g rainfall, I get:
  
north=-33.679583
south=-34.34875
east=19.17125
west=18.29875
  
and if I run v.info
-g catchments, I get:
  
north=-33.6795831
south=-34.3487498
east=19.1712501
west=18.2987501
top=0.00
bottom=0.00
  

OK, now we see that the regions are identical.
I'd like to see also the full output of 
r.info rainfall
(it will give the max-min values of the raster) and also the output of 
gdalinfo rainfall.tif (the original tiff file)
Perhaps then we can understand where the -NULL values are from?
 

  
  2010/6/13 Micha Silver 
  

(back on the ML)

Hi Sandile:
The error is popping up, apparently, because of the strange "-NULL"
value. What is -NULL??
Can you display the rainfall raster? Does it look OK (some value
everywhere?)

Perhaps run a check on the original rainfall.tif with gdalinfo to see
what range of values it is showing? Then do r.info rainfall to show
what range the GRASS raster has.

-- 
Micha



On 13/06/2010 12:13, Sandile Gumede wrote:



  
  Hi, 
  
Whats wrong with the rainfall data (rainfall.tif) if you get a DBMI-DBF
driver error when running v.rast.stats
vector=catchments
raster=rainfall colprefix=precip?
  
SQL parser error: syntax error, unexpected NULL_VALUE processing 'NULL'
in statement:
UPDATE catchments SET precip_cf_=-NULL WHERE cat=2
Error in db_execute_immediate()
  
ERROR: Error while executing: 'UPDATE catchments SET precip_cf_=-NULL
WHERE
cat=2'
  
  
  
  This mail was received via Mail-SeCure System.
  



-- 
Micha Silver
http://www.surfaces.co.il/
Arava Development Co.  +972-52-3665918



  
  
  
  
  
-- 
Kind Regards
TS Gumede
CSIR, Meraka Institute
072 258 1650
  
  
This mail was received via Mail-SeCure System.



-- 
Micha Silver
http://www.surfaces.co.il/
Arava Development Co.  +972-52-3665918



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] NVIZ help: fly keeps resetting/jumping back to center.

[Maris Nartiss]

Known issue, currently no fix.

http://trac.osgeo.org/grass/ticket/46

Maris.


2010/6/14, Kwas :
>
> Helo,
> I've used NVIZ in the past and not had this problem but after rebuilding
> Grass/Nviz for a new system (Slackware 13 64bit)  I now find when I try to
> "fly" to move the landscape it keeps resetting back to its originall
> position after a few frames.ie: it will start to move in the direction
> of my mouse motion but then keeps jumping back so that I am unable to zoom
> in or position the view where I want.
>
> Has anybody seen this problem before or know what I should do to fix it?
> Appreciate any assistance.
> Thanks,
> Ken
> --
> View this message in context:
> http://osgeo-org.1803224.n2.nabble.com/NVIZ-help-fly-keeps-resetting-jumping-back-to-center-tp5178852p5178852.html
> Sent from the Grass - Users mailing list archive at Nabble.com.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user