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 <[email protected]>:
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_outlierf...@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_outli...@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: [email protected]
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_...@sqlite_test
raster=aaa_splint...@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
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
