On Tuesday 12 Nov 2013 20:37:24 you wrote: > >> I know that it can be annoying to have to create new maps, but at > >> the same time it is a failsafe that makes sure that even if you > >> make a mistake in the call to v.category, you still keep your > >> original data. > > > > yes, it is particularly annoying, because the GRASS db driver is > > pretty slow copying data from one table to another. Maybe we > > should > > add a flag that skip to copy the attribute tables. > > That could be an option, yes.
Ok, done in r58202 > > On the other hand, the tables are already there, we need only to > > link the geometry features to the existing table. > > No, if we have a new map it should use a different attribute table > than the old map. I don't agree I prefer to avoid to have several copy of the same thing on my hard-disk, but I can understand your logic. :-) > > Anyone against this new flag/option? > > I'm not against the flag as it seems a reasonable option to me, but > I think that the performance issue should be solved as well. From > what I see in the code, I have the feeling that v.category might be > bitten by the same "bug"/problem as the one Hamish just reported > for v.what.rast [1], so possibly it is feasible to improve the > performance. Yes, I think that we have a huge problem in the DB drivers, but I don't have time right now to understand where the problem is. In general I try to avoid to use the C API of the DB as much as possible, using directly the python API. I think that the Attribute table, could gain in usability too if avoid to use v.db.select, and start to use directly the python API... and I think should avoid to load the whole table and load only the first 250 rows [0]. Best regards Pietro [0] http://trac.osgeo.org/grass/ticket/2124 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev