Re: [GRASS-user] problem on vectorizing a float point raster
I think that r.to.vect wants to build a line structure, like river channels, but sees all the raster cells occupied, so no linear structure, and the advice to thin first is then appropriate. If this is connected to your question about calculating a measure of spatial autocorrelation for the raster data, then I suspect that you do not need polygons but rather points, where r.out.xyz may be helpful, followed by v.in.ascii if you will be using GRASS downstream, or if you want to emit a shapefile for GeoDa (another posting). If you really want to calculate a measure of spatial autocorrelation for your raster, I suggest copying the raster to R with readRAST6, creating the neighbour list with dnearneigh() with max. distance the greater of ewres and nsres, and proceeding from there in the usual way. But please consider the inevitable fact that unless the resolution of your raster matches the natural support of the phenomenon of interest, the observed autocorrelation will certainly be driven by your having multiple neighbouring observations of each entity, in addition to not having demeaned (detrended) the data. This means that any results will almost certainly be spurious. Hope this helps, Roger Milton Cezar Ribeiro wrote: Dear Grass-Gurus, I have a 2400x2200 raster image with values ranging from 0.1 to 42, in float format. Now I need vetororize the image, on the way that each pixel come to be a polygon and the pixel value be stored as attribute. I am trying to do this using: r.to.vect input=temp71.img output=temp71_img_integer_vect_200m --o -b but grass return the following error messages: GRASS 6.4.0svn (newLocation):C:/GRASS-6-SVN/msys/home/mjfortin r.to.vect inpu t=temp71.img output=temp71_img_integer_vect_200m --o -b WARNING: Vector map temp71_img_integer_vect_200m already exists and will be overwritten WARNING: Table temp71_img_integer_vect_200m linked to vector map temp71_img_integer_vect_200m does not exist Extracting lines... ERROR: Raster map is not thinned properly. Please run r.thin. By the way, I am running grass under a WinXp 64bit. Any help are welcome. Cheers milton brazil=toronto ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user - Roger Bivand Economic Geography Section Department of Economics Norwegian School of Economics and Business Administration Helleveien 30 N-5045 Bergen, Norway -- View this message in context: http://n2.nabble.com/problem-on-vectorizing-a-float-point-raster-tp3052124p3054013.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 on vectorizing a float point raster
The other thread was on the openspace list and was concerned with calculating local Moran's Ii. My comments there copied here for completeness: In your case, temperature will be being driven by altitude at least, and possibly other important omitted variables. I also think that you will find exploratory variography on the (detrended) data, or perhaps rather a sample of the data (about 4M observations), might give some information. But I don't think that squeezing your data into an inappropriate methods setting is going to help much, and I'm pretty certain that just comparing the output of a function of your input data and GRASS r.neighbors average values for increasing values of the size parameter would be sufficient to display the local dependence, most of which will still be driven by the trend. For example in spearfish: g.region rast=elevation.dem r.univar -g map=elevation.dem # to get the mean and variance values r.mapcalc 'demean_elev=elevation.dem-1353.66931789804' r.neighbors -c input=demean_elev output=demean_elev3 method=average size=3 r.mapcalc 'Ii=(demean_elev*demean_elev3)/31343.402316476' Then compare histograms and displays of Ii for increasing values of size. Roger Roger Bivand wrote: I think that r.to.vect wants to build a line structure, like river channels, but sees all the raster cells occupied, so no linear structure, and the advice to thin first is then appropriate. If this is connected to your question about calculating a measure of spatial autocorrelation for the raster data, then I suspect that you do not need polygons but rather points, where r.out.xyz may be helpful, followed by v.in.ascii if you will be using GRASS downstream, or if you want to emit a shapefile for GeoDa (another posting). If you really want to calculate a measure of spatial autocorrelation for your raster, I suggest copying the raster to R with readRAST6, creating the neighbour list with dnearneigh() with max. distance the greater of ewres and nsres, and proceeding from there in the usual way. But please consider the inevitable fact that unless the resolution of your raster matches the natural support of the phenomenon of interest, the observed autocorrelation will certainly be driven by your having multiple neighbouring observations of each entity, in addition to not having demeaned (detrended) the data. This means that any results will almost certainly be spurious. Hope this helps, Roger Milton Cezar Ribeiro wrote: Dear Grass-Gurus, I have a 2400x2200 raster image with values ranging from 0.1 to 42, in float format. Now I need vetororize the image, on the way that each pixel come to be a polygon and the pixel value be stored as attribute. I am trying to do this using: r.to.vect input=temp71.img output=temp71_img_integer_vect_200m --o -b but grass return the following error messages: GRASS 6.4.0svn (newLocation):C:/GRASS-6-SVN/msys/home/mjfortin r.to.vect inpu t=temp71.img output=temp71_img_integer_vect_200m --o -b WARNING: Vector map temp71_img_integer_vect_200m already exists and will be overwritten WARNING: Table temp71_img_integer_vect_200m linked to vector map temp71_img_integer_vect_200m does not exist Extracting lines... ERROR: Raster map is not thinned properly. Please run r.thin. By the way, I am running grass under a WinXp 64bit. Any help are welcome. Cheers milton brazil=toronto ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user - Roger Bivand Economic Geography Section Department of Economics Norwegian School of Economics and Business Administration Helleveien 30 N-5045 Bergen, Norway -- View this message in context: http://n2.nabble.com/problem-on-vectorizing-a-float-point-raster-tp3052124p3054112.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 on vectorizing a float point raster
Hello Milton Roger's answer was, as always, both complete and to the point. As a further exercise, I took a small region of 54 cells with floating point values, and using the feature=area option to r.to.vect I created a vector map of polygons. It produced over 36 polygons. Most will be polygons of 1 cell in size (from the original raster). I assume that's *not* what you're looking for... -- Micha Roger Bivand wrote: I think that r.to.vect wants to build a line structure, like river channels, but sees all the raster cells occupied, so no linear structure, and the advice to thin first is then appropriate. If this is connected to your question about calculating a measure of spatial autocorrelation for the raster data, then I suspect that you do not need polygons but rather points, where r.out.xyz may be helpful, followed by v.in.ascii if you will be using GRASS downstream, or if you want to emit a shapefile for GeoDa (another posting). If you really want to calculate a measure of spatial autocorrelation for your raster, I suggest copying the raster to R with readRAST6, creating the neighbour list with dnearneigh() with max. distance the greater of ewres and nsres, and proceeding from there in the usual way. But please consider the inevitable fact that unless the resolution of your raster matches the natural support of the phenomenon of interest, the observed autocorrelation will certainly be driven by your having multiple neighbouring observations of each entity, in addition to not having demeaned (detrended) the data. This means that any results will almost certainly be spurious. Hope this helps, Roger Milton Cezar Ribeiro wrote: Dear Grass-Gurus, I have a 2400x2200 raster image with values ranging from 0.1 to 42, in float format. Now I need vetororize the image, on the way that each pixel come to be a polygon and the pixel value be stored as attribute. I am trying to do this using: r.to.vect input=temp71.img output=temp71_img_integer_vect_200m --o -b but grass return the following error messages: GRASS 6.4.0svn (newLocation):C:/GRASS-6-SVN/msys/home/mjfortin r.to.vect inpu t=temp71.img output=temp71_img_integer_vect_200m --o -b WARNING: Vector map temp71_img_integer_vect_200m already exists and will be overwritten WARNING: Table temp71_img_integer_vect_200m linked to vector map temp71_img_integer_vect_200m does not exist Extracting lines... ERROR: Raster map is not thinned properly. Please run r.thin. By the way, I am running grass under a WinXp 64bit. Any help are welcome. Cheers milton brazil=toronto ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user - Roger Bivand Economic Geography Section Department of Economics Norwegian School of Economics and Business Administration Helleveien 30 N-5045 Bergen, Norway ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] hdf4 missing in gdal 1.6.1-2
Thanks a lot. I will try to figure that out. Stefan Hamish wrote: Stefan wrote: I have Ubuntu 9.04 installed and I use the repository for GRASS64 rc4 on http://les-ejk.c. As far as I know, I have never been using a repos on DebianGIS neither on UbuntuGIS. Ubuntu packages are often directly rebuilt from the Debian/unstable packages. I don't really know, but suppose Jachym may do the same, but in this case pulling from Debian/experimental to get the latest GDAL version. i.e. they are all derived from the same parent and everybody shares and builds on each other's work. I just killed gdal 1.6.1-2 and reinstalled gdal-bin 1.5.2-3, and now everything works, my ASTER-HDF images are readable again. But I am still wondering why they do not include the hdf4-library in the latest gdal-version? I believe you can read why that is and see the game-plan for the future in the DebianGIS mailing list archives. If you think the plan could be better feel free to suggest improvements there, but be prepared to hear that the packaging game is a multi-dimensional compromise, especially when your package is depended on by a host of other packages and filters through into a number of other distributions. If it is a real problem you can always rebuild packages locally, it is fairly easy to do. (study debuild) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- View this message in context: http://n2.nabble.com/hdf4-missing-in-gdal-1.6.1-2-tp3048480p3054165.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] hdf4 missing in gdal 1.6.1-2
sela wrote: I just killed gdal 1.6.1-2 and reinstalled gdal-bin 1.5.2-3, and now everything works, my ASTER-HDF images are readable again. But I am still wondering why they do not include the hdf4-library in the latest gdal-version? This may be a packaging problem. See gdal wiki for details, under the section Potential conflicts with internal libz: http://trac.osgeo.org/gdal/wiki/HDF Craig ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] calculate speed fron GPX in GRASS
I want to calculate the speed of my GPS trace in grass. Converting the vector points where an attribute speed is added. Any ideas how to do it? -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] calculate speed fron GPX in GRASS
maning wrote: I want to calculate the speed of my GPS trace in grass. Converting the vector points where an attribute speed is added. Any ideas how to do it? use a gpsbabel filter directly on the GPX file. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] i.atcorr with ASTER L1B
Hi, has anyone ever performed atmospheric correction with i.atcorr on ASTER L1B images? I am wondering because there are no templates for geometrical conditions or sensor bands (like there are for Landsat, Modis, AVHRR etc.). I am not sure if all the information required for the i.atcorr 6S algorithm is included within the ASTER L1B header. I tried to find out but I am coming to my limits when trying to find the right entries in the header file. So maybe there is someone out there who has some experience on the ASTER L1B case... Greetings Stefan -- View this message in context: http://n2.nabble.com/i.atcorr-with-ASTER-L1B-tp3055587p3055587.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] ps.map area fill pattern location variable
John wrote: I'm making a map with postscript fill patterns using the vareas option in ps.map. In the wiki pages, the path to the fill patterns is: $GISBASE/etc/paint/patterns/diag_up.eps But when I use that in the script, the $GISBASE variable is not expanded and I get the error: can't open eps file $GISBASE/etc/paint/patterns/diag_up.eps The file does exist and can be accessed at the location from the GRASS prompt. Why doesn't ps.map expand the variable? that example is expecting input from stdin not a file, so the shell expands it. e.g. ps.map out=test.ps EOF raster elevation vareas fields pattern $GISBASE/etc/paint/patterns/diag_up.eps end end EOF for input from a real file you have to type out the full path. type echo $GISBASE at the grass terminal prompt to get that. I've just modified the code in 6.5 and 7.x svn to automatically expand $GISBASE for you if it is found in the EPS filename and input is from a file. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] problem on vectorizing a float point raster
Dear Roger and Micha, Thank you for the reply. I will read carefully your coments, and write back again. Both you clarified some interesting points to me. cheers, milton brazil=toronto 2009/6/10 Micha Silver mi...@arava.co.il Hello Milton Roger's answer was, as always, both complete and to the point. As a further exercise, I took a small region of 54 cells with floating point values, and using the feature=area option to r.to.vect I created a vector map of polygons. It produced over 36 polygons. Most will be polygons of 1 cell in size (from the original raster). I assume that's *not* what you're looking for... -- Micha Roger Bivand wrote: I think that r.to.vect wants to build a line structure, like river channels, but sees all the raster cells occupied, so no linear structure, and the advice to thin first is then appropriate. If this is connected to your question about calculating a measure of spatial autocorrelation for the raster data, then I suspect that you do not need polygons but rather points, where r.out.xyz may be helpful, followed by v.in.ascii if you will be using GRASS downstream, or if you want to emit a shapefile for GeoDa (another posting). If you really want to calculate a measure of spatial autocorrelation for your raster, I suggest copying the raster to R with readRAST6, creating the neighbour list with dnearneigh() with max. distance the greater of ewres and nsres, and proceeding from there in the usual way. But please consider the inevitable fact that unless the resolution of your raster matches the natural support of the phenomenon of interest, the observed autocorrelation will certainly be driven by your having multiple neighbouring observations of each entity, in addition to not having demeaned (detrended) the data. This means that any results will almost certainly be spurious. Hope this helps, Roger Milton Cezar Ribeiro wrote: Dear Grass-Gurus, I have a 2400x2200 raster image with values ranging from 0.1 to 42, in float format. Now I need vetororize the image, on the way that each pixel come to be a polygon and the pixel value be stored as attribute. I am trying to do this using: r.to.vect input=temp71.img output=temp71_img_integer_vect_200m --o -b but grass return the following error messages: GRASS 6.4.0svn (newLocation):C:/GRASS-6-SVN/msys/home/mjfortin r.to.vect inpu t=temp71.img output=temp71_img_integer_vect_200m --o -b WARNING: Vector map temp71_img_integer_vect_200m already exists and will be overwritten WARNING: Table temp71_img_integer_vect_200m linked to vector map temp71_img_integer_vect_200m does not exist Extracting lines... ERROR: Raster map is not thinned properly. Please run r.thin. By the way, I am running grass under a WinXp 64bit. Any help are welcome. Cheers milton brazil=toronto ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user - Roger Bivand Economic Geography Section Department of Economics Norwegian School of Economics and Business Administration Helleveien 30 N-5045 Bergen, Norway ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] hdf4 missing in gdal 1.6.1-2
Thanks a lot, Craig. I think that's it. Stefan Craig Leat wrote: sela wrote: I just killed gdal 1.6.1-2 and reinstalled gdal-bin 1.5.2-3, and now everything works, my ASTER-HDF images are readable again. But I am still wondering why they do not include the hdf4-library in the latest gdal-version? This may be a packaging problem. See gdal wiki for details, under the section Potential conflicts with internal libz: http://trac.osgeo.org/gdal/wiki/HDF Craig ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- View this message in context: http://n2.nabble.com/hdf4-missing-in-gdal-1.6.1-2-tp3048480p3055910.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] Density of points in a vector layer
Hello, I'm using grass in combination with qgis; I would know how can I calculate the density of points in a vector layer. In the past I used gvsig and Sextante, in particular I used density kernel tool. Which equivalent application can I use in Grass? Thank you for any useful advice! Paolo Tomè ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Density of points in a vector layer
See v.kernel Cheers, Dylan On Wed, Jun 10, 2009 at 7:42 AM, Paolo Tomepaolo_t...@hotmail.com wrote: Hello, I'm using grass in combination with qgis; I would know how can I calculate the density of points in a vector layer. In the past I used gvsig and Sextante, in particular I used density kernel tool. Which equivalent application can I use in Grass? Thank you for any useful advice! Paolo Tomè ___ 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] Editing dbf, problem
I was trying to edit one of my point vector dbf files in the file PERMANENT/dbf. I used the spreadsheet in Openoffice to adjust a .dbf file. The STR_1 column originally read #1 %64 @Cat. 64. I needed the Cat. 64 for a label on my map so I edited the column to read just Cat. 64. Now when I resize the size of the Map Display Window, everything freezes. If I leave the map display window alone I can work with the project a little, but GRASS (or WISH) unexpectedly quits, usually sooner rather than later. I tried to at the #1 %64 with the quotation marks back, but this didn't help. Can anyone tell what the problem is and how to fix it? Since I am using Qgis to do the actual displaying (and it doesn't seem to have the problem) I'll be fine, unless I have to adjust something in GRASS. Then I will need a back up plan. Thanks for any insight that people may have. Kurt ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Density of points in a vector layer
On Wed, Jun 10, 2009 at 8:27 AM, Paolo Tomepaolo_t...@hotmail.com wrote: Thanks for your reply, I tried to use v.kernel but the result is not very satisfactory (a raster uniformly colored of gray), I don't have much familiarity with the console, then I use the graphical interface of the application (using QGIS) . Then I can set only the maps in Stdeviation units (parameter which I did not understand the full meaning). Can you give me some guidance on how to obtain a better result? Thank you very much. Hi Paolo, The command line is the most flexible approach to using GRASS. When using modules that generate raster output you need to consider the region resolution and extent. Have a look at the raster intro (http://grass.itc.it/grass64/manuals/html64_user/rasterintro.html). You will need to work out a resolution that makes sense, then set it with g.region. Finally, you will have to tinker around with the stddev option to v.kernel for results that look right to you. Think of this parameter as the diameter of the 'filter' in which point densities are calculated. The size of this parameter will be a function of your dataset and the region parameters. This module could use an updated manual page, as its usage is somewhat mysterious. Cheers, Dylan On mer, 2009-06-10 at 08:18 -0700, Dylan Beaudette wrote: See v.kernel Cheers, Dylan On Wed, Jun 10, 2009 at 7:42 AM, Paolo Tomepaolo_t...@hotmail.com wrote: Hello, I'm using grass in combination with qgis; I would know how can I calculate the density of points in a vector layer. In the past I used gvsig and Sextante, in particular I used density kernel tool. Which equivalent application can I use in Grass? Thank you for any useful advice! Paolo Tomè ___ 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
Re: [GRASS-user] exponentiation with v.db.update
On 09/06/09 18:38, A. Marcia BARBOSA wrote: Yeah I'm doing it on a dbf attribute table. It doesn't work with the quotes, nor with power(10,x) - error message always. Does anyone know how to do an exponentiation update on a dbf table? Or do I really have to do the update outside GRASS and then re-connect the table? SQL for dbf is very limited [1,2], so you would have to either do it outside GRASS, or switch to a more sophisticated SQL backend. Moritz [1]http://grass.osgeo.org/grass64/manuals/html64_user/sql.html [2]http://grass.osgeo.org/grass64/manuals/html64_user/grass-dbf.html ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Editing dbf, problem
The dbf file started life as an ascii file written in Textwrangler. I converted via v.in.ascii. The code I used was reminiscent of what I use to use to create a site using s.in.ascii. I couldn't find out if the codes changed for v.in.ascii. I have tried using various databases for my archaeological sites, without success. I tried following the book but I must be missing something. I have SQLite Browser, it seems easy to use, but I have trouble connecting it. (I haven't touched it in a while.) How do you set up the columns for easting and northing (UTM). What about other kinds of data (in this case the Catalog number). Then how do you make it display as a point vector (in this case). The GRASS book is a little vague, when I need a step by step approach. Thanks for your help. Kurt On Jun 10, 2009, at 11:36 AM, Dylan Beaudette wrote: On Wed, Jun 10, 2009 at 8:23 AM, Kurt Springsferret_b...@mac.com wrote: I was trying to edit one of my point vector dbf files in the file PERMANENT/dbf. I used the spreadsheet in Openoffice to adjust a .dbf file. The STR_1 column originally read #1 %64 @Cat. 64. I needed the Cat. 64 for a label on my map so I edited the column to read just Cat. 64. Now when I resize the size of the Map Display Window, everything freezes. If I leave the map display window alone I can work with the project a little, but GRASS (or WISH) unexpectedly quits, usually sooner rather than later. I tried to at the #1 %64 with the quotation marks back, but this didn't help. Can anyone tell what the problem is and how to fix it? Since I am using Qgis to do the actual displaying (and it doesn't seem to have the problem) I'll be fine, unless I have to adjust something in GRASS. Then I will need a back up plan. Thanks for any insight that people may have. Kurt Hi Kurt, I (and others on the list) have encountered a variable degree of success when working with DBF files opened/saved by an external program. In some cases it works, in others the datatype (or something) of a column will change and all hell breaks loose. I have seen this in both GRASS and ESRI programs -- it just seems like the DBF file format is very fragile. If possible, try converting your database back-end to SQLite-- there are many good GUI-based tools for working on SQLite files, and the SQLite engine has full support for SQL. It can be a pain to switch between database back-ends, but I wish that I had done it sooner. Good luck, Dylan ___ 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] v.to.rast question
Hi all, I was wondering if anyone could enlighten me about how exactly the v.to.rast function works. I would like to turn a vector layer of polygons into a raster layer. Basically, my layer shows where a species occurs (the value for the areas where they occur is 1). When I transform this vector into a raster file, how does v.to.rast decide what raster cell becomes 1 versus which becomes a 0? Does it depend on what percentage of the raster cell is covered by the polygon, or does the cell get a 1 assigned to it as soon as the polygon transects it at all? Thank you for any help given! ~ Anke ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] SVN access: problems
Hi all, not sure if this is the right place. I was trying to checkout grass 7.0 from svn, but I get errors: $ svn checkout http://svn.osgeo.org/grass/grass/trunk grass_trunk svn: OPTIONS of 'http://svn.osgeo.org/grass/grass/trunk': could not connect to server (http://svn.osgeo.org) the same on https. Also, that happened while I was trying to checkout QGIS too. I recall having write access to the grass tree a while ago, but since I haven't commited for a long while, I am wondering if I am still privileged =] -- Paulo Marcondes = PU1/PU2PIX -22.915 -43.224 = GG87jc = Corrected ! -23.578 -46.671 = GG66pk ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.to.rast question
Anke Konrad wrote: I was wondering if anyone could enlighten me about how exactly the v.to.rast function works. I would like to turn a vector layer of polygons into a raster layer. Basically, my layer shows where a species occurs (the value for the areas where they occur is 1). When I transform this vector into a raster file, how does v.to.rast decide what raster cell becomes 1 versus which becomes a 0? Does it depend on what percentage of the raster cell is covered by the polygon, or does the cell get a 1 assigned to it as soon as the polygon transects it at all? If I recall, that is explained in the help page for each type. Feel free to point out the paragraph there that needs to be expanded. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.thin quirk
On Jun 6, 2009, at 11:36 PM, Dwight Needels wrote: Hi all. I have run into a quirk using r.thin, but I am not sure whether or not it is a bug. I have a raster that was generated from multiple GPS tracks using v.rast followed by r.buffer. Using r.thin followed by r.to.vect creates a vector that must then be cleaned using v.clean to remove dangles (so far, so good). The quirk is that r.thin occasionally creates a triangle at the intersection of two lines instead of two intersecting lines. All of the examples I have seen involve relatively acute angles (less than 25 degrees??). I have attached a screenshot that shows the raster in magenta, the vector with dangles in white, and the cleaned vector as (a thinner) green. There are numerous acute angles that generate the vectors I would expect, with one exception in the center. Is this expected behavior? If so, is there an easy way to search for all such resulting triangles in a vector or to remove all such extra lines in a vector? If not, is there a way to fix it? Thanks, -Dwight r.thin.png ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user Although I figured out how to file a bug report on this, http://trac.osgeo.org/grass/ticket/636 , I am not sure how to respond directly to comments on the ticket. Hamish, I used the screenshot showing the vectors because I had already created it to look for artifacts. The extra line that makes the triangle is also present in the thinned raster (screenshot attached). Thanks, -Dwight inline: r.thin_raster.png ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.thin quirk
On Jun 11, 2009, at 12:01 AM, Dwight Needels wrote: On Jun 6, 2009, at 11:36 PM, Dwight Needels wrote: Hi all. I have run into a quirk using r.thin, but I am not sure whether or not it is a bug. I have a raster that was generated from multiple GPS tracks using v.rast followed by r.buffer. Using r.thin followed by r.to.vect creates a vector that must then be cleaned using v.clean to remove dangles (so far, so good). The quirk is that r.thin occasionally creates a triangle at the intersection of two lines instead of two intersecting lines. All of the examples I have seen involve relatively acute angles (less than 25 degrees??). I have attached a screenshot that shows the raster in magenta, the vector with dangles in white, and the cleaned vector as (a thinner) green. There are numerous acute angles that generate the vectors I would expect, with one exception in the center. Is this expected behavior? If so, is there an easy way to search for all such resulting triangles in a vector or to remove all such extra lines in a vector? If not, is there a way to fix it? Thanks, -Dwight r.thin.png ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user Although I figured out how to file a bug report on this, http://trac.osgeo.org/grass/ticket/636 , I am not sure how to respond directly to comments on the ticket. Hamish, I used the screenshot showing the vectors because I had already created it to look for artifacts. The extra line that makes the triangle is also present in the thinned raster (screenshot attached). Thanks, -Dwight r.thin_raster.png Follow-up... the two examples of this happening in this particular file each have a single white pixel surrounded on 7 out of 8 directions by red pixels, but still touching a white pixel on a corner in the 8th direction (see two screenshots). I suspect that r.thin is treating this as a hole even though it is touching an edge. Another way of saying this is that the two red pixels touching in 1 out of the 8 directions are treated as a line. Perhaps there could be a flag to control this behavior. Thanks, -Dwight inline: r.thinpinched_1.pnginline: r.thinpinched_2.png___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
