[GRASS-dev] OGR write support in GRASS 7

[Markus Metz]

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 at 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 at 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