Re: [GRASS-user] Re: GRASS script to export raster
Kim wrote: > I want to build a GRASS Python script to export raster data but instead > of XYZ (from top-left corner to lower-right corner) I want the opposite. > Is there a way to do this as a python scriipt? or I can only do this as > C-module? ... > Uhm I guess I wasn't clear :) I want to write a XYZ starting from low left > corner goes to the end of row then goes to above row and so on...I mean to > go from low row to top row.Thanks so just flipping all the rows in the file you can get now? don't know how to do that in python, but if unix shell powertools are available: r.out.ascii | tac ? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] wxgui fails in latest svn
Hi, 2011/3/8 Carlos Grohmann : > FYI, I just updated grass70 svn, and wxgui is broken: which wxPython version are you running? 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
[GRASS-user] Re: GRASS script to export raster
Uhm I guess I wasn't clear :) I want to write a XYZ starting from low left corner goes to the end of row then goes to above row and so on...I mean to go from low row to top row. Thanks 2011/3/8 Kim Besson > Greetings > > I want to build a GRASS Python script to export raster data but instead of > XYZ (from top-left corner to lower-right corner) I want the opposite. Is > there a way to do this as a python scriipt? or I can only do this as > C-module? > > Thanks > Kim > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRASS script to export raster
Greetings I want to build a GRASS Python script to export raster data but instead of XYZ (from top-left corner to lower-right corner) I want the opposite. Is there a way to do this as a python scriipt? or I can only do this as C-module? Thanks Kim ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Some thoughts on wxGUI (GRASS Community Sprint)
Carlos wrote: > v.plane - I think the azimuth option here should be > compass-oriented For decades GRASS has used cartesian theta (CCW from positve x-axis) as the azimuth origin, not CW from north as used in compass orientation. there is no right or wrong answer here, so historical choices win. the mathematicians got to it first that's all. n.b. in the new v.in.geodesic module*, CW from North is used for az, as it is in r.transect. simply because that's what `geod` wants and I didn't spend the effort to invert it. (* along with v.mkgrid, I wonder how to better name these in gr7) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Subset several bands of data at one go
> But with this I can subset one band data at a time. Is it somehow possible >to use i.group and region definition to obtain subsets of all bands? >Scripting might be an answer but I have no much idea about it. what about working with different computational regions? http://grass.osgeo.org/grass64/manuals/html64_user/rasterintro.html : "[...] As a general rule in GRASS: * Raster output maps have their bounds and resolution equal to those of the current computational region. * Raster input maps are automatically cropped/padded and rescaled (using nearest-neighbour resampling) to match the current region. * Raster input maps are automatically masked if a raster map named MASK exists. The MASK is only applied when reading maps from the disk. [...]" so you can do calculations/run modules in different computational region without extracting of many subsets of your data before. best regards Helmut ___ WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt mit gratis Handy-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2 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] wxgui fails in latest svn
FYI, I just updated grass70 svn, and wxgui is broken: GRASS 7.0.svn (falklands):~ > Traceback (most recent call last): File "/usr/local/grass-7.0.svn/etc/gui/wxpython/wxgui.py", line 1578, in sys.exit(main()) File "/usr/local/grass-7.0.svn/etc/gui/wxpython/wxgui.py", line 1571, in main app = GMApp(workspaceFile) File "/usr/local/grass-7.0.svn/etc/gui/wxpython/wxgui.py", line 1470, in __init__ wx.App.__init__(self, False) File "/usr/lib64/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7978, in __init__ self._BootstrapApp() File "/usr/lib64/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7552, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File "/usr/local/grass-7.0.svn/etc/gui/wxpython/wxgui.py", line 1488, in OnInit timeout = 2000, parent = None, id = wx.ID_ANY) TypeError: __init__() got an unexpected keyword argument 'extrastyle' cheers -- Prof. Carlos Henrique Grohmann - Geologist D.Sc. Institute of Geosciences - Univ. of São Paulo, Brazil http://www.igc.usp.br/pessoais/guano http://lattes.cnpq.br/5846052449613692 Linux User #89721 Can’t stop the signal. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Subset several bands of data at one go
Ciao Chetan. I do not know if I understand your problem. I advise you to create a mask (which defines the area in respect of which "cut" the raster) and call the raster with similar names (eg landsat_1, landsat_2,). At this point you should do something like this: for i in ` g.mlist type=rast pattern=land* ` do r.mapcalc $i = "( $i )" Ciao Gabriele -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Subset-several-bands-of-data-at-one-go-tp6118506p6134798.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] Some thoughts on wxGUI (GRASS Community Sprint)
On Mar 8, 2011, at 8:46 AM, Martin Landa wrote: Hi, 2011/3/7 Carlos Grohmann : Also, when it comes to output of modules, we should have only one way of doing it. Now some modules provide output in the gis manager window (using on of the botom tabs), while others give output in the dialog window. I think there should be only one kind of output.In my view, a separated output window (like the tk gism) where _all_ output messages would go, and one should be able to close without loosing info (keeping a 'memory' of the session) or leave it open. I found myself frequently trying to close the gism after inspecting some output info, just to be reminded of what I was about to do when asked if I want to save a workspace file. commands launched from Layer Manager command line prints their output to the 'command output' tab. Separately launched modules print their output to 'command output' tab in the module's GUI dialog. Redirecting this messages to 'command output' tab in Layer Manager would avoid running more commands at the same time. One solution would be to add for every launched command separate tab in Layer Manager's 'command output' . I am not sure what is better. Anyway creating separate window is not good solution, the more windows the worse for the user. Less Windows. I suggest at most three and preferably two- The layer manager, Map Window, and "if you have to" a command window. I normally have a text editor to script in open at the same time, and even with a second monitor this arrangment gets cluttered. One of the things that annoy me is the 'close dialog on finish' option. I guess this was introduced to make GRASS look more like other GIS packages, but honestly, it sucks. At leas for me, it is very common to repeat the command with different settings, and I usually forget to unset that option, being used to old-style GRASS GUI, so I kind hate it. We could have a global preferences setting where we could choose to 'close dialogs on finish' as default action or not. But this would have to work for _all_ modules. You can imagine how disappointing it is to run r.stats just to see the dialog closing after calculations... in r45601 I changed default settings to 'unchecked'. Anyway you are always free to change this settings in Preferences dialog (command tab). 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 My two pennies Stephen ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Some thoughts on wxGUI (GRASS Community Sprint)
Hi, 2011/3/7 Carlos Grohmann : > Also, when it comes to output of modules, we should have only one way > of doing it. Now some modules provide output in the gis manager window > (using on of the botom tabs), while others give output in the dialog > window. I think there should be only one kind of output.In my view, a > separated output window (like the tk gism) where _all_ output messages > would go, and one should be able to close without loosing info > (keeping a 'memory' of the session) or leave it open. I found myself > frequently trying to close the gism after inspecting some output info, > just to be reminded of what I was about to do when asked if I want to > save a workspace file. commands launched from Layer Manager command line prints their output to the 'command output' tab. Separately launched modules print their output to 'command output' tab in the module's GUI dialog. Redirecting this messages to 'command output' tab in Layer Manager would avoid running more commands at the same time. One solution would be to add for every launched command separate tab in Layer Manager's 'command output' . I am not sure what is better. Anyway creating separate window is not good solution, the more windows the worse for the user. > One of the things that annoy me is the 'close dialog on finish' > option. I guess this was introduced to make GRASS look more like other > GIS packages, but honestly, it sucks. At leas for me, it is very > common to repeat the command with different settings, and I usually > forget to unset that option, being used to old-style GRASS GUI, so I > kind hate it. We could have a global preferences setting where we > could choose to 'close dialogs on finish' as default action or not. > But this would have to work for _all_ modules. > You can imagine how disappointing it is to run r.stats just to see the > dialog closing after calculations... in r45601 I changed default settings to 'unchecked'. Anyway you are always free to change this settings in Preferences dialog (command tab). 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] Some thoughts on wxGUI (GRASS Community Sprint)
Thanks for the input Carlos. Can you please post these as individual items in the bug tracker (after checking to make sure that they are not already posted, of course)? By putting them in the tracker, they can be identified and prioritized to be fixed. Michael On Mar 8, 2011, at 3:01 AM, wrote: > Message: 2 > Date: Mon, 7 Mar 2011 15:23:27 -0300 > From: Carlos Grohmann > Subject: [GRASS-user] Some thoughts on wxGUI (GRASS Community Sprint) > To: GRASS user list > Message-ID: > > Content-Type: text/plain; charset=windows-1252 > > Dears, with the GRASS Community Sprint just around the corner, I want > to share some impressions and bug reports about the wxGUI. > > Some are general, some are specific. All bugs/issues were found using > the latest svn. > > > GENERAL: > > I said this before, the tabs in the wx gis manager should look like > real tabs. Currently, the bottom tabs (blue) don't look like 'normal' > tabs, so this can be potentially confusing for new users. Give them > the appearance of the upper tabs. > > Improving drag-and-drop would be really helpful. > > Also, when it comes to output of modules, we should have only one way > of doing it. Now some modules provide output in the gis manager window > (using on of the botom tabs), while others give output in the dialog > window. I think there should be only one kind of output.In my view, a > separated output window (like the tk gism) where _all_ output messages > would go, and one should be able to close without loosing info > (keeping a 'memory' of the session) or leave it open. I found myself > frequently trying to close the gism after inspecting some output info, > just to be reminded of what I was about to do when asked if I want to > save a workspace file. > > > One of the things that annoy me is the 'close dialog on finish' > option. I guess this was introduced to make GRASS look more like other > GIS packages, but honestly, it sucks. At leas for me, it is very > common to repeat the command with different settings, and I usually > forget to unset that option, being used to old-style GRASS GUI, so I > kind hate it. We could have a global preferences setting where we > could choose to 'close dialogs on finish' as default action or not. > But this would have to work for _all_ modules. > You can imagine how disappointing it is to run r.stats just to see the > dialog closing after calculations... > > I also noticed that several modules fail to include the resulting map > in the tree > > > SPECIFIC > v.plane - I think the azimuth option here should be compass-oriented > > r.to.rast3 - the 3D map is added to the tree, but when you call it > properties, it opens d.vect > > r.slope.aspect - does not work with '@mapset' after the map name > > r.in.gdal - the default dialog (import raster) locks access to gism. I > think it shouldn't, like the regular module dialogs > > v.in.ogr - the default dialog (import vector) also locks access to > gism. Besides, in my machine, when I try to browse for files, it shows > nothing, even in a directory full of shapefiles (or any other format) > > r.in.gdal - when I import a tiff, it creates map.red, map.blue, > map.green, but it adds 'map' to the tree, instead of an RGB composite. > Since 'map' doesn't exists, error messages galore. > > > > Well, these are just personal ideas, but I hope they could be of use. > > cheers ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Mosaic Images
On Tue, Mar 8, 2011 at 10:45 AM, Hamish wrote: > Chethan wrote: >> When I try to mosaic landsat images(just one band) which >> belong to adjacent >> path-rows they do not mosaic properly. It appears as in the >> attached >> screenshot. I have tried changing the order of images but >> just the >> overlapping image changed. I have tried r.patch as well as >> i.image.mosaic >> with region encompassing both the scenes. However if I >> mosaic the same >> images in ERDAS Imagine there are no issues. Mosaiced >> image will be simply >> perfect except for brightness differences. ERDAS also >> provides options like >> histogram matching to sort out such issues. So what is the >> way to mosaic >> images in GRASS? Also is there any way to use specify >> options like >> resampling, histogram matching in the process? > ... >> http://osgeo-org.1803224.n2.nabble.com/file/n6108043/mosaic.png > > [sorry about yahoo's linewrap] > > > the d.what.rast or the query tool to check to see if the black image > boundaries are in fact NULL, or if they are 0. If they are 0 use the > r.null module to set them to NULL, then try again. As an alternative, you can use r.clump2 from GRASS-Addons and flood-fill areas (here, the "black" boundary" using the coordinate parameter. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Subset several bands of data at one go
Hi all! As you know landsat data has separate files for different bands. Creating a subset is a wise option to work on region of our interest. Therefore, I used this method to subset my image - d.zoom || g.region g.region -p r.mapcalc *subset*=original as suggested in http://osgeo-org.1803224.n2.nabble.com/Raster-Map-subset-td4523291.html#a4526819 . But with this I can subset one band data at a time. Is it somehow possible to use i.group and region definition to obtain subsets of all bands? Scripting might be an answer but I have no much idea about it. Thanks and regards, Chethan S. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] problem with g.extension
Markus wrote: > and perhaps also > http://trac.osgeo.org/grass/ticket/1180 that one has a test-fix in 6.5svn, does it work if you try that version? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Mosaic Images
Chethan wrote: > When I try to mosaic landsat images(just one band) which > belong to adjacent > path-rows they do not mosaic properly. It appears as in the > attached > screenshot. I have tried changing the order of images but > just the > overlapping image changed. I have tried r.patch as well as > i.image.mosaic > with region encompassing both the scenes. However if I > mosaic the same > images in ERDAS Imagine there are no issues. Mosaiced > image will be simply > perfect except for brightness differences. ERDAS also > provides options like > histogram matching to sort out such issues. So what is the > way to mosaic > images in GRASS? Also is there any way to use specify > options like > resampling, histogram matching in the process? ... > http://osgeo-org.1803224.n2.nabble.com/file/n6108043/mosaic.png [sorry about yahoo's linewrap] the d.what.rast or the query tool to check to see if the black image boundaries are in fact NULL, or if they are 0. If they are 0 use the r.null module to set them to NULL, then try again. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
