[GRASS-dev] OGR write access

Markus Metz markus.metz.giswork at googlemail.com
Fri Oct 16 05:40:56 EDT 2009

Martin Landa wrote:
> Hi,
> 2009/10/16 Markus Metz <markus.metz.giswork at googlemail.com>:
>> Not sure if I understand right: updating an existing vector map, be it OGR
>> or native, works for some but not all modules. Some modules first copy all
>> or selected primitives from input to output, then modify output, then write
>> output support files. That could cause duplication of all primitives and a
>> bogus result for some modules like e.g. v.generalize, v.clean, v.select.
> I was speaking about empty vector maps. 
> Anyway '--u' could be useful
> also for non-empty vector maps. Then you could use e.g. v.select
> without need to patch maps. E.g.
> v.select ain=imap1 bin=imap2 out=omap12 ope=within
> v.select ain=imap3 bin=imap4 out=omap34 ope=contains
> v.patch in=omap12,omap34 out=map
> with '--u' flag.
> v.select ain=imap1 bin=imap2 out=omap12 ope=within
> v.select ain=imap3 bin=imap4 out=omap12 ope=contains --u
Sounds good! Then the module does not need to check if output is indeed 
empty when already existing. Still, I'm not so sure if --u makes sense 
for all modules.
> Of course you can get bogus (duplicate categories, etc.) with --u, it
> depends on the data you are working with. Generally '--u' should
> implement 'append' mode instead of just overwriting files. 
> Of course
> there are some modules which basically cannot support update mode.
Then rather implement --u as an option for some modules but not all and 
not make it global?
>> How about a slight modification of Radim's suggestion:
>> v.random out=./shapefiles/@OGR,layer=test,format=ESRI_Shapefile
>> or something similar so that the out option can easily be parsed?
> yes, anyway it requires adding 'format' modules to the all vector
> modules which have 'output' parameter defined 
Hmm, for direct OGR write access, you need to specify the format anyway 
somewhere? There is already 'format' added to all vector modules which 
have input defined, can't be too difficult. And as I mentioned before, I 
think a new output option for output layer could make sense and AFAICT 
is required for direct OGR write access.

Maybe this is one step ahead, first fully implement direct OGR read 
access without the need for v.external?
> and modifying
> Vect_open_new() to pass format parameter, etc.
Yes, in principle similar to Vect_open_old(), needs new Vect_open_new_ogr().

Markus M

More information about the grass-dev mailing list