[GRASS-dev] v.outlier

[Michael Barton]

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 at lists.osgeo.org wrote:

> Date: Sun, 22 Nov 2009 00:46:33 -0500
> From: helena <hmitaso at unity.ncsu.edu>
> Subject: [GRASS-dev] v.outlier
> To: grass-dev at lists.osgeo.org
> Message-ID: <E9713002-D5F7-45B9-8ED9-A8AA947442A6 at 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 at 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 at 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
>