[GRASS-dev] OGR write access

[Martin Landa]

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.

It's also not clear how to implement 'update' mode for other GIS
elements (raster map, ...).

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

Then we end up with the need to update manually every module which can
support update mode. Probably we could build a list of modules where
make sense to have update mode and not (having 'output' parameter).

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

Probably I don't understand, I can't see 'format' parameter only in
v.out.ogr, v.in.ogr and similar modules. Currently would be possible"

v.out.ogr input=test dsn=`pwd` type=point -n
v.external dsn=. layer=test output=test
v.random out=test n=1000 --u

but probably

v.random map=`pwd`@OGR n=1000 olayer=test format=ESRI_Shapefile

is better approach.

> new output option for output layer could make sense and AFAICT is required
> for direct OGR write access.

yes, also olayer would be required. But it would make sense only for
OGR format, not the native format, am I right?

v.extract in=imap layer=1 where="..." out="PG:dbname=db" olayer=omap
format=PostgreSQL
v.extract in=imap layer=1 where="..." out=omap format=native

> Maybe this is one step ahead, first fully implement direct OGR read access
> without the need for v.external?

yes, I am working on it.

>> and modifying
>> Vect_open_new() to pass format parameter, etc.
>>
>
> Yes, in principle similar to Vect_open_old(), needs new Vect_open_new_ogr().

Right.

Martin

-- 
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa