[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