[GRASS-dev] v.external, ogr direct access, topology and
pseudo-topology.... a bit confused
Markus Metz
markus.metz.giswork at googlemail.com
Mon Apr 19 08:01:33 EDT 2010
G. Allegri wrote:
> I open a new post on the argument because it's something more general
> that me and my collegues need to unsertstand.
> I've tried to make the point with the various vector structures and
> modes in grass7 and I admit to be a bit confused.
>
> - v.external is meant to read ogr data sources without the
> topoloigcal overhead.
By default, pseudo-topology and a spatial index is built for both v.external
and direct OGR access.
Questions:
> - what is meant by pseduo-topology?
>
Reduced topology: each boundary is attached to one area only, i.e.
smoothing, simplification, removing small areas etc. will not work properly
for adjacent areas or areas within areas.
> - does the 'b' option is referred to pseudo-topology creation? If
> I set it, I cannot see the map and the "zoom to selected map" gives me
> an empty error box...
>
... because the extends of a vector map are stored in topology, also in
pseudo-topology. If topology and thus the extends are not available, "zoom
to selected map" won't work. And yes, the 'b' option refers to
pseudo-topology.
>
> - direct read/write access creates the same topo structure as native
> access, but it builds it each time I open the data source. Am I wrong?
> Is it too simplicistic my understanding?
>
No, it also builds pseudo-topology, not native full topology, this is only
available for native GRASS vectors. Full, correct topology can only be built
after all polygons are cleaned as done by v.in.ogr.
>
> My first concern is about the use of simple features in the grass
> environment, and tha ability to write SF algorithms
Can you give examples for such SF algorithms/operators? It's not clear to me
what you have in mind.
> that don't require
> topology to be built. This is a requirement in daily work, mostly when
> we deal with unclean polygonal data but the topology is not required
> (ie simple feature operators, etc.).
>
GRASS is rather strict about polygonal data. Working with unclean polygonal
data will produce unclean results which is not desired IMHO.
It seems to me that you are missing some functionality in GRASS, so it would
be great if you could give some examples about what is missing.
Markus M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20100419/4c1811ed/attachment.html
More information about the grass-dev
mailing list