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

[Benjamin Ducke]

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

Best,

Ben

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