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

GRASS GIS GRASS GIS developer
,
1

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) 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 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.

  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

gives (which is not true):

ERROR: option : <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.

  1. 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.

  2. I haven’t tried GUI much but v.clean went through. Unfortunately, you cannot browse the file as a user. I guess this is a feature worth putting there. Some ideas on that would be good. Or is there a reason for not having it there?

  3. I guess some documentation is needed. Perhaps even a separate page. Maybe we can try to replace text in manual “direct OGR access” in modules’ pages by a link to that page when building the pages.

  4. The name OGR might not be really the right thing anymore since OGR merged more under GDAL if I’m following the website properly. We should consider this before writing the documentation or putting it to GUI.

Thanks,

Vaclav

2

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