Re: [GRASS-user] NVIZ help: fly keeps resetting/jumping back to center.
Known issue, currently no fix. http://trac.osgeo.org/grass/ticket/46 Maris. 2010/6/14, Kwas ken.kwasni...@gmail.com: 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: v.rast.stats
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 mi...@arava.co.il (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
[GRASS-user] Re: Compiling winGRASS with OSGEO4w- #2
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
Re: [GRASS-user] Compiling GRAS on Windows- Log and error
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: v.rast.stats
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 mi...@arava.co.il 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 mi...@arava.co.il (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
Re: [GRASS-user] Re: v.rast.stats
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] Connecting vector points with the same category number
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] Connecting vector points with the same category number
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] Compiling winGRASS with OSGEO4w- #3
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] Re: v.rast.stats
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 hamis...@yahoo.com 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
Re: [GRASS-user] Re: v.rast.stats
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 hamis...@yahoo.com 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
[GRASS-user] Re: Compiling winGRASS with OSGEO4w- #2
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
[GRASS-user] r.mapcalc r.mapcalculator question
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
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
Re: [GRASS-user] r.mapcalc r.mapcalculator question
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
Re: [GRASS-user] r.mapcalc r.mapcalculator question
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] Compiling GRAS on Windows- Log and error
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 gl...@gclements.plus.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
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 ) 25 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 what might be
Re: [GRASS-user] NVIZ help: fly keeps resetting/jumping back to center.
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 ken.kwasni...@gmail.com: 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
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('', '?xml version=1.0
encoding=utf-8?\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.
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 ken.kwasni...@gmail.com: 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 ken.kwasni...@gmail.com: 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.
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 ken.kwasni...@gmail.com: 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 ken.kwasni...@gmail.com: 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] Compiling winGRASS with OSGEO4w- #2
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
