On 3/2/12, Benjamin Ducke bendu...@fastmail.fm wrote:
I think I understand your error. You confuse feature id with category
value. The feature order in the output file depends on the feature
order of the GRASS input vector, and the feature order of the GRASS
input vector has absolutely nothing
I think it's rather the dblib than v.out.ogr. Recently I have fixed a
few memory leaks in dblib, but no optimizations. The dbf driver in
particular is terribly slow. An index like for real database backends
might help, although that would need to be created on the fly since
dbf does not
On Thu, Mar 1, 2012 at 8:16 PM, Benjamin Ducke bendu...@fastmail.fm wrote:
No, this is because the i-th feature does not need to have category i,
it can have any category and multiple categories. Selecting all
attributes at once for all categories is also not memory-safe for
larger vectors.
I think I understand your error. You confuse feature id with category
value. The feature order in the output file depends on the feature
order of the GRASS input vector, and the feature order of the GRASS
input vector has absolutely nothing to do with the category order.
There was a good
On Wed, Feb 29, 2012 at 8:23 AM, Benjamin Ducke bendu...@fastmail.fm wrote:
Dear Devs,
A while ago, I submitted a small patch for v.out.ogr
that moves the SQL SELECT out of the mk_att() function,
so that this costly operation does not have to be
performed multiple times:
No, this is because the i-th feature does not need to have category i,
it can have any category and multiple categories. Selecting all
attributes at once for all categories is also not memory-safe for
larger vectors.
Hmm, let's say we take the smallest and largest category values
in the
Dear Devs,
A while ago, I submitted a small patch for v.out.ogr
that moves the SQL SELECT out of the mk_att() function,
so that this costly operation does not have to be
performed multiple times:
http://lists.osgeo.org/pipermail/grass-dev/2011-January/053150.html
Looking at 6.4.2 and 6.5 SVN
