[GRASS-dev] OGR write access

Markus Metz markus.metz.giswork at googlemail.com
Fri Oct 16 04:46:11 EDT 2009


Martin Landa wrote:
> Hi,
>
> I am thinking how to implement direct write access to OGR datasources
> from the user point of view. One approach would be to implement global
> flag '--u' for updating existing vector map (i.e. OGR datasource).
> E.g.
>
> v.out.ogr input=test dsn=. type=point -n
> v.external dsn=. layer=test output=test
> v.random out=test n=1000 --u
>   
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.
> this could work also for native format
>
> v.edit map=test tool=create
> v.random out=test n=1000 --u
>
> Or to add new parameters 'dns/format' which would be used only for OGR
> format, not for the native one.
>   
> v.random out=test n=1000 format=ESRI_Shapefile dns=.
>   
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?

Alternatively, modules that create output could be modified to have two 
separate output options: outmap (can be OGR dns) and outlayer, analogous 
to specifying input with map and layer as already present in many 
modules. Format of outlayer could be <number>/"name", make it optional 
with default 1/<mapname>. OGR format (Shapefile, POSTGIS, etc) still 
needs to go to somewhere. Modify the new global format option to reflect 
either native or which OGR format to use? OGR would be triggered by 
virtual output mapset OGR?

As starting points, I think we need to (1) globally implement layer 
names, also for native vectors, and without the need to link an 
attribute table to that layer, (2) support updating attribute tables of 
v.external vectors. After that, direct writing of primitives/features 
could be implemented. Makes sense?

Markus M


More information about the grass-dev mailing list