It seems that GV_FORMAT_OGR refers now to both OGR layers linked with
v.external and direct OGR access, but these two require different
handling. Add new GV_FORMAT_OGR_DIRECT ? See temporary workaround in [1].
Markus M
[1] https://trac.osgeo.org/grass/changeset/39545
Hi,
2009/10/17 Markus Metz markus.metz.gisw...@googlemail.com:
It seems that GV_FORMAT_OGR refers now to both OGR layers linked with
v.external and direct OGR access, but these two require different handling.
Add new GV_FORMAT_OGR_DIRECT ? See temporary workaround in [1].
I am not sure if
Martin Landa wrote:
Hi,
2009/10/17 Markus Metz markus.metz.gisw...@googlemail.com:
It seems that GV_FORMAT_OGR refers now to both OGR layers linked with
v.external and direct OGR access, but these two require different handling.
Add new GV_FORMAT_OGR_DIRECT ? See temporary workaround in
2009/10/17 Markus Metz markus.metz.gisw...@googlemail.com:
[...]
But probably GV_FORMAT_OGR_DIRECT would be better solution.
Also to avoid rewriting existing code that uses GV_FORMAT_OGR for v.external
linked vectors, see e.g. [1,2].
[1]
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
Hi,
2009/10/16 Markus Metz markus.metz.gisw...@googlemail.com:
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
Hi,
2009/10/16 Martin Landa landa.mar...@gmail.com:
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).
as the '--u' is global flag we
Martin Landa wrote:
Hi,
2009/10/16 Markus Metz markus.metz.gisw...@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
Hi,
2009/10/16 Markus Metz markus.metz.gisw...@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
Hi,
Martin:
Markus:
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
Hallo,
2009/10/16 Markus Metz markus.metz.gisw...@googlemail.com:
[...]
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
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
Hi,
2009/10/16 Martin Landa landa.mar...@gmail.com:
[...]
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.
see
http://trac.osgeo.org/grass/wiki/Grass7/VectorLib#DirectOGRreadaccess
for info about current
On Oct 15, 2009, at 3:40 AM, grass-dev-requ...@lists.osgeo.org wrote:
Date: Thu, 15 Oct 2009 11:09:11 +0200
From: Martin Landa landa.mar...@gmail.com
Subject: [GRASS-dev] OGR write access
To: GRASS developers list grass-dev@lists.osgeo.org
Message-ID:
Hi,
2009/10/15 Michael Barton michael.bar...@asu.edu:
[...]
Might this be worth considering integrating with the data catalog mentioned
yesterday?
http://lists.osgeo.org/pipermail/grass-gui/2009-October/000679.html
I see this as separate issue. First step to implemented it in the
GRASS
Fair enough. Better to do this one step at a time.
Michael
On Oct 15, 2009, at 8:58 AM, Martin Landa wrote:
Hi,
2009/10/15 Michael Barton michael.bar...@asu.edu:
[...]
Might this be worth considering integrating with the data catalog
mentioned
yesterday?
On Oct 15, 2009, at 11:36 AM, Martin Landa wrote:
Hi,
2009/10/15 Michael Barton michael.bar...@asu.edu:
Fair enough. Better to do this one step at a time.
sorry, I don't understand right now. Without direct OGR write support
in the GRASS libraries and the GRASS modules you can work on the
2009/10/15 Michael Barton michael.bar...@asu.edu:
Fair enough. Better to do this one step at a time.
sorry, I don't understand right now. Without direct OGR write support
in the GRASS libraries and the GRASS modules you can work on the GUI
integration. GRASS libraries and modules need to be
18 matches
Mail list logo
