[GRASS-dev] modifying the dblink it require to re-build the topology

Moritz Lennert mlennert at club.worldonline.be
Tue Nov 12 11:37:24 PST 2013


On 09/11/13 17:23, Pietro Zambelli wrote:
> On Thursday 07 Nov 2013 09:25:21 you wrote:
>>> I'm doing something wrong or is it a bug?
>>
>> I thought that maybe you forgot to use the type parameter, but I
>> just tried in the NC dataset and can confirm your issue.
>
> ok, the bug should be fixed in r58179, at the end it was much easier
> than I thought.
>
> Please test the v.category module, to be sure that I've not introduced
> new bugs. :-)
>
>
>> 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.

>
> 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.

>
> 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.

Moritz

[1] https://trac.osgeo.org/grass/ticket/2131


More information about the grass-dev mailing list