[GRASS-user] Landsat Stack import and export
Greetings I've a Landsat image with 6 bands in Tif format. I need to import into grass, do some processing and export the same band in a Stack. The import is easy using r.in.gdal but my difficulty is to export 6 bands in one single file. Is it possible using GRASS? Thanks Best regards, Antonio __ Information from ESET NOD32 Antivirus, version of virus signature database 5093 (20100506) __ 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] raster interpolation and NULL cell filling
Hi all, there is a new module in grass7 for raster interpolation called r.resamp.bspline, based on the lidar tool methods. NULL cells are filled on the go, no need to fill them first. Alternatively, the module only interpolates NULL cells in the input raster, running quite fast in this mode. The output raster map can then be used to fill NULL cells in the input map (r.patch input=raster_with_holes,raster_with_interpolated_nulls output=gapfilled). Please test! Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Export the conversion from Vector to Raster
Greetings This is probably a very dumb thing but I'm having a few difficulties doing this. I have an SHAPEFILE with classification polygons. And I need to Convert to raster (e.g. TIF) So I thought of using GRASS (of course) 1- Define region with a Landsat image used to create those Training areas outside GRASS 2- Run v.in.gor v.in.ogr -o dsn=C:\Data\GISDataBase\training_data.shp output=train00 Over-riding projection check Layer: training_data Default driver / database set to: driver: dbf database: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ Importanto feições do mapa 448... - Building topology for vector map train00... Registering primitives... 448 primitives registered 2903 vertices registered Building areas... 448 areas built 448 isles built Attaching islands... Attaching centroids... Number of nodes: 448 Number of primitives: 448 Number of points: 0 Number of lines: 0 Number of boundaries: 448 Number of centroids: 0 Number of areas: 448 Number of isles: 448 Number of areas without centroid: 448 - Cleaning polygons, result is not guaranteed! Building topology for vector map train00... Number of nodes: 448 Number of primitives: 448 Number of points: 0 Number of lines: 0 Number of boundaries: 448 Number of centroids: 0 Number of areas: - Number of isles: - - Break polygons: - Remove duplicates: - Break boundaries: - Remove duplicates: - Clean boundaries at nodes: - Change dangles to lines: - Remove bridges: - Building topology for vector map train00... Building areas... 448 areas built 448 isles built Attaching islands... Number of nodes: 448 Number of primitives: 448 Number of points: 0 Number of lines: 0 Number of boundaries: 448 Number of centroids: 0 Number of areas: 448 Number of isles: 448 Number of areas without centroid: 448 Layer: training_data - - Building topology for vector map train00... Registering primitives... 896 primitives registered 3351 vertices registered Building areas... 448 areas built 448 isles built Attaching islands... Attaching centroids... Number of nodes: 896 Number of primitives: 896 Number of points: 0 Number of lines: 0 Number of boundaries: 448 Number of centroids: 448 Number of areas: 448 Number of isles: 448 - 448 input polygons Total area: 6.159110e+006 (448 areas) Overlapping area: 0.00e+000 (0 areas) Area without category: 0.00e+000 (0 areas) 3- It created a vectorial train00. When I open it at GRASS and overlays it with my landsat images they MATCH... 4- I want to create a RASTER exacly with the same characteristics as my landsat images but using Class Field as Raster values. I mean, the pixels inside polygons with class value 12 will have a vlue of 12. Reading GRASS book I decided to use v.to.rast v.to.rast input=trai...@permanent output=train_raster00 type=area column=Class labelcolumn=cat Loading data... Pass 1 of 2: Reading areas... Reading features... Writing raster map... Pass 2 of 2: Reading areas... Writing raster map... Converted areas: 448 of 448 Converted points/lines: 0 of 0 v.to.rast complete. 5- Open train_raster00 and it seems to be Ok when comparing with Vectorial 6- Metadata from is train_raster00 | Type of Map: raster Number of Categories: 0 | | Data Type:CELL | | Rows: 7109 | | Columns: 7662 | | Total Cells: 54469158 | |Projection: x,y | |N: 23020.21492744S: -190249.78507256 Res:30 | |E: 177696.83076767W: -52163.16923233 Res:30 | | Range of data:min = 1 max = 17 | And Metadata from Landsat is: | Type of Map: raster Number of Categories: 0 | | Data Type:CELL | | Rows: 7109 | | Columns: 7662 | | Total Cells: 54469158 | |Projection: x,y | |N: 23020.21492744S: -190249.78507256 Res:30 | |E: 177696.83076767W: -52163.16923233 Res:30 | | Range of data:min = 0 max = 255 | So it maches :) 7- Now, export this raster.Since I want a Geotiff I used: r.out.tiff input=train_raste...@permanent output=trainraster00a If I do gdalinfo to the exported file I get:river: GTiff/GeoTIFF Files: /mnt/GIS/trainraster00a.tif Size is 7662, 7109 Coordinate System is `' Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (0.0,
Re: [GRASS-user] Export the conversion from Vector to Raster
Kim Besson wrote: [snip] 7- Now, export this raster.Since I want a Geotiff I used: r.out.tiff input=train_raste...@permanent output=trainraster00a You must use r.out.gdal to get a GeoTIFF, r.out.tiff produces an ordinary tif image, not a spatial raster dataset. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: [GRASS-dev] raster interpolation and NULL cell filling
Hi, 2010/5/7 Markus Metz markus.metz.gisw...@googlemail.com: there is a new module in grass7 for raster interpolation called r.resamp.bspline, based on the lidar tool methods. NULL cells are filled on the go, no need to fill them first. Alternatively, the module only interpolates NULL cells in the input raster, running quite fast in this mode. The output raster map can then be used to fill NULL cells in the input map (r.patch input=raster_with_holes,raster_with_interpolated_nulls output=gapfilled). Please test! great, anyway compilation fails on my machine crosscorr.c: In function ‘cross_correlation’: crosscorr.c:170: error: implicit declaration of function ‘P_Read_Raster_Region_Map’ crosscorr.c:170: warning: assignment makes pointer from integer without a cast BTW, this module should probably stay in `raster/` instead of `vector\lidar`. 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] Export the conversion from Vector to Raster
Hi Markus I did this: r.out.gdal input=train_raste...@permanentoutput=c:\Data\GISDataBase\trainraster00b nodata=-1 And I got PROJ_INFO not found for DATA PROJ_UNITS not found for PT_IGP Exporting to GDAL data type: Byte Unable to set projection Input raster map contains cells with NULL-value (no-data). The value -1 was used to represent no-data values in the input map. You can specify nodata value by nodata parameter. It's strange. Then I decided to do g.region display and I realized that: projection: 0 (x,y) zone: 0 north: 23020.21492744 south: -190249.78507256 west: -52163.16923233 east: 177696.83076767 nsres: 30 ewres: 30 rows: 7109 cols: 7662 cells: 54469158 (Fri May 07 10:40:07 2010) Comando terminado (0 sec) (Fri May 07 10:40:30 2010) g.region -p projection: 0 (x,y) zone: 0 north: 23020.21492744 south: -190249.78507256 west: -52163.16923233 east: 177696.83076767 nsres: 30 ewres: 30 rows: 7109 cols: 7662 cells: 54469158 I have NO PROJECTION :( How come? I have defined my Location from a projected Landsat image the same that I have imported. Any clues of what I did wrong? 2010/5/7 Markus Metz markus.metz.gisw...@googlemail.com Kim Besson wrote: [snip] 7- Now, export this raster.Since I want a Geotiff I used: r.out.tiff input=train_raste...@permanent output=trainraster00a You must use r.out.gdal to get a GeoTIFF, r.out.tiff produces an ordinary tif image, not a spatial raster dataset. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: [GRASS-dev] raster interpolation and NULL cell filling
On Fri, May 7, 2010 at 11:38 AM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2010/5/7 Markus Metz markus.metz.gisw...@googlemail.com: there is a new module in grass7 for raster interpolation called r.resamp.bspline, based on the lidar tool methods. NULL cells are filled on the go, no need to fill them first. Alternatively, the module only interpolates NULL cells in the input raster, running quite fast in this mode. The output raster map can then be used to fill NULL cells in the input map (r.patch input=raster_with_holes,raster_with_interpolated_nulls output=gapfilled). Please test! great, anyway compilation fails on my machine crosscorr.c: In function ‘cross_correlation’: crosscorr.c:170: error: implicit declaration of function ‘P_Read_Raster_Region_Map’ Have done make distclean? The header PolimiFunct.h has changed, your installation is probably still using the old version in include, the new version is in vector/lidar/lidarlib and gets copied to include after make distclean crosscorr.c:170: warning: assignment makes pointer from integer without a cast BTW, this module should probably stay in `raster/` instead of `vector\lidar`. For compilation it is easier if it is in vector/lidar because it uses stuff in lidarlib. Otherwise it will fail because raster modules are compiled before vector modules -lidarlib not yet available. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Export the conversion from Vector to Raster
Kim Besson wrote: Hi Markus I did this: r.out.gdal input=train_raste...@permanent output=C:\Data\GISDataBase\trainraster00b nodata=-1 nodata = -1 and type = Byte is no good because the range of Byte is 0 - 255 and -1 gets converted to 255, i.e. all NULL cells will become 255 (all cells that are already 255 stay 255) but nodata is -1 so info about NULL cells gets lost. And I got PROJ_INFO not found for DATA PROJ_UNITS not found for PT_IGP check the original Landsat data with gdalinfo. They are usually in UTM. If the original data don't have projection info, the xy location is correct and you have to manually reproject to a proper location. If the original data do have projection info, something went wrong while defining the location, no idea what. Markus M Exporting to GDAL data type: Byte Unable to set projection Input raster map contains cells with NULL-value (no-data). The value -1 was used to represent no-data values in the input map. You can specify nodata value by nodata parameter. It's strange. Then I decided to do g.region display and I realized that: projection: 0 (x,y) zone: 0 north: 23020.21492744 south: -190249.78507256 west: -52163.16923233 east: 177696.83076767 nsres: 30 ewres: 30 rows: 7109 cols: 7662 cells: 54469158 (Fri May 07 10:40:07 2010) Comando terminado (0 sec) (Fri May 07 10:40:30 2010) g.region -p projection: 0 (x,y) zone: 0 north: 23020.21492744 south: -190249.78507256 west: -52163.16923233 east: 177696.83076767 nsres: 30 ewres: 30 rows: 7109 cols: 7662 cells: 54469158 I have NO PROJECTION :( How come? I have defined my Location from a projected Landsat image the same that I have imported. Any clues of what I did wrong? 2010/5/7 Markus Metz markus.metz.gisw...@googlemail.com Kim Besson wrote: [snip] 7- Now, export this raster.Since I want a Geotiff I used: r.out.tiff input=train_raste...@permanent output=trainraster00a You must use r.out.gdal to get a GeoTIFF, r.out.tiff produces an ordinary tif image, not a spatial raster dataset. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Error in Projection from Landsat images
Greetings This topic was being discussed in converting Vector to raster and them I realized that it might be better to change it to here: I did gdalinfo to my landsat data is this: Driver: GTiff/GeoTIFF Files: L.tif Size is 7662, 7109 Coordinate System is: LOCAL_CS[ Geocoding information not available Projection Name = ETRS_1989_Transverse_Mercator Units = meters Geo, UNIT[unknown,1]] Origin = (-52163.169232331842068,23020.214927441673353) Pixel Size = (30.000,-30.000) Metadata: TIFFTAG_SOFTWARE=IMAGINE TIFF Support Copyright 1991 - 1999 by ERDAS, Inc. All Rights Reserved @(#)$RCSfile: etif.c $ $Revision: 1.10.1.9.1.9.2.11 $ $Date: 2004/09/15 18:42:01EDT $ TIFFTAG_XRESOLUTION=1 TIFFTAG_YRESOLUTION=1 TIFFTAG_RESOLUTIONUNIT=1 (unitless) AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( -52163.169, 23020.215) Lower Left ( -52163.169, -190249.785) Upper Right ( 177696.831, 23020.215) Lower Right ( 177696.831, -190249.785) Center ( 62766.831, -83614.785) Band 1 Block=64x64 Type=Byte, ColorInterp=Red Band 2 Block=64x64 Type=Byte, ColorInterp=Green Band 3 Block=64x64 Type=Byte, ColorInterp=Blue Band 4 Block=64x64 Type=Byte, ColorInterp=Undefined Band 5 Block=64x64 Type=Byte, ColorInterp=Undefined Band 6 Block=64x64 Type=Byte, ColorInterp=Undefined It has geographic information right? and it's supposed to be recognized by GRASS. So I decided to create a new Location. 1- Define name of the location (landsat02) 2- Choose method for creating a new location: Read Projection and datums from a georreferenced file== I select the file I choose no in defining region 3- Enter into location 4- do g.region -p and I get: projection: 0 (x,y) zone: 0 north: 23020.21492744 south: -190249.78507256 west: -52163.16923233 east: 177696.83076767 nsres: 30 ewres: 30 rows: 7109 cols: 7662 cells: 54469158 Everything else seems ok except the Projection that is (x,y). This means that it's not recognizing the coordinate system or am I doing something wrong? Thank you Kim ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Landsat Stack import and export
2010/5/7 António Rocha antonio.ro...@deimos.com.pt: Greetings I've a Landsat image with 6 bands in Tif format. I need to import into grass, do some processing and export the same band in a Stack. The import is easy using r.in.gdal but my difficulty is to export 6 bands in one single file. Is it possible using GRASS? To my knowledge no. But you can export it separately, then merge with GDAL tools. See http://gfoss.blogspot.com/2008/06/gdal-raster-data-tips-and-tricks.html - Merge various map/bands into a RGB composite (should work for more bands than 3). Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Landsat Stack import and export
2010/5/7 Markus Neteler nete...@osgeo.org: 2010/5/7 António Rocha antonio.ro...@deimos.com.pt: Greetings I've a Landsat image with 6 bands in Tif format. I need to import into grass, do some processing and export the same band in a Stack. The import is easy using r.in.gdal but my difficulty is to export 6 bands in one single file. Is it possible using GRASS? To my knowledge no. Sure it is. Create a group in GRASS, export the group (r.out.gdal input=group_name) to a file format that supports multiple bands, e.g. GeoTIFF. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with running Python script in GRASS
Dear Glynn, I am always interested in GRASS scripting-related questions. Thanks for your support on Python/Windows issues. From: Glynn Clements gl...@gclements.plus.com Subject: Re: [GRASS-user] Problem with running Python script in GRASS To: LeeDaniel lee.daniel.1...@gmail.com Cc: grass-user@lists.osgeo.org Message-ID: 19426.59411.559013.36...@cerise.gclements.plus.com Content-Type: text/plain; charset=us-ascii LeeDaniel wrote: I've written a Python script, doing my best to use the Python I know and reverse engineer the python scripts I found in the Internet. As far as I can tell, the script should be fine, although I naturally can't execute it independently. [...] Windows, Python and 6.4 isn't the most reliable combination. At a minimum, you need a fairly recent version of 6.5 to be able to use Python scripts on Windows (the hacks required to get shell scripts to work on Windows get in the way of running other scripts). 6.4.0-RC6 won't work (g.parser was updated, but lib/python wasn't). Is this true also for the daily WinGRASS-6.4.SVN at http://josef.fsv.cvut.cz/wingrass/ and will this hold true for 6.4 in general? You also need a clean Python install with the correct registry entries, From what you say, one needs two Python installations: the one that comes with GRASS and an additional fresh one -- is it ok to install the current Python 2.6.5 version or 2.5 is better (2.6 seems to be ok from http://grass.osgeo.org/wiki/GRASS_and_Python)? From the GRASS/Python wiki one also infers that on Windows the Python binaries that come with the GRASS installation are no longer used (?). (Currently I am using WinGRASS-6.4.SVN-r42046-1 from the installer downloaded at the link above; OS is windows 7.) and you may need to hack the GRASS startup scripts (the WinGRASS installer fails quite badly with regard to Python, and the OSGeo4W installer fails even harder). But my question is actually: if a user wants to take a (Windows) Python scripting approach to GRASS, what version should she/he target? My impression is that trying to build functionality using GRASS 7 may have the best returns, although I am not sure how feasible is that right now, i.e. what GRASS 6 functionality can currently be ported to GRASS 6 (I am thinking for example to a way around the display issue that in 6.4 is solved using appropriate settings for e.g. GRASS_RENDER_IMMEDIATE). Given that WinGRASS users have the extreme luxury of 7.0.svn snapshot installers being built almost daily thanks to Martin Landa: http://josef.fsv.cvut.cz/wingrass/grass70/ it would be very interesting to know your opinion. Kind regards and thank you in advance, Luigi -- 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: Problem with running Python script in GRASS
Hi everyone, Just a quick status update: Being so new to the whole GRASS scene (and the Open Source scene in the first place) but wanting very much to work with these systems, I installed Linux and had the difficulties I described above. As an answer to the question if anything else happened when I tried to run a Python script using GRASS 6.4: I listed everything that happened, sadly there was no further information that the system gave me. I've now learned a little bit about writing shell scripts and have successfully translated the Python script into the shell format. Now it seems to be running without problems. It's quite a large computation, but right now it's going great in Linux. My other question, though, is how to get newer versions of GRASS. I also considered going over to GRASS 7, it seems to be planned to deal a lot better with Python, but wasn't able to find it on the official GRASS page. Did I just overlook it, or is it available through some other source? I found some sources in the Internet but didn't quite trust them. Best, Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Problem-with-running-Python-script-in-GRASS-tp5007296p5018865.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-windows] Re: [GRASS-user] Problem with running Python script in GRASS
Luigi Ponti wrote: Windows, Python and 6.4 isn't the most reliable combination. At a minimum, you need a fairly recent version of 6.5 to be able to use Python scripts on Windows (the hacks required to get shell scripts to work on Windows get in the way of running other scripts). 6.4.0-RC6 won't work (g.parser was updated, but lib/python wasn't). Is this true also for the daily WinGRASS-6.4.SVN at http://josef.fsv.cvut.cz/wingrass/ and will this hold true for 6.4 in general? The current 6.4 SVN head has been updated to use g.parser -s, which eliminates the main issue with Python scripts (on Windows, you can't execute a script based upon the #! line, so g.parser explicitly invoked the script via %GRASS_SH%, which didn't work for Python scripts). You also need a clean Python install with the correct registry entries, From what you say, one needs two Python installations: the one that comes with GRASS and an additional fresh one -- is it ok to install the current Python 2.6.5 version or 2.5 is better (2.6 seems to be ok from http://grass.osgeo.org/wiki/GRASS_and_Python)? From the GRASS/Python wiki one also infers that on Windows the Python binaries that come with the GRASS installation are no longer used (?). You don't need the version which comes with GRASS, and you're probably better off not using it. You need Python 2.4 or later, with wxWidgets 2.8, NumPy, and PyWin32. [The main reason for the attempt at bundling Python in the installer is to eliminate the need to install wxWidgets, NumPy and PyWin32 to match the installed version of Python.] You may need to set PYTHONPATH to %WINGISBASE%\etc\python in order for scripts to find the grass.script module. You may also need to add %WINGISBASE%\scripts to %PATH% (Init.bat doesn't do this on Windows, as shell scripts in the scripts directory are invoked via a matching batch file in the bin directory). (Currently I am using WinGRASS-6.4.SVN-r42046-1 from the installer downloaded at the link above; OS is windows 7.) and you may need to hack the GRASS startup scripts (the WinGRASS installer fails quite badly with regard to Python, and the OSGeo4W installer fails even harder). But my question is actually: if a user wants to take a (Windows) Python scripting approach to GRASS, what version should she/he target? My impression is that trying to build functionality using GRASS 7 may have the best returns, although I am not sure how feasible is that right now, i.e. what GRASS 6 functionality can currently be ported to GRASS 6 (I am thinking for example to a way around the display issue that in 6.4 is solved using appropriate settings for e.g. GRASS_RENDER_IMMEDIATE). A lot of the fundamental issues have been fixed in 7.0, although it isn't as widely deployed and hasn't been as widely tested as 6.x. The need for backwards compatibility in 6.x makes it harder to deal with some fundamental portability issues, while 7.0 doesn't have that problem (if existing mechanisms aren't portable, they get replaced with something that is, even if it breaks compatibility). -- 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] r.contour generates no lines
Hi, I tried to create contours from a DEM with the following information: | Type of Map: raster Number of Categories: 255 | Data Type:FCELL | Rows: 9856 | Columns: 4844 | Total Cells: 47742464 |Projection: Transverse Mercator |N: -3704977.57894189S: -3803537.57894189 Res:10 |E: -15589.63705055W: -64029.63705055 Res:10 | Range of data:min = -39.681747 max = 1084.584839 The command I used was: r.contour --overwrite input=ct_dem_...@permanent output=ct_contours_1...@permanent step=100 cut=2000 However, the resulting vector file contains no lines. This is the output of v.info: | Type of Map: vector (level: 2) | | Number of points: 0 Number of areas: 0 | Number of lines:0 Number of islands:0 | Number of boundaries: 0 Number of faces: 0 | Number of centroids:0 Number of kernels:0 | | Map is 3D: Yes | Number of dblinks: 1 | | Projection: Transverse Mercator | N: 0S: 0 | E: 0W: 0 | B: 0T: 0 The attribute table does contain 10 categories starting from 100m and ending at 1000m. Leaving out the cut parameter doesn't change anything. Any ideas about why the file contains no features? Thanks Hanlie ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.proj or r.resamp.rst issues
Bulent Arikan wrote:
I am running GRASS 6.5 svn (Snow Leopard). I have several ASTER GDEMs
(Latlong, 30m res.), which I reprojected into UTM using both 'nearest' and
'cubic' methods ('r.proj'). Only in some imagery that are reprojected in
cubic, I ended up having couple of cells (literally, 1-2 cells out of 8
million in average) with minus (-) values. For example, in a DEM where the
elevation values are between 800-2600 meters, I have cell values between
-150 and -85 meters. This does not seem to be an issue in reprojected
imagery with the nearest method. I am not sure how these minus values are
introduced at the first place.
Cubic interpolation can introduce overshoot, as can other forms of
spline interpolation. Linear and nearest-neighbor interpolation don't
have this issue.
With r.resamp.rst, the problem can be alleviated to a degree by using
higher values for the tension= parameter.
Also, if your data is noisy, this will tend to exaggerate the
gradients, making overshoot more likely. Filtering the data first will
reduce the errors.
--
Glynn Clements gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: [GRASS-dev] raster interpolation and NULL cell filling
Markus Metz wrote: BTW, this module should probably stay in `raster/` instead of `vector\lidar`. For compilation it is easier if it is in vector/lidar because it uses stuff in lidarlib. Otherwise it will fail because raster modules are compiled before vector modules -lidarlib not yet available. Should vector/lidar/lidarlib be moved to lib/lidarlib? -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Problem with running Python script in GRASS
LeeDaniel wrote: My other question, though, is how to get newer versions of GRASS. I also considered going over to GRASS 7, it seems to be planned to deal a lot better with Python, but wasn't able to find it on the official GRASS page. Did I just overlook it, or is it available through some other source? I found some sources in the Internet but didn't quite trust them. http://grass.osgeo.org/download/software.php -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Error in Projection from Landsat images
Hi Kim Besson wrote: Greetings This topic was being discussed in converting Vector to raster and them I realized that it might be better to change it to here: I did gdalinfo to my landsat data is this: Driver: GTiff/GeoTIFF Files: L.tif Size is 7662, 7109 Coordinate System is: LOCAL_CS[ Geocoding information not available Projection From this it looks like gdal was not able to identify the coordinate system. There are lots of ETRS_1989 projections. Do you have any other way to know what the original CRS is? (BTW, original Landsat imagery are always in some UTM zone coordinates. Is that the case here? or is this some derived and reprojected TIFF?) Once you know the correct CRS, you'll be able to create a matching Location/mapset, import the vector layer, then convert to raster, etc... Name = ETRS_1989_Transverse_Mercator Units = meters Geo, UNIT[unknown,1]] Origin = (-52163.169232331842068,23020.214927441673353) Pixel Size = (30.000,-30.000) Metadata: TIFFTAG_SOFTWARE=IMAGINE TIFF Support Copyright 1991 - 1999 by ERDAS, Inc. All Rights Reserved @(#)$RCSfile: etif.c $ $Revision: 1.10.1.9.1.9.2.11 $ $Date: 2004/09/15 18:42:01EDT $ TIFFTAG_XRESOLUTION=1 TIFFTAG_YRESOLUTION=1 TIFFTAG_RESOLUTIONUNIT=1 (unitless) AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( -52163.169, 23020.215) Lower Left ( -52163.169, -190249.785) Upper Right ( 177696.831, 23020.215) Lower Right ( 177696.831, -190249.785) Center ( 62766.831, -83614.785) Band 1 Block=64x64 Type=Byte, ColorInterp=Red Band 2 Block=64x64 Type=Byte, ColorInterp=Green Band 3 Block=64x64 Type=Byte, ColorInterp=Blue Band 4 Block=64x64 Type=Byte, ColorInterp=Undefined Band 5 Block=64x64 Type=Byte, ColorInterp=Undefined Band 6 Block=64x64 Type=Byte, ColorInterp=Undefined It has geographic information right? and it's supposed to be recognized by GRASS. So I decided to create a new Location. 1- Define name of the location (landsat02) 2- Choose method for creating a new location: Read Projection and datums from a georreferenced file== I select the file I choose no in defining region 3- Enter into location 4- do g.region -p and I get: projection: 0 (x,y) zone: 0 north: 23020.21492744 south: -190249.78507256 west: -52163.16923233 east: 177696.83076767 nsres: 30 ewres: 30 rows: 7109 cols: 7662 cells: 54469158 Everything else seems ok except the Projection that is (x,y). This means that it's not recognizing the coordinate system or am I doing something wrong? Thank you Kim This mail was received via Mail-SeCure System. ___ 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 Arava Development Co. +972-52-3665918 http://www.surfaces.co.il ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRASS 7.0 - OS X install problem
Hi - I'm trying to install GRASS 7.0 on OS X 10.6.3 and ran into some problems: First some errors during the make process GRASS GIS compilation log Started compilation: Fri May 7 09:22:05 EDT 2010 Errors in: /Users/stu/grass_trunk/gui/wxpython /Users/stu/grass_trunk/visualization/nviz In case of errors please change into the directory with error and run 'make'. If you get multiple errors, you need to deal with them in the order they appear in the error log. If you get an error building a library, you will also get errors from anything which uses the library. I followed the instructions and get no errors on the first 're-make' and the following on the second: SEsMacPro:grass_trunk stu$ cd visualization/nviz SEsMacPro:nviz stu$ make make -C src gcc -g -O2 -I/Users/stu/grass_trunk/dist.i386-apple-darwin10.3.0/include -I/Users/stu/grass_trunk/dist.i386-apple-darwin10.3.0/include -D_FILE_OFFSET_BITS=64 -I/Library/Frameworks/Tcl.framework/Headers -I/Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tk.framework/PrivateHeaders -I/Library/Frameworks/Tcl.framework/Headers -I/Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tk.framework/PrivateHeaders -I/Users/stu/grass_trunk/dist.i386-apple-darwin10.3.0/include -I/Users/stu/grass_trunk/dist.i386-apple-darwin10.3.0/include -I/Library/Frameworks/UnixImageIO.framework/unix/include -I/Library/Frameworks/GDAL.framework/Versions/1.6/Headers -I/Library/Frameworks/GEOS.framework/Versions/3/unix/include -DPACKAGE=\grassmods\ -I/Users/stu/grass_trunk/dist.i386-apple-darwin10.3.0/include -I/Users/stu/grass_trunk/dist.i386-apple-darwin10.3.0/include -o OBJ.i386-apple-darwin10.3.0/togl.o -c togl.c In file included from /Library/Frameworks/Tk.framework/Headers/tkMacOSX.h:34, from togl.c:53: /Library/Frameworks/Tk.framework/Headers/tkPlatDecls.h:107: error: expected ‘)’ before ‘*’ token /Library/Frameworks/Tk.framework/Headers/tkPlatDecls.h:152: error: expected ‘)’ before ‘*’ token /Library/Frameworks/Tk.framework/Headers/tkPlatDecls.h:153: error: expected ‘;’ before ‘GWorldPtr’ togl.c: In function ‘Togl_CreateWindow’: togl.c:2221: warning: cast to pointer from integer of different size togl.c:2338: warning: ‘aglSetDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:313) togl.c: In function ‘Togl_EventProc’: togl.c:2594: warning: ‘AGLDrawable’ is deprecated togl.c:2596: warning: ‘aglSetDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:313) togl.c:2610: warning: ‘aglSetDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:313) togl.c: In function ‘Togl_LoadBitmapFont’: togl.c:3143: warning: ‘aglUseFont’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:374) make[1]: *** [OBJ.i386-apple-darwin10.3.0/togl.o] Error 1 make: *** [default] Error 2 make install creates the GRASS-7.0.app but on opening there is the following error: SEsMacPro:~ stu$ '/Applications/GRASS-7.0.app/Contents/MacOS/grass.sh'; exit Rebuilding Addon HTML manual pages index... cp: /Applications/GRASS-7.0.app/Contents/MacOS/docs/html/grass_icon.png: No such file or directory Rebuilding Addon menu... Python 2.6.4 found. /Applications/GRASS-7.0.app/Contents/MacOS/grass.sh: line 220: /Applications/GRASS-7.0.app/Contents/MacOS/etc/Init.sh: No such file or directory /Applications/GRASS-7.0.app/Contents/MacOS/grass.sh: line 220: exec: /Applications/GRASS-7.0.app/Contents/MacOS/etc/Init.sh: cannot execute: No such file or directory logout Seems that at some point an Init.sh file should have been created but doesn't exist. I note that the 7.0.app is about 37 Mb and the 6.4.app weighs in at 144 Mb - does that make sense? Thanks for any assistance -- Stu ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS 7.0 - OS X install problem
On May 7, 2010, at 10:05 AM, Stuart Edwards wrote: Hi - I'm trying to install GRASS 7.0 on OS X 10.6.3 and ran into some problems: SEsMacPro:grass_trunk stu$ cd visualization/nviz SEsMacPro:nviz stu$ make make -C src gcc -g -O2 -I/Users/stu/grass_trunk/dist.i386-apple-darwin10.3.0/include -I/Users/stu/grass_trunk/dist.i386-apple-darwin10.3.0/include -D_FILE_OFFSET_BITS=64 -I/Library/Frameworks/Tcl.framework/Headers -I/Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tk.framework/PrivateHeaders -I/Library/Frameworks/Tcl.framework/Headers -I/Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tk.framework/PrivateHeaders -I/Users/stu/grass_trunk/dist.i386-apple-darwin10.3.0/include -I/Users/stu/grass_trunk/dist.i386-apple-darwin10.3.0/include -I/Library/Frameworks/UnixImageIO.framework/unix/include -I/Library/Frameworks/GDAL.framework/Versions/1.6/Headers -I/Library/Frameworks/GEOS.framework/Versions/3/unix/include -DPACKAGE=\grassmods\ -I/Users/stu/grass_trunk/dist.i386-apple-darwin10.3.0/include -I/Users/stu/grass_trunk/dist.i386-apple-darwin10.3.0/include -o OBJ.i386-apple-darwin10.3.0/togl.o -c togl.c In file included from /Library/Frameworks/Tk.framework/Headers/tkMacOSX.h:34, from togl.c:53: /Library/Frameworks/Tk.framework/Headers/tkPlatDecls.h:107: error: expected ‘)’ before ‘*’ token /Library/Frameworks/Tk.framework/Headers/tkPlatDecls.h:152: error: expected ‘)’ before ‘*’ token /Library/Frameworks/Tk.framework/Headers/tkPlatDecls.h:153: error: expected ‘;’ before ‘GWorldPtr’ I'm not sure what's wrong with this one. I can take a closer look tonight. make install creates the GRASS-7.0.app but on opening there is the following error: SEsMacPro:~ stu$ '/Applications/GRASS-7.0.app/Contents/MacOS/grass.sh'; exit Rebuilding Addon HTML manual pages index... cp: /Applications/GRASS-7.0.app/Contents/MacOS/docs/html/grass_icon.png: No such file or directory Rebuilding Addon menu... Python 2.6.4 found. /Applications/GRASS-7.0.app/Contents/MacOS/grass.sh: line 220: /Applications/GRASS-7.0.app/Contents/MacOS/etc/Init.sh: No such file or directory /Applications/GRASS-7.0.app/Contents/MacOS/grass.sh: line 220: exec: /Applications/GRASS-7.0.app/Contents/MacOS/etc/Init.sh: cannot execute: No such file or directory logout Seems that at some point an Init.sh file should have been created but doesn't exist. I note that the 7.0.app is about 37 Mb and the 6.4.app weighs in at 144 Mb - does that make sense? I haven't looked at GRASS 7 on OS X in a while. It's possible the init.sh thing has changed radically. I'll take a look and see what's up. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of objects. - the wisdom of Tarzan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.proj or r.resamp.rst issues
Thanks Glynn.
That makes sense now. I did not know about the inherent problem of
overshooting in cubic interpolation. ASTER DEMs I have seem to be pretty
consistent in terms of data ranges and representation of values (based on
r.report), so I am not sure about the noise effect in my case. However,
does this mean that I am sort of out of corrective options if I want to
use cubic reprojection of imagery from Latlong to UTM? I mean I either use
nearest method for error-free reprojection or I have to be careful about the
results of cubic method. Finally, when you say use higher values for
tension parameter, I guess you mean values lower than default 40. such as
30. or 20.
Bulent
On Fri, May 7, 2010 at 5:08 AM, Glynn Clements gl...@gclements.plus.comwrote:
Bulent Arikan wrote:
I am running GRASS 6.5 svn (Snow Leopard). I have several ASTER GDEMs
(Latlong, 30m res.), which I reprojected into UTM using both 'nearest'
and
'cubic' methods ('r.proj'). Only in some imagery that are reprojected in
cubic, I ended up having couple of cells (literally, 1-2 cells out of 8
million in average) with minus (-) values. For example, in a DEM where
the
elevation values are between 800-2600 meters, I have cell values between
-150 and -85 meters. This does not seem to be an issue in reprojected
imagery with the nearest method. I am not sure how these minus values are
introduced at the first place.
Cubic interpolation can introduce overshoot, as can other forms of
spline interpolation. Linear and nearest-neighbor interpolation don't
have this issue.
With r.resamp.rst, the problem can be alleviated to a degree by using
higher values for the tension= parameter.
Also, if your data is noisy, this will tend to exaggerate the
gradients, making overshoot more likely. Filtering the data first will
reduce the errors.
--
Glynn Clements gl...@gclements.plus.com
--
BÜLENT ARIKAN
School of Human Evolution and Social Change
Arizona State University
Tempe - AZ
85287-2402
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
