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

[Benjamin Ducke]

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

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