[GRASS-dev] v.outlier

GRASS GRASS developer
,
1

I agree about getting them to work.

In v.surf.bspline, the attribute option does not work at all--by design--with the dbf driver. I have no idea why, since v.surf.rst works just fine with dbf columns.

However, it doesn't work with the sqlite driver either.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Nov 22, 2009, at 10:00 AM, grass-dev-request@lists.osgeo.org wrote:

Date: Sun, 22 Nov 2009 00:46:33 -0500
From: helena <hmitaso@unity.ncsu.edu>
Subject: [GRASS-dev] v.outlier
To: grass-dev@lists.osgeo.org
Message-ID: <E9713002-D5F7-45B9-8ED9-A8AA947442A6@unity.ncsu.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

this is an issue that may be related to the v.surf.bspline #96 bug.
When running v.outlier on 3D vector file with topology built but no
DBF table
we get the following error:

v.outlier input=JR2007 output=JR2007_outlierfree
outlier=JR2007_outliers thres_o=30
DBMI-DBF driver error:
Table 'Auxiliar_outlier_table' doesn't exist.
Error in db_execute_immediate()

ERROR: Impossible to write in the database

The output files are actually written but when trying to display them
we get
GRASS 6.4.0RC5 (nc_spm_08):~/tgrassdata > d.vect JR2007_outlierfree
siz=1 co=red
WARNING: Coor files of vector map <JR2007_outlierfree@helena> is larger
         than it should be (94411739 bytes excess)
WARNING: Unable to display areas, topology not available
Segmentation fault
GRASS 6.4.0RC5 (nc_spm_08):~/tgrassdata > d.vect JR2007_outliers siz=1
co=red
WARNING: Coor files of vector map <JR2007_outliers@helena> is larger
than
         it should be (839 bytes excess)
WARNING: Unable to display areas, topology not available

Looking at the manual it seems that the table is needed only for QGIS
output where
the elevation is stored as category. So I am wondering whether this
is a bug
that needs to be fixed or whether the v.* lidar modules require points
with elevation stored in DBF (which is a problem for large datasets) -
if that is
the case it should be probably mentioned in the man page.

These modules would be really useful if we could get them to work,

Helena