On 02/09/15 00:31, Vaclav Petras wrote:
Hi,
in the source code I stumbled on direct OGR access and realized that I
don't know what it is. I haven't found any documentation (now I think
there might be something on the wiki)
https://grasswiki.osgeo.org/wiki/Working_with_external_data_in_GRASS_7#Direct_access_to_external_data
https://trac.osgeo.org/grass/wiki/Grass7/VectorLib/OGRInterface
but at the end I remembered I've
seen it (probably lately for the GSoC idea) and figured out that you can
do the following:
# prepare data
v.random output=direct_ogr_test -z npoints=10
v.out.ogr input=direct_ogr_test output=direct_ogr_test.shp
# magic
v.info <http://v.info> direct_ogr_test.shp@OGR layer=direct_ogr_test
This is pretty cool. There are just some issue and my question is
weather I should create tickets for them.
1) You need to specify layer, in my case it was the same as filename
without suffix. This took my some time to find out. Perhaps natural for
GDAL/OGR, not so much for common users.
That's normal OGR procedure linked to the fact that OGR deals with so
many different data formats with different ways data are organised, but
it probably could be documented better. I think it is quite clear in the
v.in.ogr man page, but then again, v.in.ogr is more flexible as it
allows the shapefile name directly as data source, without layer info.
2) It gives strange errors when you use it for output.
# note @OGR in output
v.clean input=direct_ogr_test.shp@OGR output=direct_ogr_test_clean@OGR
tool=rmdac layer=direct_ogr_test
I would have thought that v.clean needs topological format (i.e. level 2
topology). Is direct OGR access able to provide such topology ?
# gives (which is not true):
ERROR: option <output>: <direct_ogr_test_clean> exists. To overwrite,
use the --overwrite flag
# note @OGR in output and --o
v.clean input=direct_ogr_test.shp@OGR output=direct_ogr_test_clean@OGR
tool=rmdac layer=direct_ogr_test --o
# gives:
ERROR: Output vector map name <direct_ogr_test_clean@OGR> is not in the
current mapset (manual)
Which is at least right but perhaps not 100% fitting the OGR case.
3) Is the above read-only limitation necessary? I suppose it is not
implemented but now the code is shared for reading with the
external/link driver for reading. The issue is of course writing to
different Mapset. I don't like to potential mess in code and increased
complexity in documentation and in writing checks (e.g. in GUI).
However, it would be nice to find a way our it.
You always have v.external.out as one solution, but I guess you mean you
would like to be able to do this flexibly in each module. IIUC, this
would mean that either
- @OGR has to be treated as a special case, and, 'OGR' forbidden as a
mapset name
- or that direct access should use a different syntax than '@OGR'.
I personally think that the v.out.external solution is enough.
Moritz
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
