[GRASS-dev] about simple feature/ogr direct processing

GRASS GRASS developer
1

Hello,
it's a long time I'm away from Grass, because of various reasons. Some
days ago I've decided to come back to have a look to Grass7, and my
first thought/wish was: it would be great to have direct simple
features processing supported, along the native structures... and
that's what Martin Landa has done! :slight_smile: Great, exactly what I was
hoping!

I admit that this news has raised new interest in me, and some
collegues of mine. I've given a look at the code, to see what is
needed to make the v.* commands support direct ogr, but I haven't been
able to highlight where the "magics" is done... Martin, or others,
could you indicate me an example?

thanks,
giovanni

2

On Tue, Apr 6, 2010 at 4:01 PM, G. Allegri <giohappy@gmail.com> wrote:

Hello,
it's a long time I'm away from Grass, because of various reasons. Some
days ago I've decided to come back to have a look to Grass7, and my
first thought/wish was: it would be great to have direct simple
features processing supported, along the native structures... and
that's what Martin Landa has done! :slight_smile: Great, exactly what I was
hoping!

welcome back :slight_smile:

I admit that this news has raised new interest in me, and some
collegues of mine. I've given a look at the code, to see what is
needed to make the v.* commands support direct ogr, but I haven't been
able to highlight where the "magics" is done... Martin, or others,
could you indicate me an example?

cd vector
grep -l 'OGR support' */* | sed 's+/main.c++g' | tr '\n' ',' | sed
's+,+, +g' | fmt
v.buffer, v.category, v.class, v.clean, v.db.select, v.distance, v.drape,
v.extrude, v.generalize, v.hull, v.kcv, v.neighbors, v.normal, v.out.dxf,
v.out.pov, v.out.svg, v.overlay, v.parallel, v.qcount, v.random,
v.reclass, v.sample, v.segment, v.split, v.surf.idw, v.to.points,
v.to.rast3, v.to.rast, v.transform, v.type, v.univar, v.what,

Martin can certainly say more about it the current state.

cheers
Markus

3

Hi,

2010/4/6 G. Allegri <giohappy@gmail.com>:

I admit that this news has raised new interest in me, and some
collegues of mine. I've given a look at the code, to see what is
needed to make the v.* commands support direct ogr, but I haven't been
able to highlight where the "magics" is done... Martin, or others,
could you indicate me an example?

see [1] for details about implementation issues. I hope it helps.
Direct read OGR access is completely untested, any kind of
contribution is welcomed.

Martin

[1] http://trac.osgeo.org/grass/wiki/Grass7/VectorLib/OGRInterface

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

4

Ok, I see in http://trac.osgeo.org/grass/changeset/39161. The core
work is done in open.c depending on the @Mapset name. If it's 'ogr'
the vectors are opened as direct ogr, and level 1 (without topoloy).
So also polygons can be opened as level 1?

giovanni

2010/4/6 Martin Landa <landa.martin@gmail.com>:

Hi,

2010/4/6 G. Allegri <giohappy@gmail.com>:

I admit that this news has raised new interest in me, and some
collegues of mine. I've given a look at the code, to see what is
needed to make the v.* commands support direct ogr, but I haven't been
able to highlight where the "magics" is done... Martin, or others,
could you indicate me an example?

see [1] for details about implementation issues. I hope it helps.
Direct read OGR access is completely untested, any kind of
contribution is welcomed.

Martin

[1] http://trac.osgeo.org/grass/wiki/Grass7/VectorLib/OGRInterface

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

5

Hi,

2010/4/6 G. Allegri <giohappy@gmail.com>:

Ok, I see in http://trac.osgeo.org/grass/changeset/39161. The core
work is done in open.c depending on the @Mapset name. If it's 'ogr'
the vectors are opened as direct ogr, and level 1 (without topoloy).
So also polygons can be opened as level 1?

direct read access means that topology is build when OGR datasource is
open. You can avoid build-topo-on-open when you link OGR layer via
v.external, then topology is saved in topo file (which can cause
problems when original data is modified and 'topo' file remains
out-dated).

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

6

[back to ML]

Hi,

2010/4/6 G. Allegri <giohappy@gmail.com>:

So it's not meant to be used for ogc simple featurer processing (like
in qgis or saga). The topo build step is required for processing. I
thought it was an option to permit the development/use of
not-topological algorithms...

it's question for discussion, currently no SF processing implemented
in GRASS AFAIK.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

7

Citing from http://download.osgeo.org/grass/grass7_progman/vectorlib.html#vlibTopoManagement

"Topology is written for native format while pseudo-topology is
written for OGR sources, SHAPE-link."

Please, forgive me, but I would like to clarify some points more.

1 - v.external links to data without topology buing built. At the
moment it's only useful for visualizing (but could it be used for SF
algorithms?)
2 - OGR data sources use "pseudo-topology". Does this refer to the
read/write directly accessed sources? Or is it general? What is the
main difference between pseudo- and real- topology?

thanks again,
giovanni

2010/4/6 Martin Landa <landa.martin@gmail.com>:

[back to ML]

Hi,

2010/4/6 G. Allegri <giohappy@gmail.com>:

So it's not meant to be used for ogc simple featurer processing (like
in qgis or saga). The topo build step is required for processing. I
thought it was an option to permit the development/use of
not-topological algorithms...

it's question for discussion, currently no SF processing implemented
in GRASS AFAIK.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

8

Update, v.external uses pseudo-topology, while OGR direct access uses
true topology... mmm, so I think that the v.external way could be the
right one to develop SF algorithms....

giovanni

1 - v.external links to data without topology buing built. At the
moment it's only useful for visualizing (but could it be used for SF
algorithms?)
2 - OGR data sources use "pseudo-topology". Does this refer to the
read/write directly accessed sources? Or is it general? What is the
main difference between pseudo- and real- topology?

thanks again,
giovanni

2010/4/6 Martin Landa <landa.martin@gmail.com>:

[back to ML]

Hi,

2010/4/6 G. Allegri <giohappy@gmail.com>:

So it's not meant to be used for ogc simple featurer processing (like
in qgis or saga). The topo build step is required for processing. I
thought it was an option to permit the development/use of
not-topological algorithms...

it's question for discussion, currently no SF processing implemented
in GRASS AFAIK.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev