Dear all,
I have just reviewed v.out.ogr and where it spends those
massive amounts of time it needs to export larger vector maps.
Turns out that it issues a new SQL SELECT statement for every
single attribute it wants to export.
So I rearranged the code to use only one SQL SELECT statement that
fetches all records at once (same as what v.db.select does).
Essentially, I moved the SQL SELECT out of mk_atts() and into the
calling function, where it is now executed only once.
After that fix, I was able to export a vector map with 220.000 points
within 10 secs, instead of originally ca. 100 mins. Go figure out the
speed-up factor, it's ridulous! Granted, my data has a very simple
attribute table and for more complex table structures, the factor
may be smaller (v.out.ogr re-examines the field types for every
record, so there is still some room for optimization).
Question is: what to do with this? I would like to have it in
6.4.1 and believe that the change is actually very small, but
I understand that v.out.ogr is a very critical modules and so
every change in there needs to well-tested.
I have some resources for working on GRASS contributions next week,
but I need to plan them well. So if there is a realistic chance that
this can go into 6.4.1, I will do some in-depth testing next week
to make sure all works well.
If not, I can check this into 6.5 and then we give it enough time
to mature for 6.4.2.
Also: I am getting really annoyed by having to supply those OGR
"lco=" (or was it "dsco="? See, that's what I mean...)
options for creating 3D Shapefiles. How about, similar
to "-e" I add another flag "-z" which automatically creates 3D
output in case the input is a 3D GRASS map and the output are
Shapefiles? It wouldn't change anything about the default behaviour.
Cheers,
Ben
------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.