[GRASS-dev] Speeding up v.out.ogr (again)

Markus Metz markus.metz.giswork at googlemail.com
Fri Mar 2 14:15:42 EST 2012

On Thu, Mar 1, 2012 at 8:16 PM, Benjamin Ducke <benducke at 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.
> Hmm, let's say we take the smallest and largest category values
> in the map to export, then chop up the range of values into
> reasonably sized chunks let's say max. 1000 features, and select
> a chunk at a time. Shouldn't that make sure that we get all
> features and also have a guaranteed maximum memory footprint?
> If the category values in the GRASS map are not strictly
> increasing, then the feature order will be changed in the
> output file. However, I am not sure whether this would be
> a problem, given that the feature<->attribute links stay
> intact?
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 reason why I wrote "the cursor really needs to be
opened for each cat separately".

You have again introduced a serious bug (the same one for the second
time) in one of the main GRASS modules. Please revert this change
immediately or I have to revert this change, again.


Markus M

>> >
>> > If so, then I suggest putting in a condition, so that those
>> > GRASS maps that have just one attribute table can perform
>> > the SQL SELECT outside of mk_att(). Otherwise, we punish
>> > all GRASS users with extremely slow export speed, even though
>> > most of them might not even use multi-table attributes in
>> > their projects. The difference in my test was something like
>> > factor 500!
>> Please test if attribute assignment is preserved and attributes are
>> not randomly swapped. A stream vector created with r.stream.extract
>> would be a good test case.
> Will do.
> Ben
>> Markus M
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

More information about the grass-dev mailing list