Re: [GRASS-user] r.to.vect Produces Too Many Areas
On 02/22/2010 10:12 PM, Rich Shepard wrote: I've done something incorrectly but cannot find what that is. Ran r.water.outlet and produced the output basin map. Then I applied r.null to that map setting nulls to zeros. Next I applied r.to.vect to that map (with the '-s' option) setting feature to area. When I look at the aspect map overlaid by the sub-basin map I see the 5 extraneous cells that should not be there. You can see them on the attached screen shot. What I do in these cases is run v.clean with the rmarea option. I choose a threshold about 5X the cell resolution to get rid of any small areas like these. I think it comes from the way r.to.vect works (others with more knowledge might correct me). Any cell which touchs the contiguous area only at one corner is considered a separate polygon, so you end up with some square vector areas of size nsresXewres. This did not happen the last time I used r.water.outlet, and the drainage map does not suggest to me why these 5 cells are included. Help would be appreciated in learning what happened and how to get this tail off the map. Thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- 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
Fwd: [GRASS-user] HDF-5 parse
Hey Not necessarily. It is also possible that GCPs are stored and gdalwarp needs to be used first to obtain a really geocoded file. Say, use gdalwarp to preprocess the data. Please try with one channel and post what gdalinfo reports on the resulting file. Since GRASS documentation extensively preprocess to GEOTIFF, I will try that. Is it the best thing to do? ok here it goes By using gdalinfo HDF5:/mnt/GIS/DATA/HDF5_DATA_MSG_FAPAR_Euro_20070222://FAPAR I get: Driver: HDF5Image/HDF5 Dataset Files: none associated Size is 1701, 651 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9108]], AXIS[Lat,NORTH], AXIS[Long,EAST], AUTHORITY[EPSG,4326]] Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 651.0) Upper Right ( 1701.0,0.0) Lower Right ( 1701.0, 651.0) Center ( 850.5, 325.5) Band 1 Block=1701x1 Type=Int16, ColorInterp=Undefined Metadata: FAPAR:CLASS=Data FAPAR:PRODUCT=product FAPAR:PRODUCT_ID=0 FAPAR:N_COLS=1701 FAPAR:N_LINES=651 FAPAR:NB_BYTES=2 FAPAR:SCALING_FACTOR=1 FAPAR:OFFSET=0 FAPAR:MISSING_VALUE=-10 FAPAR:UNITS=N/A FAPAR:CAL_SLOPE=1 FAPAR:CAL_OFFSET=0 If I do : gdalwarp HDF5:/mnt/GIS/LSASAF/HDF5_LSASAF_MSG_FAPAR_Euro_20070222://FAPAR /mnt/GIS/testing.tif I get: ERROR 1: Unable to compute a transformation between pixel/line and georeferenced coordinates for HDF5:/mnt/GIS/LSASAF/HDF5_LSASAF_MSG_FAPAR_Euro_20070222://FAPAR. There is no affine transformation and no GCPs. Is this helpful to solve this question? At MODIS Wiki (http://grass.osgeo.org/wiki/MODIS) Gdal Warp is not used. Instead, it's create a intermediate file (TIF) using gdal_translate and only then is r.in.gdal is used. Thank you Markus and Antonio and Hamish for your help Markus Because there is not much inofmration regarding how to do this. I mean, it seems that if I do r.in.gdal I loose all GCP and coordinates system information... Sorry for these lammer questions but I think I'm lost Thanks Pedro 2010/2/17 Pedro Roma pedroroma1...@gmail.com Thank you all. Regarding Antonio's suggestion I will see if I can do that. It seems a good Idea. Is it possible to have a button to browse files? Thanks Best regards Pedro 2010/2/17 António Rocha antonio.ro...@deimos.com.pt Hello Pedro My suggestion, in case you have a consistent dataset, would be to create your own script to read import HDF5 files. My question regarding this is it possible to have a Browse files button in a GRASS scripts? Antonio __ Information from ESET NOD32 Antivirus, version of virus signature database 4872 (20100216) __ 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 mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] HDF-5 parse
On Tue, Feb 23, 2010 at 10:16 AM, Pedro Roma pedroroma1...@gmail.com wrote: By using gdalinfo HDF5:/mnt/GIS/DATA/HDF5_DATA_MSG_FAPAR_Euro_20070222://FAPAR I get: Driver: HDF5Image/HDF5 Dataset Files: none associated Size is 1701, 651 Coordinate System is: GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0, AUTHORITY[EPSG,8901]], UNIT[degree,0.0174532925199433, AUTHORITY[EPSG,9108]], AXIS[Lat,NORTH], AXIS[Long,EAST], AUTHORITY[EPSG,4326]] Corner Coordinates: Upper Left ( 0.0, 0.0) Lower Left ( 0.0, 651.0) Upper Right ( 1701.0, 0.0) Lower Right ( 1701.0, 651.0) Center ( 850.5, 325.5) Band 1 Block=1701x1 Type=Int16, ColorInterp=Undefined Metadata: FAPAR:CLASS=Data FAPAR:PRODUCT=product FAPAR:PRODUCT_ID=0 FAPAR:N_COLS=1701 FAPAR:N_LINES=651 FAPAR:NB_BYTES=2 FAPAR:SCALING_FACTOR=1 FAPAR:OFFSET=0 FAPAR:MISSING_VALUE=-10 FAPAR:UNITS=N/A FAPAR:CAL_SLOPE=1 FAPAR:CAL_OFFSET=0 If I do : gdalwarp HDF5:/mnt/GIS/LSASAF/HDF5_LSASAF_MSG_FAPAR_Euro_20070222://FAPAR /mnt/GIS/testing.tif I get: ERROR 1: Unable to compute a transformation between pixel/line and georeferenced coordinates for HDF5:/mnt/GIS/LSASAF/HDF5_LSASAF_MSG_FAPAR_Euro_20070222://FAPAR. There is no affine transformation and no GCPs. Since this is a GDAL problem, please ask on the GDAL list. Did you try the MODIS Reprojection Tool? Does that fail as well? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Help with webmaps
On Mon, Feb 22, 2010 at 9:13 PM, Pablo Carreira pablotcarre...@hotmail.com wrote: Hi, I want to display some of my Grass vectors over the internet with GeoServer. Do I have to export the vector to shp or postgis everytime I make an update, so I can open them with Geoserver? If Geoserver uses GDAL/OGR, you could try to use the GRASS-GDAL-OGR plugin and read the data directly from the GRASS database. Or expose the GRASS database via GRASS-GDAL-OGR plugin as WMS/WFS? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] Help with webmaps
Hi, I want to display some of my Grass vectors over the internet with GeoServer. Do I have to export the vector to shp or postgis everytime I make an update, so I can open them with Geoserver? If Geoserver uses GDAL/OGR, you could try to use the GRASS-GDAL-OGR plugin and read the data directly from the GRASS database. Or expose the GRASS database via GRASS-GDAL-OGR plugin as WMS/WFS? Markus Thank you for the help, now I am going to study these possibilities. _ Quer deixar seus vídeos mais divertidos? Com o Movie Maker isso fica fácil. http://www.windowslive.com.br/public/tip.aspx/view/87?product=4ocid=Windows Live:Dicas - Movie Maker:Hotmail:Tagline:1x1:Titulo Legendas Creditos___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.profile grass64_rc5 - grass7
John Tate wrote: I looked at v.rast.stats. Nice that it updates the table but for this purpose, it produces a lot of extra unneeded columns (shame you can't select which stats to add to the table - or perhaps you can?). I don't think you can. (beyond v.db.dropcol after) file a wish in the trac system if you like. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.to.vect Produces Too Many Areas
On Tue, 23 Feb 2010, Micha Silver wrote: What I do in these cases is run v.clean with the rmarea option. I choose a threshold about 5X the cell resolution to get rid of any small areas like these. I think it comes from the way r.to.vect works (others with more knowledge might correct me). Any cell which touchs the contiguous area only at one corner is considered a separate polygon, so you end up with some square vector areas of size nsresXewres. Micha, I'd not used v.clean before so this approach did not occur to me. Works like a charm. Now I have a new tool to apply when the situation comes up again. Toda raba, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Interactive Vector Editing
I want to remove basin boundary lines other than the that for the specific project basin. Reading the v.edit man page (and looking at the command line in the GUI) I see that this is non-interactive. What module can I use in the GUI or console monitor to click on a boundary line and delete it? Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.overlay Limited In wxPython GUI
I tried to extract the streams within a specific drainage basin using the wxPython GUI and the v.overlay function. It fails because it assumes the operation is 'or' (set UNION) and does not permit the user to select a different operator. To write only those streams within the named basin to an output file requires the set operator INTERSECT, or 'and.' I did not see anywhere on the GUI window tabs where the operator could be selected. If I missed it, please point that out to me. Else, consider adding a widget to select the operator. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GDAL version for GRASS6.4.0
Greetings I'm currently using GDAL1.5.4 and I would like to know if, I update it to 1.6 or 1.7, GRASS will have any sort of problems? Thanks Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Interactive Vector Editing
On Tue, 23 Feb 2010, Rich Shepard wrote: I want to remove basin boundary lines other than the that for the specific project basin. Reading the v.edit man page (and looking at the command line in the GUI) I see that this is non-interactive. What module can I use in the GUI or console monitor to click on a boundary line and delete it? Here's more: I tried v.edit from the command line specifying the tool as delete and the feature type as boundary. The boundary lines remain. If I specify the feature type as centroid, then those disappear. I thought that this module would remove all remaining lines from the partial basins but that's apparently not the case. The same thing happens when I use the GUI, display attributes, select all the partial drainage basins in the project area, and delete them. The centroids are removed but the boundary lines remain. What I want for this map is only the single watershed boundary. Not the partial ones that remain when I overlay the entire state basin map with the project-specific rectangle, and not that bounding rectangle, either. I cannot find a module that does this. Your advice needed, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed: Interpreting Visual Output Map
Rich Shepard wrote: When I read the man page for the visual output map of r.watershed I see that it's supposed to help me display results. I assume that it does this by coloring the accumulation of surface runoff with sub-basin sizes between 0 and the threshold value. Almost right. ...with surface flow accumulation between 0 and the threshold value. How am I to interpret this map? How does 'surface runoff accumulation with values modified for easy display' relate to minimum basin size? All flow accumulation values larger than the threshold value are set to the threshold value. What are the units of surface runoff accumulation? Number of cells draining through a given cell. Converted to squared map units by multiplying with nsres * ewres, of the flow accumulation map of course, and first setting the computational region to match the flow accumulation map with g.region -p rast=my_flow_acc. -p to check that everything is all right. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed: Interpreting Visual Output Map
On Tue, 23 Feb 2010, Markus Metz wrote: Almost right. ...with surface flow accumulation between 0 and the threshold value. Markus, Now I understand, yet still miss the difference between the accumulation map and the visual map. All flow accumulation values larger than the threshold value are set to the threshold value. Got that from the man page. Number of cells draining through a given cell. Converted to squared map units by multiplying with nsres * ewres, of the flow accumulation map of course, and first setting the computational region to match the flow accumulation map with g.region -p rast=my_flow_acc. -p to check that everything is all right. I assume that the above calculation is left for me to do; that the module does not do the math before displaying the results. Am I correct in my assumption? One last point: why no color in the legend? There is color on the visual map but not on the accompanying legend. Strange and I don't know how to fix this. Many thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] strange output from v.voronoi
Hi, This morning I noticed very odd output from v.voronoi, specifically on split between adjacent points was missing and the output messages contained the following: Number of nodes: 22 Number of primitives: 27 Number of points: 0 Number of lines: 0 Number of boundaries: 20 Number of centroids: 7 Number of areas: 6 Number of isles: 1 Number of duplicate centroids: 1 The resulting voronoi polygons are attached. Here are some details on the vector: Number of points: 127 type countminmax point127 1127 line 0 0 0 boundary 0 0 0 centroid 0 0 0 area 0 0 0 face 0 0 0 kernel 0 0 0 all 127 1127 Here is the version information: GRASS 6.5.svn (2010) ./configure --with-tcltk-includes=/usr/include/tcl8.4 --with-postgres --without-odbc --with-mysql --with-mysql-includes=/usr/include/mysql/ --with-freetype --with-freetype-includes=/usr/include/freetype2 --with-readline --with-cxx --enable-largefile --with-postgres-includes=/usr/local/pgsql/include/ --with-postgres-libs=/usr/local/pgsql/lib/ --with-sqlite --with-python --with-proj-share=/usr/local/share/proj/ --with-cairo Revision: 38990 Date: 2009-09-05 10:01:13 -0700 (Sat, 05 Sep 2009) Could it be that the bad output is caused by some fundamental problem with the input point vector? Cheers, Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 attachment: bad_thiessen.png___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed: Interpreting Visual Output Map
Rich Shepard wrote: On Tue, 23 Feb 2010, Markus Metz wrote: Almost right. ...with surface flow accumulation between 0 and the threshold value. Markus, Now I understand, yet still miss the difference between the accumulation map and the visual map. All flow accumulation values larger than the threshold value are set to the threshold value. Got that from the man page. I forgot, the difference between flow accumulation and visual output is not only that all flow accumulation values larger than the threshold value are set to the threshold value, but also that all negative values are converted to positive values. Number of cells draining through a given cell. Converted to squared map units by multiplying with nsres * ewres, of the flow accumulation map of course, and first setting the computational region to match the flow accumulation map with g.region -p rast=my_flow_acc. -p to check that everything is all right. I assume that the above calculation is left for me to do; that the module does not do the math before displaying the results. Am I correct in my assumption? Yes. One last point: why no color in the legend? There is color on the visual map but not on the accompanying legend. Strange and I don't know how to fix this. Must be a problem of d.rast.leg, no quick help from my side, sorry! Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.overlay Limited In wxPython GUI
On Feb 23, 2010, at 12:37 PM, grass-user-requ...@lists.osgeo.org wrote: Date: Tue, 23 Feb 2010 09:46:13 -0800 (PST) From: Rich Shepard rshep...@appl-ecosys.com Subject: [GRASS-user] v.overlay Limited In wxPython GUI To: grass-us...@lists.osgeo.org Message-ID: alpine.lnx.2.00.1002230942540.6...@salmo.appl-ecosys.com Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII I tried to extract the streams within a specific drainage basin using the wxPython GUI and the v.overlay function. It fails because it assumes the operation is 'or' (set UNION) and does not permit the user to select a different operator. To write only those streams within the named basin to an output file requires the set operator INTERSECT, or 'and.' I did not see anywhere on the GUI window tabs where the operator could be selected. If I missed it, please point that out to me. Else, consider adding a widget to select the operator. Rich I just looked at this in GRASS 7 and there is a pull down choice control for operator defines features written to output vector map: The pull-down lists and, or, not, and xor. Is this missing on GRASS 6.4? Michael___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] first time running
I've installed, downloaded sample data (NC and Spearfish) and am following tutorial instructions from this page: http://trac.osgeo.org/grass/wiki/HowToTestGrass6 Everything goes alright until Start GRASS then I get this error: g.proj or projection error: dyld: Library not loaded: /Library/Frameworks/PROJ.framework/Versions/4.6/PROJ Referenced from /Applications/GRASS-6.4.app/Contents/MacOS/bin/g.proj Reason: image not found and crash. Any ideas? ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.overlay Limited In wxPython GUI
2010/2/23 Michael Barton michael.bar...@asu.edu: [...] I just looked at this in GRASS 7 and there is a pull down choice control for operator defines features written to output vector map: The pull-down lists and, or, not, and xor. Is this missing on GRASS 6.4? it's not missing in G6.4. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: r.out.gdal and INTERLEAVE=PIXEL
Thanks for all your answer. This is the reply from the Gdal list: http://trac.osgeo.org/gdal/ticket/3433 My problem is how to export a raster to be used inside ArcGIS..the procedure on the wiki [1] uses INTERLEAVE=PIXEL . If I use a standard r.out.gdal syntax, the min shown is 2.22 *e^-308 and the max 1.97*e^308 Anyone has got experience on this task? Thanks Luca [1] : http://grass.osgeo.org/wiki/Tips_for_Arc_users#Raster_import.2Fexport_commands -- View this message in context: http://n2.nabble.com/r-out-gdal-and-INTERLEAVE-PIXEL-tp4611081p4621558.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
Re: [GRASS-user] Re: r.out.gdal and INTERLEAVE=PIXEL
thedok78 wrote: Thanks for all your answer. This is the reply from the Gdal list: http://trac.osgeo.org/gdal/ticket/3433 My problem is how to export a raster to be used inside ArcGIS..the procedure on the wiki [1] uses INTERLEAVE=PIXEL . ... for multi-band raster exports If I use a standard r.out.gdal syntax, the min shown is 2.22 *e^-308 and the max 1.97*e^308 ... in some ESRI product I guess. That's a bug in that ESRI product, it should use something like -DBL_MAX but uses DBL_MIN, which would be the potential data range but not the actual data range. File a bug with ESRI, wait for it to get fixed, download the fixed version. Alternatively, adjust the symbology for the raster map you want to display, if you're lucky, the ESRI product you are using offers a number of different color rules to be applied to your raster map. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.overlay Limited In wxPython GUI
On Tue, 23 Feb 2010, Martin Landa wrote: it's not missing in G6.4. Martin, Aha! I did not see the vertical scroll bar on the Optional tab. It is there near the bottom. My error. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] first time running
jon winchester wrote: I've installed, downloaded sample data (NC and Spearfish) and am following tutorial instructions from this page: http://trac.osgeo.org/grass/wiki/HowToTestGrass6 Everything goes alright until Start GRASS then I get this error: g.proj or projection error: dyld: Library not loaded: /Library/Frameworks/PROJ.framework/Versions/4.6/PROJ Referenced from /Applications/GRASS-6.4.app/Contents/MacOS/bin/g.proj Reason: image not found and crash. Any ideas? did you install all the required framework packages listed on the Mac download site? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.overlay Limited In wxPython GUI
On Tue, 23 Feb 2010, Rich Shepard wrote: pull-down lists and, or, not, and xor. Is this missing on GRASS 6.4? Turns out there's a vertical scroll bar on the Optional tab, and below what's visible at the top of the tab is that option. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.overlay Limited In wxPython GUI
Michael wrote: I just looked at this in GRASS 7 and there is a pull down choice control for operator defines features written to output vector map: The pull-down lists and, or, not, and xor. Is this missing on GRASS 6.4? that requires GRASS to be built with GEOS support, which AFAIK was added after the major feature freeze for 6.4. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed: Interpreting Visual Output Map
Rich Shepard wrote: One last point: why no color in the legend? There is color on the visual map but not on the accompanying legend. Strange and I don't know how to fix this. 64bit build with Cairo driver was fixed by Glynn a few days ago. report back if it breaks with the latest SVN. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.overlay Limited In wxPython GUI
Hi, 2010/2/23 Hamish hamis...@yahoo.com: Michael wrote: I just looked at this in GRASS 7 and there is a pull down choice control for operator defines features written to output vector map: The pull-down lists and, or, not, and xor. Is this missing on GRASS 6.4? that requires GRASS to be built with GEOS support, which AFAIK was added after the major feature freeze for 6.4. GEOS support is related to v.select not v.overlay. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed: Interpreting Visual Output Map
On Tue, 23 Feb 2010, Hamish wrote: 64bit build with Cairo driver was fixed by Glynn a few days ago. report back if it breaks with the latest SVN. Hamish, While my server/workstation has an AMD Athlon/X2 CPU I am running the 32-bit Slackware-12.2 on it. I'll grab the latest from the subversion repository and build it later this afternoon. Leaking kitchen sink drain needs to be fixed first. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: r.out.gdal and INTERLEAVE=PIXEL
thedok78 wrote: If I use a standard r.out.gdal syntax, the min shown is 2.22 *e^-308 and the max 1.97*e^308 try different values for the type= option. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Bug or my fault?
Thanks for your help Michael. Here is the status. Issued v.db.connect and all prints as expected by you and all vectors have a corresponding .dbf file. This is what I do. I have a mapset with 270 vectors. I open GRASS64 with wxpython GUI and select one vector in the middle, call it vect135. I right click to list the attributes. The system hangs with error Python.exe not responding I restart GRASS64 with TclTk GUI and load the same vector, press the attributes button and all attributes show up perfectly. I then delete the top 100 .dbf files from the dbf directory only (not from the vector directory). I restart GRASS64 with the python GUI again, load the same vector (vect135), right click and the attribute table shows up perfectly. I then restore the 100 .dbf files I had previously deleted and now delete the bottom 100. Restart GRASS64 with python GUI, load vect135, right click and the attribute table shows up perfectly. As soon as the number of dbf files increases to approx 188 (the actual number seems to depend on which vectors are involved) the system hangs when opening the attribute table, but only with the python GUI. I have now restructured my location so I have a number of mapsets and have distributed the vectors among the new mapsets, so they all have less than 100 files each, and all works perfectly. But I am really puzzled and would dearly like to know why this happens only to me! By the way, the problem occurs running GRASS with or without MSys. -- View this message in context: http://n2.nabble.com/Bug-or-my-fault-tp4609390p4623610.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
Re: [GRASS-user] GDAL version for GRASS6.4.0
Nikos wrote: I'm currently using GDAL1.5.4 and I would like to know if, I update it to 1.6 or 1.7, GRASS will have any sort of problems? no, but you'll probably have to rebuilt it. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
