[GRASS-user] Re: [Qgis-user] Nearest neighbour analysis
These are separate layers with no duplicate points. I have tried it with several layers, in multiple projects. Only one gave results, and that was relatively quickly. I the coordinates in sqlite, there should be no distance of zero. [later] As I wrote this, I decided to do some experimenting. I found something interesting. Normally I use GRASS for a lot of my analysis. I then in qgis, I just add GRASS vector or raster layers. It seems that is the problem. Occasionally a layer works (usually my wedge tombs), but mostly not. However, I tried some shape files that I down loaded, and it works fine. So, I exported the GRASS vectors to shape files and it works fine, even with layers that didn't work before. So the solution is to export from GRASS to ESRI Shape then open the shape file in qgis. BTW don't try to export a GRASS vector file from qgis. It doesn't seem to work. You have to export from GRASS. This observation didn't seem to have anything to do with the database. The GRASS vectors are mostly sqlite now, but some of my older ones are dbf. The problem seems to be the GRASS vectors themselves. Thanks Carson. Kurt On Dec 7, 2010, at 5:46 PM, Carson Farmer wrote: > Does the layer you were testing with have any duplicate points (i.e. > neighbours with zero distanace)? I wouldn't think this should matter, > but it might? Have you tried it with other layers (rather than just > subsets of the same layer)? > > Carson > > On 7 December 2010 20:03, Kurt Springs wrote: >> I use OS X 10.6.5, and William Kyngesburye's Qgis 1.6.0-1 and GDAL Complete >> 1.7. >> >> Kurt >> On Dec 7, 2010, at 2:53 PM, Carson Farmer wrote: >> >>> Hi Kurt, >>> I've been playing with some of Qgis's vector analysis tools. Has anyone tried using the Nearest neighbour analysis, under Vector=>Analysis Tools? I have tried it and after seeing the black and white wheel for a while, nothing happens. How long should it take, depending on the population size? I've tried populations as small as five and bigger. >>> I just tested this using the 'popp' point layer from the vmap0 QGIS >>> sample data, and it ran in about 1 second (incidentally, the nearest >>> neighbour index turns out to be 0.4 for this dataset). I also tested >>> it with larger and smaller layers and all seemed fine. Which OS and >>> version of QGIS & GDAL are you running? >>> >>> Carson >>> >>> -- >>> Carson J. Q. Farmer >>> ISSP Doctoral Fellow >>> National Centre for Geocomputation >>> National University of Ireland, Maynooth, >>> http://www.carsonfarmer.com/ >> >> > > > > -- > Carson J. Q. Farmer > ISSP Doctoral Fellow > National Centre for Geocomputation > National University of Ireland, Maynooth, > http://www.carsonfarmer.com/ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Problem with Lidar Tools
Hi Mark, It's mostly urban, with large buildings. There are some areas of parkland with scattered trees. Ben -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Problem-with-Lidar-Tools-tp3918684p5813897.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] Re: Problem with Lidar Tools
On Tue, Dec 7, 2010 at 7:53 PM, benmarillier wrote: > > Hi All, > > I am having similar problems to Kaipi in regards to the v.lidar.growing > stage of LiDAR processing. I'm running GRASS 6.4.0 on Windows. My dataset is > a 1km by 1km tile of LiDAR with a point spacing of about 1.5 points/m2, so a > total of about 1.5 million in the area of interest. > > Thus far I've imported the points with v.in.ascii, split into the first > returns and last returns. I interpreted these two classes as follows (please > correct me if I'm wrong)... > > First returns: all first returns, including single returns where only one > return has been received. > Last returns: all single returns, and the last return where multiple returns > have been received. > > Then I removed outliers as per the micro-tutorial on the GRASS wiki. > > Next I ran v.lidar.edgedetection on the last returns with the default > parameters. > > This resulted in a reasonable looking classification of edge (2), not-edge > (1) and uncertain (3). The edges of the buildings and trees are quite well > defined, as shown in the image below, so far so good... > > ...however, when I run v.lidar.growing (default parameters), the output I > get is exactly the same as the edgedetection output. The points are > classified identically into 1, 2 and 3, and there appears to have been no > change in the classification. I've tried varying the growing parameters, and > changing the region resolution, but the output is always the same. > > I've trawled through the forums to no avail, so any advice would be greatly > appreciated. > > Thanks, > Ben Hi. Is this urban, rural, or mixed land use? Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Problem with Lidar Tools
Hi All, I am having similar problems to Kaipi in regards to the v.lidar.growing stage of LiDAR processing. I'm running GRASS 6.4.0 on Windows. My dataset is a 1km by 1km tile of LiDAR with a point spacing of about 1.5 points/m2, so a total of about 1.5 million in the area of interest. Thus far I've imported the points with v.in.ascii, split into the first returns and last returns. I interpreted these two classes as follows (please correct me if I'm wrong)... First returns: all first returns, including single returns where only one return has been received. Last returns: all single returns, and the last return where multiple returns have been received. Then I removed outliers as per the micro-tutorial on the GRASS wiki. Next I ran v.lidar.edgedetection on the last returns with the default parameters. This resulted in a reasonable looking classification of edge (2), not-edge (1) and uncertain (3). The edges of the buildings and trees are quite well defined, as shown in the image below, so far so good... ...however, when I run v.lidar.growing (default parameters), the output I get is exactly the same as the edgedetection output. The points are classified identically into 1, 2 and 3, and there appears to have been no change in the classification. I've tried varying the growing parameters, and changing the region resolution, but the output is always the same. I've trawled through the forums to no avail, so any advice would be greatly appreciated. Thanks, Ben -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Problem-with-Lidar-Tools-tp3918684p5813852.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] Where the grassdata base resides
In order for GRASS to run properly, is it necessary for the grassdata folder (database) to reside at the disk prompt (as in C:\grassdata)? I would rather have it higher up [farther down?] in the hierarchy, such as C:\GIS\placename, because it is more intuitive to me that way. However, when I try that, GRASS crashes on start-up. But when I use C:\grassdata arrangement, it starts up fine. Thank you. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Where-the-grassdata-base-resides-tp5813667p5813667.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] i.atcorr problems for ALOS, Ikonos and RapidEye
Dear list, I just realized that there are some problems with the filter functions used to do the atmospheric correction for the Alos AVNIR2, Ikonos and RapidEye sensors. I expect to fix some of those bugs this week so please, use i.atcorr with care if you work with these sensors. Sorry for the inconvenience Daniel ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Importing of raster data doesn't seem to work through GUI
On 12/07/2010 04:08 PM, Martin Landa wrote: Hi, 2010/12/6 Micha Silver: I think I have an idea why the GUI isn't working. I noticed in your first post that the LandSAT tif files are named with CAPS in the filename extension, i.e. 171146051_05122001402_B10.TIF. It looks to me that the GUI ignores files name *.TIF and only "sees" *.tif. this bug hopefully fixed by r44554. Great. Thanks, Martin. Martin -- 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
Re: [GRASS-user] Re: Importing of raster data doesn't seem to work through GUI
Hi, 2010/12/6 Micha Silver : > I think I have an idea why the GUI isn't working. I noticed in your first > post that the LandSAT tif files are named with CAPS in the filename > extension, i.e. 171146051_05122001402_B10.TIF. It looks to me that the GUI > ignores files name *.TIF and only "sees" *.tif. this bug hopefully fixed by r44554. 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] v.voronoi SegFault
Hi List Running v.voronoi in Grass 6.4 (.deb package) and 6.5 svn on Debian I get segmentation fault error: GRASS 6.5.svn (Basilicata):~ > v.voronoi input=stazi...@suolo_paesoutput=voronoi --overwrite WARNING: Vector map already exists and will be overwritten Reading sites... Voronoi triangulation... Segmentation fault It does create a map, which is: GRASS 6.5.svn (Basilicata):~ > v.info map=voronoi WARNING: Coor files of vector map is larger than it should be (14 bytes excess) ++ | Layer: voronoi | | Mapset: suolo_paes| | Location: Basilicata| | Database: /home/madi/grassdata | | Title: | | Map scale: 1:1 | | Map format: native| | Name of creator: madi | | Organization: | | Source date: Tue Dec 7 14:22:51 2010 | || | Type of Map: vector (level: 1) | | | | 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: No | | Number of dblinks: 0| | | | Projection: Universal Transverse Mercator (zone 0) | | N: 0S: 0 | | E: 0W: 0 | | | | Digitization threshold: 0| | Comments:| | | ++ Any suggest? Thank you in advance -Margherita ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: v.in-out quirks
On 07/12/2010 12:52, Shane Litherland wrote: now, to spend a bit more time in GRASS and come up with my next 'victim'.. I reckon I can give v.digit and its friends a good workout! Oh, v.digit will give you a good run for your money ;-) Regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] i.spectral.py in WinGrass
You are right Glynn, I just checked i.spectral.py and it has the
d.linegraph feature but, i.spectral is greyed out in wxpython gui and,
when I try to run it from the command line (using Msys wingrass7svn),
if I input a raster group I get the error:
GRASS 7.0.svn> i.spectral.py group=alos.radiance coords=720560,261787
< foi inesperado neste momento.
Traceback (most recent call last):
File "c:/GRASS-70-SVN/scripts/i.spectral.py", line 236, in
main()
File "c:/GRASS-70-SVN/scripts/i.spectral.py", line 231, in main
draw_linegraph(what)
File "c:/GRASS-70-SVN/scripts/i.spectral.py", line 144, in draw_linegraph
for j, val in enumerate(what[0][3:]):
IndexError: list index out of range
GRASS 7.0.svn>
If I try to run it using the raster options I don't get any errors but
nothing is displayed to the screen.
Running from the command console in wxgui I get:
(Tue Dec 07 08:54:34 2010)
i.spectral.py raster=alos.6s.1,alos.6s.2,alos.6s.3,alos.6s.4
coords=720560,261787
Traceback (most recent call last):
File "C:\GRASS-70-SVN\scripts\i.spectral.py", line 74, in
from grass.script import core as grass
File
"C:\GRASS-70-SVN\etc\python\grass\script\__init__.py", line
1, in
from core import *
File "C:\GRASS-70-SVN\etc\python\grass\script\core.py",
line 31, in
import subprocess
File "C:\GRASS-70-SVN\Python25\lib\subprocess.py", line
376, in
import threading
File "C:\GRASS-70-SVN\Python25\lib\threading.py", line 13,
in
from collections import deque
ImportError: No module named collections
(Tue Dec 07 08:54:34 2010) Command finished (0 sec)
Traceback (most recent call last):
File
"C:\GRASS-70-SVN\etc\gui\wxpython\gui_modules\goutput.py",
line 738, in OnCmdDone
task = menuform.GUI().ParseCommand(event.cmd, show = None)
File
"C:\GRASS-70-SVN\etc\gui\wxpython\gui_modules\menuform.py",
line 2221, in ParseCommand
self.grass_task = self.ParseInterface(cmd)
File
"C:\GRASS-70-SVN\etc\gui\wxpython\gui_modules\menuform.py",
line 2192, in ParseInterface
tree = etree.fromstring(getInterfaceDescription(cmd[0]))
File
"C:\GRASS-70-SVN\Python25\lib\xml\etree\ElementTree.py",
line 964, in XML
return parser.close()
File
"C:\GRASS-70-SVN\Python25\lib\xml\etree\ElementTree.py",
line 1254, in close
self._parser.Parse("", 1) # end of data
xml.parsers.expat
.
ExpatError
:
no element found: line 1, column 0
It looks as though I don't have the collections module?
Thanks for all the help
Daniel
On Tue, Dec 7, 2010 at 3:13 AM, Glynn Clements wrote:
>
> Daniel Victoria wrote:
>
>> I'm using WinGrass 7.0svn from the daily build and I just realized
>> that i.spectral.py needs gnuplot.
>
> It shouldn't need gnuplot. It shouldn't even try to use gnuplot unless
> you use the -g flag. The default behaviour is to use d.linegraph.
>
> --
> Glynn Clements
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: v.in-out quirks
Hi Micha, yes, by all means, wiki away :-) I haven't yet educated myself on how to contribute to wikis and bugzillas and the likes, so if you want to take that task off my hands you're welcome :-) Somewhat pleased that my verbosity had some elements of usefulness therein! now, to spend a bit more time in GRASS and come up with my next 'victim'.. I reckon I can give v.digit and its friends a good workout! Regards, Shane. On Tue, 2010-12-07 at 12:03 +0200, Micha Silver wrote: > Shane Litherland wrote: > > > (my first-ever reply to the list...hope I get the cc / subject stuff > > right!) > > > Seems to be OK > > > (also FYI - GRASS 6.4.0RC, Ubuntu 10.04LTS (most of my sys/progs from > > synaptic package manager) > > AND a GARMIN GPS60) > > > > Micha - your suggestion much appreciated :-) I had used v.in.ascii a > > while back, had forgotten how versatile it could be! > > > > I used a slight adjustment to your suggestion - I still like having > > another copy of my gps data, so did it in the two steps rather than > > piping, i.e. gpsbabel (gebabbel GUI) to save a unicsv format file from > > the garmin handset, then the v.in.ascii (GRASS GUI) to get the unicsv > > format into grass. > > > > May I take take your suggestions to add to the GRASS wki? > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: v.in-out quirks
Shane Litherland wrote: (my first-ever reply to the list...hope I get the cc / subject stuff right!) Seems to be OK (also FYI - GRASS 6.4.0RC, Ubuntu 10.04LTS (most of my sys/progs from synaptic package manager) AND a GARMIN GPS60) Micha - your suggestion much appreciated :-) I had used v.in.ascii a while back, had forgotten how versatile it could be! I used a slight adjustment to your suggestion - I still like having another copy of my gps data, so did it in the two steps rather than piping, i.e. gpsbabel (gebabbel GUI) to save a unicsv format file from the garmin handset, then the v.in.ascii (GRASS GUI) to get the unicsv format into grass. May I take take your suggestions to add to the GRASS wki? -- Micha ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Landsat SLC-Off data usage
Agreed. You have to make sure you have valid training areas are for each image you want to classify. I've also found that dealing with clouds and their shadows is one of the biggest issues to consider when doing classifications. - Nick J On Sun, Dec 5, 2010 at 4:12 AM, Nikos Alexandris < nikos.alexand...@uranus.uni-freiburg.de> wrote: > Nick Jachowski: > > > I have been working a lot with SLC-Off imagery lately. Some people in my > > department have used the gap filling programs floating around the net, > but > > I'm not familiar with them personally. I've settled on using r.patch as > > well, although you have to be careful how you apply it. I found that > even > > if I used radiometrically corrected landsat images (using i.landsat.toar) > > from the same season often the patched parts of the image did not fit > > smoothly with the rest of the image (i.e. you could see striations where > > the gaps had been). > > Right. The same here. But I used the composites only for visual > interpretation > which was ok. It's always interesting how different tasks pose different > challenges. > > > I'm using the imagery for land classification, so > > I've found it works better if I do the classification on each landsat > > image separately and then patch them. Using this method you can't tell > > where the former gaps are, at least in my experience working with imagery > > from the dry season in southeast asia. > > Interesting. Yet, I guess, you had to use independent training areas (in > case > you performed supervised classifications), right? > > [...] > > Nikos A > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
