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

Markus Metz markus.metz.giswork at googlemail.com
Sat Mar 3 09:03:00 EST 2012


On 3/2/12, Benjamin Ducke <benducke at fastmail.fm> wrote:
>> 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.

OK. Apparently I misinterpreted the subject of the post (slow internet
connection while doing field work, did not check changes to
v.out.ogr).
>
> But I still think that something needs to be done
> to speed up v.out.ogr.

I think it's rather the dblib than v.out.ogr. Recently I have fixed a
few memory leaks in dblib, but no optimizations. The dbf driver in
particular is terribly slow. An index like for real database backends
might help, although that would need to be created on the fly since
dbf does not support indexes. Nevertheless, I noticed that a lot can
be done on module level. The new v.out.ply addon for example is based
on v.out.ascii, and v.out.ply with attribute export is magnitudes
faster than v.out.ascii with attribute export.

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


More information about the grass-dev mailing list