[GRASS-dev] Speeding up v.out.ogr (again)
benducke at fastmail.fm
Fri Mar 2 16:48:22 EST 2012
> 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".
I thought so. Just didn't know what that reason was.
That's why I asked.
> 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.
I haven't touched anything, so there's nothing to revert.
Just wanted to discuss some thoughts on this list, that's all.
But I still think that something needs to be done
to speed up v.out.ogr.
> 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