Re: [GRASS-user] Possible bug in r.sum and in r.stats?
Rainer M Krug wrote: > As some commands do use the region and mask, while others don't, it might be > a good idea to make > this clear in the manual - I know, it is stated if they do, but not if they > don't. I would expect it to be the other way around. Most raster modules respect the current region and mask, because it happens automatically. Modules which don't want to use the current region have to explicitly set the working region (typically based upon an input map); modules which don't want inputs to be masked have to explicitly disable masking. As a general guideline, you should expect any module which actually processes raster data to honour the current region and mask (r.info isn't such a module; it just display's the map's metadata). -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] -- add-on module to compute Linear Directional Mean
Dear GRASS'ers! I wrote the shell-script that computes "Linear Directional Mean" of the vector map (as explaned there http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/How_Linear_Directional_Mean_works/005p001r00/) and displays LDM graphics on the X-monitor, optionally save it to vector line and update attribute table with LDM parameters. Links: https://raw.github.com/amuriy/GRASS-scripts/master/v.ldm http://grass.osgeo.org/wiki/GRASS_AddOns#v.ldm I hope it would be useful for somebody :) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Registering Maps From Different Sources
All project data are from different sources, and normally I have no difficulties importing them to GRASS, then reprojecting various maps to the desired project location. This project is being obdurate and I'm out of ideas on how to resolve the issue. Now I am working with three map themes: Public Land Survey System (PLSS; the Townships/Ranges/Sections at scale of 1:24K); Hydrography (HUC at 12-digit, subwatershed, level at scale of 1:24K from the National Hydrographic Database); and DEM (3m at scale of 1:24K from the National Elevation Dataset). Following is the projection information from the source files: PLSS (.e00): ProjectionLAMBERT Datum NAD83 ZunitsNO Units 3.280840 Spheroid GRS1980 Xshift0.00 Yshift0.00 Parameters 43 0 0.000 /* 1st standard parallel 45 30 0.000 /* 2nd standard parallel -120 30 0.000 /* central meridian 41 45 0.000 /* latitude of projection's origin 40.0 /* false easting (meters) 0.0 /* false northing (meters) HUC12 (.prj): StatePlane_Washington_North FIPS 4601 NAD83 GRS80 PROJECTION Lambert_Conformal_Conic False_Easting 50.0 False_Northing 0.0 Central_Meridian -120.8 Standard_Parallel_1 47.5 Standard_Parallel_2 48.73 Latitude_Of_Origin 47.0 UNIT Meter, 1.0 DEM (.tif): UTM Zone 11 NAD83 GRS80 Bounds West -118.86004 East -118.10445 North 49.00047 South 47.83036 UNITS Either Degrees or Meters I created a separate location for each and imported the data (multiple DEM and hydrography files). The project location is in State Plane Coordinate System, Washington North, NAD83, with units of US feet and created using .shp files of a project theme provided by my client: name: Lambert Conformal Conic proj: lcc datum: nad83 ellps: grs80 lat_1: 47.5 lat_2: 48.73 lat_0: 47 lon_0: -120.8 x_0: 50.01 y_0: 0 no_defs: defined unit: Foot_US units: Foot_US meters: 0.3048006096012192 Using v.proj, I re-projected the PLSS and HUC12 coverages, but the two are separated by a rather large gap on the map display with the former to the left. When I try to apply r.proj to bring in the DEM I'm told the region is outside that of the current location. I don't see what I've done differently than I have with other projects where I did not have these issues. What process should I apply to re-import these source maps so they all overlap in the same coordinate system and units? TIA, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] WxGUI Vector Digitizer crashes
Hi, 2012/3/8 Vincent Bain : > working with grass 6.4 release branch (r51019) on a debian linux system, > vector digitizer sometimes crashes after a long time of use, running out > of memory : 100% of 6GB RAM is progressively used, never decreases while > GUI is not restarted. It occurs especially when a raster background has > to be displayed. No idea what to do to help diagnose the problem (?), > looks like there is something wrong with memory deallocation. > Is it worth opening a ticket for it or can the problem be due to my > system ? working with larger vector maps? Probably DEBUG and WX_DEBUG messages could help (last few lines before crash). g.gisenv set=DEBUG=5 g.gisenv set=WX_DEBUG=5 Needs some more investigation, ... Martin -- Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Possible Bug: -6.5svn Build #51017 [FIXED?]
On Thu, 8 Mar 2012, Rich Shepard wrote: I just tried v.proj using the wxgui, but was unsuccessful. Working from the command line I believe I found the error, and it's not a v.proj bug. I used the GUI to create a new location specifying a shapefile .prj for the projection information. For some reason, that did not create the PROJ_INFO and PROJ_UNITS files in the PERMANENT mapset. So, I start over from the command line and that should fix the problem. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Possible Bug: -6.5svn Build #51017
I just tried v.proj using the wxgui, but was unsuccessful. The source is in a location named Washington-SPCS-meters and the destination location is Washington-SPCS. After filling in all requisite data entry widgets and pressing the 'Run' button I see an error message that the source location needs to be specified. This message box appears over the dialog box showing the source location in the text entry widget. So, the source location is specified (correctly) but the reprojection won't run. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.what.rast.buffer crash
Hi there! I just started using GRASS GUI a few days ago so please bear with me if this is a newbie question (tried searching on forums etc. but could not find a solution). I want to use r.what.rast.buffer to calculate the average of a raster within a buffer from points. When I run the addon it produces the following output: v.what.rast.buffer.bat --verbose input=epoint@climate raster=wetavr_raster@climate buffer=100 output=C:\Users\okonk\test2 [wetavr_raster@climate] v.what.rast.buffer -- epoint@climate -> wetavr_raster@climate @ 100 m Using resolution from: wetavr_raster@climate Extracting [wetavr_raster@climate] at [epoint@climate] At this point the computer hangs and Windows gives me a "v.out.ascii.exe has stopped working - a problem caused the program to stop working correctly" message. When I click "close program" the command output says "done!" but the output ascii file is empty. Thanks in advance! Nicolai -- View this message in context: http://osgeo-org.1560.n6.nabble.com/r-what-rast-buffer-crash-tp4558773p4558773.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] WxGUI Vector Digitizer crashes
Hi, working with grass 6.4 release branch (r51019) on a debian linux system, vector digitizer sometimes crashes after a long time of use, running out of memory : 100% of 6GB RAM is progressively used, never decreases while GUI is not restarted. It occurs especially when a raster background has to be displayed. No idea what to do to help diagnose the problem (?), looks like there is something wrong with memory deallocation. Is it worth opening a ticket for it or can the problem be due to my system ? Thanks, Vincent. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] ODBC driver in GRASS
Have posted a few weeks ago on a problem with the ODBC driver. Got some answers and thanks a lot to all those who took their time to do so. Tried it recently with a QGIS/GRASS installation via OSGeo4W with some hope, the driver problem could be solved this way. But it wasn't. If I try to conclude the answers and my experiences, the ODBC driver is not working as it should: (http://osgeo-org.1560.n6.nabble.com/ODBC-in-GRASS-td4377627.html#a4378582) "... The ODBC driver was written on Linux, based on http://www.unixodbc.org/. It was written before GRASS was ported to Windows. The API is standard so that it should work on Windows, maybe some minor modifications are necessary. Most probably some debugging and bugfixing has to be done on Windows. " Please correct me, if I should be wrong. The question is, who could modificate the driver so it works also on Windows ? Have I to ask the in developers list ? Another answer hinted on a missing compilation of the ODBC driver in WinGRASS. (http://osgeo-org.1560.n6.nabble.com/Re-winGrass-ODBC-and-MS-Access-database-td4356636.html#a4358688). Also in an earlier thread of Sharon in 4/2011 there were given some hints on ask on the OSGeo4W list (http://osgeo-org.1560.n6.nabble.com/winGrass-ODBC-and-Oracle-td3887239.html#a3887242). So how to proceed ? GRASS appears to be able to process ODBC sources, but obviously there are actually some restrictions ... Thanks again for comments, regards, Christine -- View this message in context: http://osgeo-org.1560.n6.nabble.com/ODBC-driver-in-GRASS-tp4558182p4558182.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: Possible bug in r.sum and in r.stats?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/12 12:20, Markus Neteler wrote: > On Thu, Mar 8, 2012 at 11:34 AM, Hermann Peifer wrote: >> On 08/03/2012 10:43, Rainer M Krug wrote: >>> >>> >>> As some commands do use the region and mask, while others don't, it might >>> be a good idea to >>> make this clear in the manual - I know, it is stated if they do, but not if >>> they don't. >>> >>> An sub-section under the Description might be an option? > > I am always ready to improve the documentation but in this file should > additions go? I looked at it again - there are effectively two solutions I could think of: 1) on raster.html, the list of raster commands could be split into two lists, one "respecting region and MASK", one "not respecting region and MASK" (or similar). 2) on the respective site of the module (e.g. r.mapcalc.html), under DESCRIPTION, add a standard sentence as a last paragraph : "This module *respects* the region settings and the MASK" or "This module *does not respect* the region settings and the MASK" In addition, it should actually also be added to the output of the --help of the modules... > >> This question does indeed come up occasionally. You could perhaps have a >> look at [1], then go >> to Next message > Next message > ... >> >> Hermann >> >> [1] http://lists.osgeo.org/pipermail/grass-user/2010-September/057988.html Interesting read - clarified a few things for me. Cheers, Rainer > > Fine - just let me know where to add stuff. > > thanks Markus ___ grass-user > mailing list > grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9Ym8oACgkQoYgNqgF2egonpgCfXkAVzKP078owa1X0lhFTfb9B o6kAn30mo/Nlp6Loimqr6Ti4rRJ5RNXp =TLRH -END PGP SIGNATURE- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Possible bug in r.sum and in r.stats?
On Thu, Mar 8, 2012 at 11:34 AM, Hermann Peifer wrote: > On 08/03/2012 10:43, Rainer M Krug wrote: >> >> >> As some commands do use the region and mask, while others don't, it might >> be a good idea to make >> this clear in the manual - I know, it is stated if they do, but not if >> they don't. >> >> An sub-section under the Description might be an option? I am always ready to improve the documentation but in this file should additions go? > This question does indeed come up occasionally. You could perhaps have a > look at [1], then go to Next message > Next message > ... > > Hermann > > [1] http://lists.osgeo.org/pipermail/grass-user/2010-September/057988.html Fine - just let me know where to add stuff. thanks Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Possible bug in r.sum and in r.stats?
On 08/03/2012 10:43, Rainer M Krug wrote: As some commands do use the region and mask, while others don't, it might be a good idea to make this clear in the manual - I know, it is stated if they do, but not if they don't. An sub-section under the Description might be an option? This question does indeed come up occasionally. You could perhaps have a look at [1], then go to Next message > Next message > ... Hermann [1] http://lists.osgeo.org/pipermail/grass-user/2010-September/057988.html ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Possible bug in r.sum and in r.stats?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/03/12 21:20, Glynn Clements wrote: > > Rainer M Krug wrote: > >> I get the following output as seen on the screenshot. > > In future, please copy/paste the text rather than using a screenshot. I wanted to, but it was completely garbled due to line breaks: I now changed the wraplength setting (thunderbird - http://forums.mozillazine.org/viewtopic.php?f=29&t=1598995), and it would have looked fine. > >> Look at the number of cells in r.stats, compared to total cells as given by >> r.info (which is >> correct). >> >> Any ideas what is happening? > > Does the current region match the raster? r.info displays statistics for the > underlying raster; > the data which r.stats uses is resampled and cropped/padded according to the > current region. Thanks a lot - that is the problem - the wind file was different. Fixed it and it is working now. As some commands do use the region and mask, while others don't, it might be a good idea to make this clear in the manual - I know, it is stated if they do, but not if they don't. An sub-section under the Description might be an option? Cheers, Rainer > - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9Yf0wACgkQoYgNqgF2egq6mgCfb6AzJXqW9nSVnDOc9JdH31dR D+gAn37fhHZp/Jkfn/TJEZvy0CqTKmoI =dbyd -END PGP SIGNATURE- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
