Martin Landa wrote:
Hi,
direct OGR read access is implemented in the most of vector modules
[1]. You can access OGR layer directly (i.e. without linking it via
v.external) using 'map' and 'layer' parameters, e.g.
v.extract input=PG:dbname=nc_spm_08@OGR layer=busstopsall
where="STREET_1 = 'William Moore Dr.'" output=b1
Currently I started working on write OGR support. 'output' parameter
can be used for OGR datasource name, anyway parameter for OGR layer is
not available. It would require to add new parameter 'olayer' to the
most of vector modules. For native format it would be optional
parameter which defines layer name. In the case of OGR layers it would
specify OGR layer name, e.g.
v.extract map=obce where="NAZEV = Solany" output=PG:dbname=gisdb@OGR olayer=obce
What do you think about that?
Direct OGR support is surely a user-friendly feature in the sense that vectors do not need to be imported with v.in.ogr. OTOH, all that topological cleaning done by v.in.ogr is there for a reason and the risk of getting corrupted results when using a direct OGR link as input for modules is quite high.
The whole direct OGR access only makes sense if attribute table operations are working which is not the case lest you create a special test vector with a valid key column. IMHO, that needs to be fixed first before direct OGR read/write access is enabled.
In three quick tests, neither v.extract nor v.clean nor v.what produce correct results. v.extract fails with "ERROR: Unable select records from table <OGR_test>". The output of v.clean has a corrupted dblink, "Error in rule on row 1". v.what from the wxGUI fails because layer -1 is not available (easy to fix I guess: if (field = -1 && !strcmp(mapset, "OGR") field = 1;).
The recent changes in lib/vector/Vlib/write.c, write_nat.c and write_ogr.c make things more complicated than needed, the structural design of writing/deleting primitives can be simplified. It does not make a lot of sense to me to
- first call a generic function like Vect_write_line()
- which calls format-specific V2_write_line_nat or V2_write_line_ogr()
- both are a wrapper for the new generic (format-independent) function V2__write_line
- which calls format-specific V1_write_line_[nat|ogr]
Vect_write_line() can call V2__write_line() directly when modifying *Vect_write_line_array[3], thus Vect_write_line() -> V2__write_line() -> V1_write_line_[nat|ogr] or for level 1 Vect_write_line() -> V1_write_line_[nat|ogr].
The vector libs are complicated enough as they are, I would try to avoid making them more opaque and first see if they can be made a bit more transparent and easier to read.
I can't see a way to have direct OGR write access for areas without writing a temporary grass vector first, then export it v.out.ogr-like to one or more OGR layers because grass writes each boundary separately while for OGR, a polygon needs to be constructed from all boundaries and isles constituting it first before writing it out. Currently, a boundary would be written as wkbLineString, i.e. boundaries are converted to lines and area attributes get lost. This can only be corrected by rewriting all vector modules that may write boundaries, for some that process one boundary at a time, this may not be possible at all. Therefore I would opt against direct OGR write access.
I'm afraid that the vector code, both libs and modules, will become much more complicated if direct OGR write access is fully implemented. That means more potential for bugs and more work to detect and remove bugs. There are not that many active developers fixing bugs in the grass vector libs; making the code base even more complicated is frightening off others.
IMHO, the disadvantages and problems associated with direct OGR access outweigh the advantages, but I am ready to be convinced 
Maybe it makes sense to get v.external fully functional before doing any more work on direct OGR access?
Not a very positive feedback I'm afraid, tainted by my preference for grass vector format over other OGR vector formats and experience with dirty non-topological OGR vectors.
Markus M