Re: [GRASS-user] raster import GRASS tools in Qgis
Hi, open the raster 1st in Qgis (not through GRASS tools) Then use the GRASS tools, then you will find the file choices. Same is true for shape files too. You have another list for Qgis too. [EMAIL PROTECTED] Nice to find a fellow Indian on this list. Would you mind giving Institute: Present work with Open Source GIS: Interest in other Open source GIS. Namaste Ravi Kumar Tara Athan <[EMAIL PROTECTED]> wrote: I'm not sure if this is the right place to post this... I have a jpg file with a world file that was created by the Georeferencer in Quantum GIS. I am trying to bring this into a mapset using the GRASS tools in Quantum GIS and I am confused. When I open the r.in.global tool I don't see any choices for the files. Am I supposed to move the jpg/wld files into a particular directory in the mapset or is there something else I am missing? Thanks, Tara ___ 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
[GRASS-user] raster import GRASS tools in Qgis
I'm not sure if this is the right place to post this... I have a jpg file with a world file that was created by the Georeferencer in Quantum GIS. I am trying to bring this into a mapset using the GRASS tools in Quantum GIS and I am confused. When I open the r.in.global tool I don't see any choices for the files. Am I supposed to move the jpg/wld files into a particular directory in the mapset or is there something else I am missing? Thanks, Tara ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] error svn-update grass-addons
hi, i tried to update my svn-copy of the grass-addons (svn-client: Tortoise-svn on win xp - german version), but i've got the following error message : "Error: Can't open file 'C:\msys\1.0\local\src\grassaddonssvn\gipe\i.vi.grid\server\.svn\tmp\text-base\VI_Server::VI_CALC.ldif.svn-base': Falscher Parameter. " (false parameter) what's going wrong? the update of grass-svn is ok. helli -- helmut kudrnovsky email: [EMAIL PROTECTED] internet: www.alectoria.at __ GRATIS: Movie-FLAT. Jetzt freischalten! http://freemail.web.de/club/maxdome.htm/?mc=025557 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ascii - put1 of 4 columns to 3D point file attribute
On Mon, Apr 14, 2008 at 1:33 AM, Hamish <[EMAIL PROTECTED]> wrote: > Mark wrote: > > The points are about 5 million per tile, and there are 23 tiles (about > > 115 million total). I'm not sure if this is considered a large amount > > of mass input points. > > Yes, it's a lot. The current vector engine allocates a small amount of > memory per feature for topology. With the DBF as database and default > v.in.ascii settings I've only ever managed to import about 3 million > points before running out of memory. I am interested to hear that you > could load 5 million into a SQLite DB, maybe that is more efficient. The SQlite setup was so easy (thanks to the book), and then able to start working with the tables was a breeze (literally as easy as db.connect driver=sqlite database="$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db.) I'm not a SQL expert, but learned enough to do some sweet tasks. SQlite was rather impressive in working with 5.2 million records. Through v.in.ascii, it did load all the data (4 columns) into the sqlite database without problem (about 7 minutes on a 64bit 2.0GHz 2GB ram system - no table and no topology) > > With the v.in.ascii -t and -b flags you should be able to load 25million+ > points into a single vector map, but there is a limited number of modules > that will be able to use a vector map without topology. (importantly > v.surf.rst still works) > Ayone know if the v.outlier, v.lidar.edgedetect, v. lidar.grow and v.lidar.correction need topology? > > If you are willing to abandon your "code" data column, you can strip off > that column and import the rest as a 3D vector (-z z=), in which case no > table is created (or just ignore it with -t -z). If you are just > interested in the 3D coordinate, then a DB table is unneeded overhead and > is best skipped. > This approach turned out to be the best. You (Hamish) were right that the code was an intensity or strength of return signal. I made a nice "intensity" grayscale map, that was great. Since I dont need the intensity, or know how to use it to help separate the DEM from DSM features, the 3D point worked perfect. Thanks! > > > Question: what do you want to do with the data? Simply create a raster > DEM or do more fancy cleaning with v.lidar.*? If just creating a raster > DEM you might skip v.in.ascii altogether and use the r.in.xyz module. > > I will definitely look more closely at the r.in.xyz module. I had used it for some binning and statistical analysis of the point distribution of the lidar. it is pretty tight data. I want/need to do fancy cleaning with the v.lidar.* tools. However, not having pulse return counts to work with like the example in the book, I am not sure how well it will work, because only having an intensity value, I'm not sure how that relates to first and last returns. What I would like to do with the data is create a bare earth DEM, and a DSM of the elevated surface features. Then perhaps add elevated surface features like solid objects (e.g. buildings, etc) that would block terrain for shallow overland flow or r.lake simulations for flooding. Since the application is for watershed analysis (feature building, and ultimately running hydrology models in GRASS), so my goal is to create the most realistic hydrologic surface model to properly route the water. In theory, it seems to me that water should not route through solid features like buildings (extrude as walls?), but should be able to (and often does) route through shrubby or forested areas. In these areas, where there is canopy, it seems that those canopy elevations should be replaced with bare earth elevations, but allow water to flow through these areas. This is the first time I have worked with raw LiDAR data to create features or do watershed analysis, so this is a fun learning experience. Typically, I had worked with contour data in the past. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ascii - put1 of 4 columns to 3D point file attribute
On Mon, Apr 14, 2008 at 7:33 AM, Hamish <[EMAIL PROTECTED]> wrote: > Yes, it's a lot. The current vector engine allocates a small amount of > memory per feature for topology. With the DBF as database and default > v.in.ascii settings I've only ever managed to import about 3 million > points before running out of memory. I am interested to hear that you > could load 5 million into a SQLite DB, maybe that is more efficient. GRASS 6.3.0svn (patUTM):~/data/lidar_PAT_raw/raw > wc -l big.txt 13072022 big.txt GRASS 6.3.0svn (patUTM):~/data/lidar_PAT_raw/raw > head big.txt 659936.35 5096943.37 368.58 659900.34 5096968.01 1082.09 659900.23 5096966.73 1082.84 664549.79 5097099.35 234.83 664553.50 5097099.56 234.70 664551.90 5097098.79 234.70 664550.46 5097098.11 234.98 664557.22 5097099.75 234.71 664555.68 5097099.02 235.02 664554.24 5097098.33 235.02 GRASS 6.3.0svn (patUTM):~/data/lidar_PAT_raw/raw > date ; v.in.ascii big.txt out=big -z z=3 fs=space ; date Mon Apr 14 10:17:46 CEST 2008 Scanning input for column types... Maximum input row length: 29 Maximum number of columns: 3 Minimum number of columns: 3 Importing points... Building topology ... Registering lines: 10116000252000388000524000660000796000932001068001204001340001476001612001748001884002020002156002292002428002564002728360029720013072022 primitives registered 3072000 Building areas: 100% 0 areas built 0 isles built Attaching islands: Attaching centroids: 100% Topology was built. Number of nodes : 13070034 Number of primitives: 13072022 Number of points: 13072022 Number of lines : 0 Number of boundaries: 0 Number of centroids : 0 Number of areas : 0 Number of isles : 0 v.in.ascii complete. Mon Apr 14 11:25:21 CEST 2008 It took (despite the lines print overflow above) a bit more than 1h to import 13 million points into SQLite. Unfortunately v.univar cannot yet calculate on the x, y, or z geometry to perform further performance
[GRASS-user] Geoconnexion: Open Source #8: Grass Open Source GIS
New article about GRASS by Malte (promotion manager): http://www.geoconnexion.com/geo_issue/March_2008 -> Open Source #8: Grass Open Source GIS markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: R: [GRASS-dev] Re: [GRASS-user] trouble with v.rast.stats underWINGRASS
I installed the full version, not only the corrected script. Niels Hamish schrieb: Niels Thevs wrote: I installed WINGRASS 63 RC6 and tried again v.rast.stats. Before running it I chose a small region (only a bit more than 2 polygons). The following error messages were printed: :/GRASS/scripts/v.rast.stats: v.db.addcol: command not found DBMI-DBF driver error: Column 'qb4_reg1_n' not found Error in db_execute_immediate() Error while executing: 'UPDATE kacheladdstat SET qb4_reg1_n=1020 WHERE cat=24495' Statistics calculated from raster map <[EMAIL PROTECTED]> and uploaded to attribute table of vector map . Done. The dbf file of the vector has not been altered. "v.db.addcol: command not found" is the key, the rest of the problems are just due to that failing. Did you install a full version of GRASS 6.3.0rc6 or just upgrade the v.rast.stats script from there? In 6.3svn I have just modified v.rast.stats (r30976) to better deal with v.db.addcol errors. It already had a test to see if v.db.addcol failed (exit code 1), but not if it failed because it couldn't run (for me on linux: exit code 127). Now it stops for any error. Hamish Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -- - Dr. Niels Thevs Chair of Geobotany and Landscape Ecology Institute of Botany and Landscape Ecology Greifswald University Grimmer Strasse 88 17487 Greifswald Germany Tel.: +49-3834-86-4137 Fax: +49-3834-86-4114 - ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
