[GRASS-user] Mosaic Images
Greetings! 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? Thanks and regards, Chethan S. http://osgeo-org.1803224.n2.nabble.com/file/n6108043/mosaic.png -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Mosaic-Images-tp6108043p6108043.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] problem with g.extension
On Wed, Jan 12, 2011 at 6:23 PM, Eduardo Klein wrote: > Thanks, you're right. But still, after installing the missing package and > fixing some permissions problems, I'm getting some errors. The first of > them: > > make[82]: Entering directory > `/home/eklein/grassdata/usb/PERMANENT/.tmp/diodon/7414.0/v.mkhexgrid' > if [ "/build/buildd/grass-6.4.0/dist.i486-pc-linux-gnu/scripts/v.mkhexgrid" > != "" ] ; then > GISRC=/build/buildd/grass-6.4.0/dist.i486-pc-linux-gnu/demolocation/.grassrc64 ... This is a packaging error as well as bug http://trac.osgeo.org/grass/ticket/620 and perhaps also http://trac.osgeo.org/grass/ticket/1180 A pity that it is still open after so much time. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: db.execute where condition
Hello Rich, I got the syntax wrong, had been looking at it too long to see the problem! Thank you for pointing it out! Frans-Joost -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/db-execute-where-condition-tp6094088p6098727.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] db.execute where condition
On Mon, 7 Mar 2011, Frans-Joost Boogert wrote: I removed the 'within' quotes and the command line now looks like this: echo 'UPDATE landuse_table SET FEATURE_ID=1 WHERE FEATURE=Grazing_land'|db.execute driver=dbf database=$database Frans-Joost, You still don't have the correct syntax. Look at the examples on the db.execute page: Update attribute entries to new value based on SQL rule: echo "UPDATE roads SET travelcost=5 WHERE cat=1" | db.execute Notice that the entire expression to be echoed is in double quotes. Other examples on that page show the column values are in single quotes. Try: echo "UPDATE landuse_table SET FEATURE_ID=1 WHERE FEATURE='Grazing_land'" | db.execute after setting the driver and database name separately. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] db.execute where condition
Hello Markus The database is not linked to a vector map so I used db.describe -c landuse_table ncols: 6 nrows: 5 Column 1: OBJECTID:INTEGER:11 Column 2: FEATURE:CHARACTER:16 Column 3: A:DOUBLE PRECISION:20 Column 4: CC:DOUBLE PRECISION:20 Column 5: PH:DOUBLE PRECISION:20 Column 6: FEATURE_ID:INTEGER:11 I removed the 'within' quotes and the command line now looks like this: echo 'UPDATE landuse_table SET FEATURE_ID=1 WHERE FEATURE=Grazing_land'|db.execute driver=dbf database=$database Unfortunately this doesn't change the output. The error still refers to the value Grazing_land not found as a column: DBMI-DBF driver error: Column 'Grazing_land' not found Incompatible types in WHERE condition. Error in selecting rows Error in db_execute_immediate() Thanks in advance, Frans-Joost ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Some thoughts on wxGUI (GRASS Community Sprint)
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 Carlos -- 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
Re: [GRASS-user] db.execute where condition
On Sun, Mar 6, 2011 at 1:10 PM, frans-joost wrote: > Dear GRASS users, > > I have imported a table titled landuse_tabe with the db.in.ogr command. > I want to do the following with the table: > Add a column named FEATURE_ID > and add values to the column. > To add the values to the column I use: > > echo 'UPDATE landuse_table SET FEATURE_ID='1' WHERE I suspect that '1' makes GRASS-DB interpret this values as a string. What does v.info -c landuse_table say? If that is a numeric column, you need to specify 1 as number. > FEATURE='Grazing_land'|db.execute driver=dbf database=$database Additionally, you cannot have ' within ' quotes. Either you need to escape them or use ". Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] really good
amazing news i bought some laptops from this site now i had receive it , i like it very much they also have thousands of new original products on their site hope you like it too : enjoy yourself . will save more than 30% !! ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] DRASTIC for GRASS - Groundwater Vulnerability Modeling
thank you Giovanni for the response. Have you done such excercise in the recent past? or do you have any tuto or exhaustive list of GRASS tools that might help in this. With kind regards, --N 2011/3/7 Giovanni Manghi : > Hi, > >> I am currently doing some support for a geosciense student working on >> groundwater vulnerabilty. Is there any DRASTIC module implemented in >> GRASS that could help calculate the Di index for a specific area? > > not that I know, but it is not difficult to implement the drastic model > using other standard GRASS tools (reclassification, mapcalculator, etc.) > > > cheers > > > -- Giovanni --- > > -- Nahmsath P. YABOURI ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] DRASTIC for GRASS - Groundwater Vulnerability Modeling
Hi, > I am currently doing some support for a geosciense student working on > groundwater vulnerabilty. Is there any DRASTIC module implemented in > GRASS that could help calculate the Di index for a specific area? not that I know, but it is not difficult to implement the drastic model using other standard GRASS tools (reclassification, mapcalculator, etc.) cheers -- Giovanni --- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] DRASTIC for GRASS - Groundwater Vulnerability Modeling
Hi everybody, I am currently doing some support for a geosciense student working on groundwater vulnerabilty. Is there any DRASTIC module implemented in GRASS that could help calculate the Di index for a specific area? Awaiting for your support. With kind regards, -- Nahmsath P. YABOURI ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: problem with g.extension
Hi just stumbled upon your question while trying to find a way to install it on 10.04 as well. Jumped through all the hoops to get onto this mailing list to let you know what worked for me... 1. Download mkhexgrid-0.1.1-1.i386.rpm 2. $ sudo alien mkhexgrid-0.1.1-1.i386.rpm 3. Double click the generated .deb Simple as that as long as you don't have 64bit of course, then you probably still have to compile. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/problem-with-g-extension-tp5915051p6097132.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] Importing landsat data with GUI - bug again
Hi, 2011/3/7 Chethan S : > Few months back I had reported problems in GUI based bulk import of landsat > data in GRASS 6.4.1svn - > http://osgeo-org.1803224.n2.nabble.com/Importing-of-raster-data-doesn-t-seem-to-work-through-GUI-td5805160.html. > It was recognized that grass could recognize *.tif files and not *.TIF files > and was fixed in the next update. But now again the same issue has cropped > up. I run the latest updated version of grass6.4.1svn. Can the developers > fix it again? well, it was not really fixed, this fix introduced a new bug. With r45593 (relbr64) it's better I hope. 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] Importing landsat data with GUI - bug again
Greetings! Few months back I had reported problems in GUI based bulk import of landsat data in GRASS 6.4.1svn - http://osgeo-org.1803224.n2.nabble.com/Importing-of-raster-data-doesn-t-seem-to-work-through-GUI-td5805160.html. It was recognized that grass could recognize *.tif files and not *.TIF files and was fixed in the next update. But now again the same issue has cropped up. I run the latest updated version of grass6.4.1svn. Can the developers fix it again? Regards, Chethan S. -- Chethan S. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
