On Thu, Mar 1, 2012 at 8:16 PM, Benjamin Ducke <[email protected]> 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. 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
