> 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 > > [email protected] > > http://lists.osgeo.org/mailman/listinfo/grass-dev > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
