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
