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