Martin:
Markus:
[...]
yes, also olayer would be required. But it would make sense only for
OGR format, not the native format, am I right?
Thinking about it, there may be problems because some modules may produce
several output layers in the same output vector map if feature cats refer to
several layers. No idea how to accommodate that with direct OGR write access
where each OGR layer needs its own name not number. Fetch layer name from
input vector, append layer number to map name if no layer name available?
I would suggest to use multiple 'olayer' parameter. If number of
produced layers would differ from the number of 'olayers', the module
ends up with an error and nothing is written to OGR datasource (?)
But make olayer optional, if not given, come up with reasonable names
based on input layer names/output map name?
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
Should work, but preferably use input layer name if available?
Yes, if vector layer is defined - currently there are few modules
which write out layer name.
Can be changed.
I would suggest to modify all vector
modules to write layer name identical with input vector map name (if
more layers produced, then input_1, input_2). Do you agree with it?
Not feeling too strongly about it, could also be output_1 etc. But
v.support should definitively allow specifying/changing layer names for
native format if the user is not happy with the default names. Changing
layer names for OGR layers can be more difficult or impossible,
depending on the format (nothing to change for e.g. GPX I think).
Coming back to the original idea of direct OGR write access, I think
this would be great!
I see however a number of issues that need to be solved before getting
to there: I can neither query nor update attributes of a shapefile
linked in with v.external, it must be possible to specify layers by
number or name for native vector maps, vector map layers linked with
v.external and direct OGR access, direct OGR access can be triggered
with virtual mapset OGR or new option Format (what are the
(dis)advantages of this approach and your approach with option Format?)
but for direct OGR write access an additional option 'format' or similar
is needed specifying one of the locally supported OGR formats. I'm not
an expert on OGR API, but updating an existing OGR layer may not be that
easy? IMO minor issues are how to specify OGR dsn, OGR layer(s), and OGR
supported format (for write access) in vector modules.
Markus M
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
