[GRASS-dev] v.outlier

Markus Metz markus.metz.giswork at googlemail.com
Mon Nov 23 05:17:46 EST 2009


Hi Maris,

sorry, I don't really understand the purpose of that auxiliary table in 
P_outlier() in outlier.c. It is possible that all code referring to that 
table can be safely removed, but that needs some more testing. If the 
table is indeed used and not getting too large, it could be replaced 
with another faster data structure kept in memory. If the table is 
getting large, it could be difficult to come up with something 
file-based that's faster than a database. Anyway, it looks like the 
LiDAR tools could do with some maintenance.

Markus M


Maris Nartiss wrote:
> 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
>>
>>     
>
>   


More information about the grass-dev mailing list