Michael wrote: > I actually get the same thing. > For the first while the process runs in full use > of one core, but once the process starts writing results to > the db, the whole process bogs down to a > grinding halt. CPU usage for v.lidar.edgedetection > drops down to ~1% (1% of one core) and sqlite usage rises to > ~16%. Maybe I'm wrong, but my impression was that the > bottle neck was the modifications to the database.
hmmm. I've seen no problems on Linux64 + DBF backend. 100% core until completion. Are you running WinXP + SQlite? Can you try with the DBF driver? maybe the common problem is in the SQLite driver... ?? if you build from the latest grass 6.5 or 7 svn you can use the --verbose flag to follow the action. setting 'g.gisenv set="DEBUG=1" gives you even more detail (even with existing versions). John wrote: > Also, when I have tried to run v.oultier without db/topology > it says it cannot as there is no database. you can have a database without topology. > I will look at this again later. Maybe I am not selecting 3D when > I have tried without db etc. it needs that. Mike: > Note that there is a bug in v.outlier. v.outlier > creates a temporary table by the name of outfilename_aux (LN > #137 /lidar/v.outlier/main.c) but elsewhere in the code it > is hardwired to Auxiliar_outlier_table (LN's # 239 > & 258 /lidar/v.outlier/outlier.c) , so when it > actually tries to write to the table it complains and fails. > You can get around it by manually creating this table using; > db.copy from_table=outfilename_aux > to_table=Auxiliar_outlier_table > I'm not sure why, but it looks like the > system doesn't always need to use the Auxiliar_outlier_table, and > when it doesn't, it continues on merrily without > complaint. Unfortunately, when it does require the table, on my system > the program continues on only to segmentation fault further > down the line (at least it does on my system). Maybe > it's because of the changes that I made to the code to > correct the above error, but I can't see why that would > be true. I was planning on looking further into it, but > haven't had the time to start debugging. In the mean > time I've added the files with my changes to the code > for the developers. I'm a hack, so the changes are > probably in poor coding practice. Someone > more savvy that I will need to clean it .... > PS. IF I find what I think are errors or > possible improvements to the code, what is the most > appropriate place and method to submit them? please create your patches with "svn diff > somepatch.diff" and file them in the trac system. Otherwise they quickly get lost and forgotten. http://grass.osgeo.org/bugtracking/ https://trac.osgeo.org/grass/wiki/WikiStart#BugTracking cheers, Hamish _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user