[GRASS-dev] v.external, ogr direct access, topology and pseudo-topology.... a bit confused

GRASS GRASS developer
1

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. Questions:
    - what is meant by pseduo-topology?
    - 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...

- 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?

My first concern is about the use of simple features in the grass
environment, and tha ability to write SF algorithms 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.).
Maybe this could be based on the v.external approach...

Could you help us to clarify ideas?
thanks a lot,
giovanni

2

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

3

Hi Markus,
thanks for the clarifying reply.
For SF algorithms I mean those that can apply to SF structures, as meant by the OGC definition. For example a simple clip based on the SF spatial operators (like those in v.select in GRASS 7).
It’s not uncommon to need these operations rapidly, even on unclean data (at least, this happens frequently between my collegues and practioners). Much strict correctness is often not required, for daily work…

But from your explanation I understand that with pseudo-topology Grass can digest unclean polygons too… so I suppose that these kind of operations (like a clip) can be rapidly made through direct OGR read access. Even with v.external? (I have to verify, because I don’t have GRASS 7 right now on this pc).

giovanni

[1] OpenGIS® Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture, Chapter 6 http://portal.opengeospatial.org/files/?artifact_id=18242

2010/4/19 Markus Metz <markus.metz.giswork@googlemail.com>

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

4

G. Allegri wrote:

Hi Markus,
thanks for the clarifying reply.
For SF algorithms I mean those that can apply to SF structures, as meant by the OGC definition. For example a simple clip based on the SF spatial operators (like those in v.select in GRASS 7).

v.select requires a spatial index which in turn requires (at least some basic information stored in) topology. Doing the same operation without a spatial index would be much slower. BTW, v.select should be faster in GRASS 7 than in GRASS 6.x, particularly for larger vectors, because the spatial index is handled differently in GRASS 7. The same applies for v.what (simple vector querying). For direct OGR access however, topology is always built anew on the fly, whenever that OGR vector is accessed which can take some time for larger vectors.

Enabling v.select to work without topology would 1) require a near complete rewrite of the module and 2) make clips slower, at least for native GRASS vectors.

It’s not uncommon to need these operations rapidly, even on unclean data (at least, this happens frequently between my collegues and practioners).

These operations should be quite fast for native vectors with topology.

But from your explanation I understand that with pseudo-topology Grass can digest unclean polygons too… so I suppose that these kind of operations (like a clip) can be rapidly made through direct OGR read access.

Yes, although not that rapidly because pseudo-topology needs to be built first. Polygons do not need to be clean, but then nobody can guarantee for the results.

Even with v.external?

Yes.

Markus M

2010/4/19 Markus Metz>

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

5

2010/4/19 Markus Metz <markus.metz.giswork@googlemail.com>

G. Allegri wrote:

Hi Markus,
thanks for the clarifying reply.
For SF algorithms I mean those that can apply to SF structures, as meant by the OGC definition. For example a simple clip based on the SF spatial operators (like those in v.select in GRASS 7).

v.select requires a spatial index which in turn requires (at least some basic information stored in) topology. Doing the same >operation without a spatial index would be much slower. BTW, v.select should be faster in GRASS 7 than in GRASS 6.x, >particularly for larger vectors, because the spatial index is handled differently in GRASS 7. The same applies for v.what (simple >vector querying).

ok, this is how grass works, but spatial index isn’t strictly associated to topology. Many other gis systems use indexes but don’t require topology info.

For direct OGR access however, topology is always built anew on the fly, whenever that OGR vector is accessed which can take >some time for larger vectors.

you mean pseudo-topology. I’m sorry, but I need to be clear, otherwise I make some confusion :slight_smile:

Enabling v.select to work without topology would 1) require a near complete rewrite of the module and 2) make clips slower, at least for native GRASS vectors.

No problem, this is not what I expect. I just expect a user to be able to import a polygonal layer, without worrying about topology correctness (clean/build operations), and do spatial operations on it. Obviously the correctness of results depend on the operation the user is doing (and it’s his problem) but, i.e. a geometrical clip will be always correct, I think…

These operations should be quite fast for native vectors with topology.

With “rapidly” I meant: load data, do-the-op, save the results. I’m sure that the native grass data structures can deal more efficiently then SF structures… but often a user prefer to wait a minute more for the operation to end, then working a minute to have to manage the data cleaness (more often it takes much more then a minute, and it doesn’t worth it!)

Yes, although not that rapidly because pseudo-topology needs to be built first. Polygons do not need to be clean, but then nobody can guarantee for the results.

Ok, but the user just have to wait and wath the progress bar completing… that’s ok from his perspective :slight_smile:

Even with v.external?

Yes.

Ok, so v.external could be ok too.

giovanni

Markus M

2010/4/19 Markus Metz>

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

6

G. Allegri wrote:

Markus Metz:

v.select requires a spatial index which in turn requires (at least some basic information stored in) topology. Doing the same >operation without a spatial index would be much slower. BTW, v.select should be faster in GRASS 7 than in GRASS 6.x, >particularly for larger vectors, because the spatial index is handled differently in GRASS 7. The same applies for v.what (simple >vector querying).

ok, this is how grass works, but spatial index isn’t strictly associated to topology. Many other gis systems use indexes but don’t require topology info.

GRASS works like this for historical reasons, in GRASS 6.x the spatial index is always built on the fly from topology, and because the spatial index also holds features only available with topology (nodes, areas and isles of native GRASS vectors). Technically it’s possible to change that in GRASS 7 and build a spatial index but no topology.

For direct OGR access however, topology is always built anew on the fly, whenever that OGR vector is accessed which can take >some time for larger vectors.

you mean pseudo-topology. I’m sorry, but I need to be clear, otherwise I make some confusion :slight_smile:

Right, I meant pseudo-topology.

[…] I just expect a user to be able to import a polygonal layer, without worrying about topology correctness (clean/build operations), and do spatial operations on it.

Spatial operations without a preceding topology build are currently not possible in GRASS. It would be quite a lot of work to change that if possible at all. Note that topology must not necessarily be correct, but for most operations in GRASS it must exist. I don’t see such a huge drawback in building topology for OGR vectors, but then admittedly I usually import and clean them before I work with them.

These operations should be quite fast for native vectors with topology.

With “rapidly” I meant: load data, do-the-op, save the results. I’m sure that the native grass data structures can deal more efficiently then SF structures… but often a user prefer to wait a minute more for the operation to end, then working a minute to have to manage the data cleaness (more often it takes much more then a minute, and it doesn’t worth it!)

Cleaning is optional although highly recommended :wink: Contrary to some other topological vector formats, GRASS vectors must not be 100% clean and correct and most modules can tolerate somewhat corrupted topology. IOW, you could e.g. clip an OGR vector (linked in with v.external or direct OGR access) and directly export the result without cleaning, sometimes it might work, sometimes not.

OGR support in GRASS 7 is work in progress, I’m sure it will improve in the near future.

Markus M

2010/4/19 Markus Metz>

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

7

Jumping into the debate, since it raises some fundamental questions in my eyes;

On 19/04/10 17:46, G. Allegri wrote:

No problem, this is not what I expect. I just expect a user to be able
to import a polygonal layer, without worrying about topology correctness
(clean/build operations), and do spatial operations on it. Obviously the
correctness of results depend on the operation the user is doing (and
it's his problem) but, i.e. a geometrical clip will be always correct, I
think...

The questions here for me are:

- What is the actual error linked to doing operations on non-topological formats ?

- Why do you absolutely want GRASS to do this ? If all you want to do is simple geometry operations on spaghetti files, you can easily do this with most of the available open source viewers / GIS, such as QGIS, gvSIG, uDIG, etc or even directly with ogr. Why go through the trouble of using GRASS for that ?

These operations should be quite fast for native vectors with topology.

With "rapidly" I meant: load data, do-the-op, save the results. I'm sure
that the native grass data structures can deal more efficiently then SF
structures.... but often a user prefer to wait a minute more for the
operation to end, then working a minute to have to manage the data
cleaness (more often it takes much more then a minute, and it doesn't
worth it!)

> Yes, although not that rapidly because pseudo-topology needs to be
built first. Polygons do not need to be clean, but then nobody can
guarantee for the results.

Ok, but the user just have to wait and wath the progress bar
completing... that's ok from his perspective :slight_smile:

I find it a bit suspicious when user comfort is apparently put so much higher in priority then correctness of results...

Moritz

8

The language doesn’t help, so please forgive me if I haven’t been clear: I don’t expect from grass something more or something less, I was wondering if with the new grass 7 features (like direct ogr access) it was possible to make some daily operations faster.

I frequently use SAGA for spatial processing, so I have its features in mind… So I just was looking how to unify the various needs (more or less rigorous) in a single environent, like grass.

giovanni

2010/4/19 Moritz Lennert <mlennert@club.worldonline.be>

Jumping into the debate, since it raises some fundamental questions in my eyes;

On 19/04/10 17:46, G. Allegri wrote:

No problem, this is not what I expect. I just expect a user to be able
to import a polygonal layer, without worrying about topology correctness
(clean/build operations), and do spatial operations on it. Obviously the
correctness of results depend on the operation the user is doing (and
it’s his problem) but, i.e. a geometrical clip will be always correct, I
think…

The questions here for me are:

  • What is the actual error linked to doing operations on non-topological formats ?

  • Why do you absolutely want GRASS to do this ? If all you want to do is simple geometry operations on spaghetti files, you can easily do this with most of the available open source viewers / GIS, such as QGIS, gvSIG, uDIG, etc or even directly with ogr. Why go through the trouble of using GRASS for that ?

These operations should be quite fast for native vectors with topology.

With “rapidly” I meant: load data, do-the-op, save the results. I’m sure
that the native grass data structures can deal more efficiently then SF
structures… but often a user prefer to wait a minute more for the
operation to end, then working a minute to have to manage the data
cleaness (more often it takes much more then a minute, and it doesn’t
worth it!)

Yes, although not that rapidly because pseudo-topology needs to be
built first. Polygons do not need to be clean, but then nobody can
guarantee for the results.

Ok, but the user just have to wait and wath the progress bar
completing… that’s ok from his perspective :slight_smile:

I find it a bit suspicious when user comfort is apparently put so much higher in priority then correctness of results…

Moritz

9

On 19/04/10 23:56, G. Allegri wrote:

The language doesn't help, so please forgive me if I haven't been clear:
I don't expect from grass something more or something less, I was
wondering if with the new grass 7 features (like direct ogr access) it
was possible to make some daily operations faster.

Yes, but the fundamental question here is: should the speed of these operations be more important then their quality ?

Moritz

10

Yes, but the fundamental question here is: should the speed of these
operations be more important then their quality ?

The quality is always important. I think the question is: is topology
always required to guarantee it? The answar, IMHO, is no. In that
cases the quality doesn't depend on the data structure or the
algorithm, but on the input data. The algorithm shouldn't alter the
instrinsic quality of the information... This, of course, depends on
what you're doing. A network analysis should never let be done on
non-topo data! :slight_smile:

11

On 20/04/10 09:45, G. Allegri wrote:

Yes, but the fundamental question here is: should the speed of these
operations be more important then their quality ?

The quality is always important. I think the question is: is topology
always required to guarantee it? The answer, IMHO, is no. In that
cases the quality doesn't depend on the data structure or the
algorithm, but on the input data. The algorithm shouldn't alter the
intrinsic quality of the information... This, of course, depends on
what you're doing. A network analysis should never let be done on
non-topo data! :slight_smile:

But even a simple overlay can give wrong results if the data is not topologically clean... I personally cherish the fact that GRASS doesn't make it easy to do things quick and dirty.

Moritz

12

But even a simple overlay can give wrong results if the data is not
topologically clean... I personally cherish the fact that GRASS doesn't make
it easy to do things quick and dirty.

Probably we mean different things, or maybe I've msunderstood topology
in Grass. Spatial operators like Overlay generally leaverages on
topology graph structures (like in GEOS), but I suppsed that
pseudo-topology (as meant in Grass) would be enough to guarantee the
results. Isn't it?

13

Is it correct to say that pseudo-topology is at feature level, while
full-topology is at layer level?

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

But even a simple overlay can give wrong results if the data is not
topologically clean... I personally cherish the fact that GRASS doesn't make
it easy to do things quick and dirty.

Probably we mean different things, or maybe I've msunderstood topology
in Grass. Spatial operators like Overlay generally leaverages on
topology graph structures (like in GEOS), but I suppsed that
pseudo-topology (as meant in Grass) would be enough to guarantee the
results. Isn't it?

14

On Tue, Apr 20, 2010 at 10:25 AM, G. Allegri <giohappy@gmail.com> wrote:

But even a simple overlay can give wrong results if the data is not
topologically clean… I personally cherish the fact that GRASS doesn’t make
it easy to do things quick and dirty.

Probably we mean different things, or maybe I’ve msunderstood topology
in Grass. Spatial operators like Overlay generally leaverages on
topology graph structures (like in GEOS), but I suppsed that
pseudo-topology (as meant in Grass) would be enough to guarantee the
results. Isn’t it?

Most GRASS modules require information available in topology which might be true vector topology or other auxiliary information. This other auxiliary information also helps to make operations faster and safer, and BTW this is not a peculiarity of GRASS to require some auxiliary information. Reducing this info is in most cases not an option because it would sacrifice the accuracy of results. It remains unclear to me why you insist on reducing topological (true topological and other auxiliary) information gathering. Correct me if I’m wrong but AFAICT in GRASS there are equivalents to the SF algorithms you have in mind, IOW, in GRASS you can do everything you can do in e.g. SAGA, and a (fair) bit more. Many modules and functions already reduce the amount of topological information to the minimum required for the current operation, e.g. v.clean.

Replying to your next mail, both pseudo-topology and full topology are at feature level for all layers in a vector map.

Markus M

15

Markus, I do not doubt that grass data sructures permits efficency and
rigorous processing. And I haven't your knowladge and experience on
this field. I'm just putting myself on the (lazy?) end user experience
side, and from this point of view there's a foundamental difference
between grass and others (like saga): the v.clean step. Two recent
cases we had:

1 - we had to make a simple points in polygon count. The polygon layer
wasn't 'clean' (we hadn't perfect boundary adjacency for example), and
it was made of hundreds of thousands of polygons. The v.in.ogr
process, and the necessary clean, was taking too much time respect to
the simple operation we needed, so we imported it in saga, and with a
few clicks we had our result.

2 - we had to create a single area from a parcel shapefile, made by
lines. We could do it only with grass, thanks to its topology, through
v.type, and this worths the cleaning step...

So, I know that grass lets me to do a lot more then "the others". In
synthesis, I was just wondering if for processing ops like in case 1
one could avoid the v.clean phase...

2010/4/20 Markus Metz <markus.metz.giswork@googlemail.com>:

On Tue, Apr 20, 2010 at 10:25 AM, G. Allegri <giohappy@gmail.com> wrote:

> But even a simple overlay can give wrong results if the data is not
> topologically clean... I personally cherish the fact that GRASS doesn't
> make
> it easy to do things quick and dirty.

Probably we mean different things, or maybe I've msunderstood topology
in Grass. Spatial operators like Overlay generally leaverages on
topology graph structures (like in GEOS), but I suppsed that
pseudo-topology (as meant in Grass) would be enough to guarantee the
results. Isn't it?

Most GRASS modules require information available in topology which might be
true vector topology or other auxiliary information. This other auxiliary
information also helps to make operations faster and safer, and BTW this is
not a peculiarity of GRASS to require some auxiliary information. Reducing
this info is in most cases not an option because it would sacrifice the
accuracy of results. It remains unclear to me why you insist on reducing
topological (true topological and other auxiliary) information gathering.
Correct me if I'm wrong but AFAICT in GRASS there are equivalents to the SF
algorithms you have in mind, IOW, in GRASS you can do everything you can do
in e.g. SAGA, and a (fair) bit more. Many modules and functions already
reduce the amount of topological information to the minimum required for the
current operation, e.g. v.clean.

Replying to your next mail, both pseudo-topology and full topology are at
feature level for all layers in a vector map.

Markus M

16

I don't want to make this discussion go on too long, but

On 20/04/10 13:38, G. Allegri wrote:

1 - we had to make a simple points in polygon count. The polygon layer
wasn't 'clean' (we hadn't perfect boundary adjacency for example), and
it was made of hundreds of thousands of polygons. The v.in.ogr
process, and the necessary clean, was taking too much time respect to
the simple operation we needed, so we imported it in saga, and with a
few clicks we had our result.

This is typically the example where quick and dirty "works", but where it might contain imprecise results if you do not ensure clean polygons: any point falling into sliver polygons will be counted double. So this is exactly why I would plead for not allowing such operation in GRASS, as I see as one of the trademarks and strengths of GRASS its rigour in pushing the use as far as possible towards a careful and thoughful use of the data.

Moritz

17

On 21/04/10 00:21, Volker Wichmann wrote:

Hi Moritz,

I fully agree with you that GRASS should not change its concepts. But
your arguments are misleading: just cleanning up your vector data does
not imply that your results are more correct - the cleaning process
itself introduces new errors. so it depends on your application if it is
more appropriate to count a point twice or to let the cleaning algorithm
take the choice to which polygon it will be added. The "dirty" approach
somehow introduces some kind of fuzziness. With SAGA we also encourage
the user to know her/his data - but we leave it to the user to decide if
the she/he wants to do a certain calculation or not. It's in her/his
responsibility to interpret the results correctly. This is a thing which
software can't take the responsibility for.

I think this is exactly what I said:

>> I see as one of the trademarks and strengths of
>> GRASS its rigour in pushing the [user] as far as possible towards a
>> careful and thoughtful use of the data.

You can decide how to clean the data, but you have to make a choice. If you just let the user do what he wants without thinking about the implications of the data quality for his results, then I would wager that many analyses contain mistakes without anybody knowing about them.

As you so rightly say, it's one of these questions about whether software should impose certain limits or leave complete freedom to the user to make his own mistakes. Not currently active as a developer, but active in using GRASS for teaching and research, I see daily how GRASS allows us to avoid a series of mistakes (cf also the debate about on-the-fly reprojection). And when there are so many other tools out there to do analyses on spaghetti data, and so little developers available for GRASS, I'd rather see those spend time on the core strenghts of GRASS, then on trying to implement this particular feature.

But as always, that's only my less than 2 cents worth...

Moritz

Moritz Lennert schrieb:

I don't want to make this discussion go on too long, but

On 20/04/10 13:38, G. Allegri wrote:

1 - we had to make a simple points in polygon count. The polygon layer
wasn't 'clean' (we hadn't perfect boundary adjacency for example), and
it was made of hundreds of thousands of polygons. The v.in.ogr
process, and the necessary clean, was taking too much time respect to
the simple operation we needed, so we imported it in saga, and with a
few clicks we had our result.

This is typically the example where quick and dirty "works", but where
it might contain imprecise results if you do not ensure clean
polygons: any point falling into sliver polygons will be counted
double. So this is exactly why I would plead for not allowing such
operation in GRASS, as I see as one of the trademarks and strengths of
GRASS its rigour in pushing the use as far as possible towards a
careful and thoughful use of the data.

Moritz
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

18

These are respectable points of view. As I've repeated many times in
this post, I don't expect Grass to work different. My only questions
was: is it possible to do not-topological processing in Grass? Given
its data structures, is it possible to develop geoprocessing
operations which don't strctly require rigorous topology? It seems
that the answer is not. Ok, that's all I needed :slight_smile:

thanks for all the usefull informations you gave me,
giovanni

2010/4/21 Moritz Lennert <mlennert@club.worldonline.be>:

On 21/04/10 00:21, Volker Wichmann wrote:

Hi Moritz,

I fully agree with you that GRASS should not change its concepts. But
your arguments are misleading: just cleanning up your vector data does
not imply that your results are more correct - the cleaning process
itself introduces new errors. so it depends on your application if it is
more appropriate to count a point twice or to let the cleaning algorithm
take the choice to which polygon it will be added. The "dirty" approach
somehow introduces some kind of fuzziness. With SAGA we also encourage
the user to know her/his data - but we leave it to the user to decide if
the she/he wants to do a certain calculation or not. It's in her/his
responsibility to interpret the results correctly. This is a thing which
software can't take the responsibility for.

I think this is exactly what I said:

I see as one of the trademarks and strengths of
GRASS its rigour in pushing the [user] as far as possible towards a
careful and thoughtful use of the data.

You can decide how to clean the data, but you have to make a choice. If you
just let the user do what he wants without thinking about the implications
of the data quality for his results, then I would wager that many analyses
contain mistakes without anybody knowing about them.

As you so rightly say, it's one of these questions about whether software
should impose certain limits or leave complete freedom to the user to make
his own mistakes. Not currently active as a developer, but active in using
GRASS for teaching and research, I see daily how GRASS allows us to avoid a
series of mistakes (cf also the debate about on-the-fly reprojection). And
when there are so many other tools out there to do analyses on spaghetti
data, and so little developers available for GRASS, I'd rather see those
spend time on the core strenghts of GRASS, then on trying to implement this
particular feature.

But as always, that's only my less than 2 cents worth...

Moritz

Moritz Lennert schrieb:

I don't want to make this discussion go on too long, but

On 20/04/10 13:38, G. Allegri wrote:

1 - we had to make a simple points in polygon count. The polygon layer
wasn't 'clean' (we hadn't perfect boundary adjacency for example), and
it was made of hundreds of thousands of polygons. The v.in.ogr
process, and the necessary clean, was taking too much time respect to
the simple operation we needed, so we imported it in saga, and with a
few clicks we had our result.

This is typically the example where quick and dirty "works", but where
it might contain imprecise results if you do not ensure clean
polygons: any point falling into sliver polygons will be counted
double. So this is exactly why I would plead for not allowing such
operation in GRASS, as I see as one of the trademarks and strengths of
GRASS its rigour in pushing the use as far as possible towards a
careful and thoughful use of the data.

Moritz
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

19

On Wed, Apr 21, 2010 at 2:19 PM, G. Allegri <giohappy@gmail.com> wrote:

These are respectable points of view. As I’ve repeated many times in
this post, I don’t expect Grass to work different. My only questions
was: is it possible to do not-topological processing in Grass? Given
its data structures, is it possible to develop geoprocessing
operations which don’t strctly require rigorous topology?

Sure. By default, topology or in case of OGR vectors pseudo-topology is always built, but no module enforces correct topology. If topology is not correct, results might be not correct, but in this case results would also not be correct when doing equivalent processing in a non-topological environment. GRASS gives you the chance to fix errors that would not be detectable in a non-topological environment, but you don’t have to fix them. But then, GRASS will most probably remind you regularly that something is wrong with the data :wink:

Markus M

It seems
that the answer is not. Ok, that’s all I needed :slight_smile:

thanks for all the usefull informations you gave me,
giovanni

2010/4/21 Moritz Lennert <mlennert@club.worldonline.be>:

On 21/04/10 00:21, Volker Wichmann wrote:

Hi Moritz,

I fully agree with you that GRASS should not change its concepts. But
your arguments are misleading: just cleanning up your vector data does
not imply that your results are more correct - the cleaning process
itself introduces new errors. so it depends on your application if it is
more appropriate to count a point twice or to let the cleaning algorithm
take the choice to which polygon it will be added. The “dirty” approach
somehow introduces some kind of fuzziness. With SAGA we also encourage
the user to know her/his data - but we leave it to the user to decide if
the she/he wants to do a certain calculation or not. It’s in her/his
responsibility to interpret the results correctly. This is a thing which
software can’t take the responsibility for.

I think this is exactly what I said:

I see as one of the trademarks and strengths of
GRASS its rigour in pushing the [user] as far as possible towards a
careful and thoughtful use of the data.

You can decide how to clean the data, but you have to make a choice. If you
just let the user do what he wants without thinking about the implications
of the data quality for his results, then I would wager that many analyses
contain mistakes without anybody knowing about them.

As you so rightly say, it’s one of these questions about whether software
should impose certain limits or leave complete freedom to the user to make
his own mistakes. Not currently active as a developer, but active in using
GRASS for teaching and research, I see daily how GRASS allows us to avoid a
series of mistakes (cf also the debate about on-the-fly reprojection). And
when there are so many other tools out there to do analyses on spaghetti
data, and so little developers available for GRASS, I’d rather see those
spend time on the core strenghts of GRASS, then on trying to implement this
particular feature.

But as always, that’s only my less than 2 cents worth…

Moritz

Moritz Lennert schrieb:

I don’t want to make this discussion go on too long, but

On 20/04/10 13:38, G. Allegri wrote:

1 - we had to make a simple points in polygon count. The polygon layer
wasn’t ‘clean’ (we hadn’t perfect boundary adjacency for example), and
it was made of hundreds of thousands of polygons. The v.in.ogr
process, and the necessary clean, was taking too much time respect to
the simple operation we needed, so we imported it in saga, and with a
few clicks we had our result.

This is typically the example where quick and dirty “works”, but where
it might contain imprecise results if you do not ensure clean
polygons: any point falling into sliver polygons will be counted
double. So this is exactly why I would plead for not allowing such
operation in GRASS, as I see as one of the trademarks and strengths of
GRASS its rigour in pushing the use as far as possible towards a
careful and thoughful use of the data.

Moritz

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

20

Thanks Markus, this is what I needed to know. So, in synthesis:

clean topology is not required for vector processing algorithms to
work correctly (this is what I thought...) => (obviously) correctness
of results ONLY depend on correctness on input, not on algorithm
problems with unclesn topology.

thanks,
giovanni

2010/4/21 Markus Metz <markus.metz.giswork@googlemail.com>:

On Wed, Apr 21, 2010 at 2:19 PM, G. Allegri <giohappy@gmail.com> wrote:

These are respectable points of view. As I've repeated many times in
this post, I don't expect Grass to work different. My only questions
was: is it possible to do not-topological processing in Grass? Given
its data structures, is it possible to develop geoprocessing
operations which don't strctly require rigorous topology?

Sure. By default, topology or in case of OGR vectors pseudo-topology is
always built, but no module enforces correct topology. If topology is not
correct, results might be not correct, but in this case results would also
not be correct when doing equivalent processing in a non-topological
environment. GRASS gives you the chance to fix errors that would not be
detectable in a non-topological environment, but you don't have to fix them.
But then, GRASS will most probably remind you regularly that something is
wrong with the data :wink:

Markus M

It seems
that the answer is not. Ok, that's all I needed :slight_smile:

thanks for all the usefull informations you gave me,
giovanni

2010/4/21 Moritz Lennert <mlennert@club.worldonline.be>:
> On 21/04/10 00:21, Volker Wichmann wrote:
>>
>> Hi Moritz,
>>
>> I fully agree with you that GRASS should not change its concepts. But
>> your arguments are misleading: just cleanning up your vector data does
>> not imply that your results are more correct - the cleaning process
>> itself introduces new errors. so it depends on your application if it
>> is
>> more appropriate to count a point twice or to let the cleaning
>> algorithm
>> take the choice to which polygon it will be added. The "dirty" approach
>> somehow introduces some kind of fuzziness. With SAGA we also encourage
>> the user to know her/his data - but we leave it to the user to decide
>> if
>> the she/he wants to do a certain calculation or not. It's in her/his
>> responsibility to interpret the results correctly. This is a thing
>> which
>> software can't take the responsibility for.
>
> I think this is exactly what I said:
>
>>> I see as one of the trademarks and strengths of
>>> GRASS its rigour in pushing the [user] as far as possible towards a
>>> careful and thoughtful use of the data.
>
> You can decide how to clean the data, but you have to make a choice. If
> you
> just let the user do what he wants without thinking about the
> implications
> of the data quality for his results, then I would wager that many
> analyses
> contain mistakes without anybody knowing about them.
>
> As you so rightly say, it's one of these questions about whether
> software
> should impose certain limits or leave complete freedom to the user to
> make
> his own mistakes. Not currently active as a developer, but active in
> using
> GRASS for teaching and research, I see daily how GRASS allows us to
> avoid a
> series of mistakes (cf also the debate about on-the-fly reprojection).
> And
> when there are so many other tools out there to do analyses on spaghetti
> data, and so little developers available for GRASS, I'd rather see those
> spend time on the core strenghts of GRASS, then on trying to implement
> this
> particular feature.
>
> But as always, that's only my less than 2 cents worth...
>
> Moritz
>
>
>> Moritz Lennert schrieb:
>>>
>>> I don't want to make this discussion go on too long, but
>>>
>>> On 20/04/10 13:38, G. Allegri wrote:
>>>>
>>>> 1 - we had to make a simple points in polygon count. The polygon
>>>> layer
>>>> wasn't 'clean' (we hadn't perfect boundary adjacency for example),
>>>> and
>>>> it was made of hundreds of thousands of polygons. The v.in.ogr
>>>> process, and the necessary clean, was taking too much time respect to
>>>> the simple operation we needed, so we imported it in saga, and with a
>>>> few clicks we had our result.
>>>
>>> This is typically the example where quick and dirty "works", but where
>>> it might contain imprecise results if you do not ensure clean
>>> polygons: any point falling into sliver polygons will be counted
>>> double. So this is exactly why I would plead for not allowing such
>>> operation in GRASS, as I see as one of the trademarks and strengths of
>>> GRASS its rigour in pushing the use as far as possible towards a
>>> careful and thoughful use of the data.
>>>
>>> Moritz
>>> _______________________________________________
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev