[GRASS-dev] Direct OGR access requires layer and is unclear about read only

[Moritz Lennert]

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 at 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 at OGR output=direct_ogr_test_clean at 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 at OGR output=direct_ogr_test_clean at OGR
> tool=rmdac layer=direct_ogr_test --o
>
> # gives:
> ERROR: Output vector map name <direct_ogr_test_clean at 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