[GRASS-dev] v.outlier

[Maris Nartiss]

Hello Markus,
if You understand taht code - how complex (usefull) would be getting
rid of DB at all? I mean - is it possible to store temporary data into
some faster data structure (file?) and thus eliminate all DB
dependencies for this module?

Maris.

2009/11/23, Markus Metz <markus.metz.giswork at googlemail.com>:
> Please try trunk r39785.
>
> According to the comments in the code, the auxiliary table is used to
> store info about overlapping zones and is dropped at the end. The
> auxiliary table is always created and used, also when no output vector
> for display (QGIS output) is given.
>
> Markus M
>
>
> helena wrote:
>> 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
>>
>>
>>
>>
>> On Nov 21, 2009, at 11:27 AM, GRASS GIS wrote:
>>
>>> #96: v.surf.bspline column option broken
>>> -----------------------+----------------------------------------------------
>>>
>>>
>>> Reporter: cmbarton | Owner: grass-dev at lists.osgeo.org
>>> Type: defect | Status: reopened
>>> Priority: major | Milestone: 6.4.0
>>> Component: Raster | Version: unspecified
>>> Resolution: | Keywords: v.surf.bspline
>>> Platform: All | Cpu: All
>>> -----------------------+----------------------------------------------------
>>>
>>>
>>> Comment (by cmbarton):
>>>
>>> Forgot to give an example of the command I used--that did not work.
>>>
>>> Michael
>>>
>>> v.surf.bspline --overwrite input=elev_pts1000_sql at sqlite_test
>>> raster=aaa_splintest at sqlite_test sie=400 sin=400 layer=1
>>> column=elevation
>>>
>>> --
>>> Ticket URL: <http://trac.osgeo.org/grass/ticket/96#comment:13>
>>> GRASS GIS <http://grass.osgeo.org>
>>> _______________________________________________
>>> grass-dev mailing list
>>> grass-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>