[GRASS5] Re: [GRASSLIST:5030] Re: Grass Data Model used for areas

Radim Blazek blazek at itc.it
Fri Nov 22 07:59:28 EST 2002

On Thursday 21 November 2002 05:09 pm, jprs wrote:
> > > Is the Grass Data Model compliant with OGC standards,
> > > or will the OGC data model standards evolv to Grass Data Model?
> > No.
> What about the other way round? Will GRASS comply with OGC standards?
> If the question makes any sense.

[I use "topologogical area model" (TAM) if areas are formed by set of 
boundaries and identified by centroid (like in grass or A/I coverage)
and "non TAM" (NTAM) for areas represented by closed polygons (like
OGC SF or shapefile) in this mail; any standard names exist?]

Grass cannot be compliant with SF until it uses TAM and SF uses NTAM. So the
question is: "Should be NTAM used by GRASS instead of TAM?" (I don't worry
that OGC would ever use TAM.) This is realy hard question. Something about 

When arguing for and against (N)TAM, I think that we can forget about some
traditional arguments like:
- NTAM wastes space because it stores shared boundaries twice:
   It seems that there are no problems with space for vectors nowadays.
   (We could maybe talk about PDA or mobile phones today but not tomorrow)
- TAM is difficult to create/maintan: I think that this is not valid
   if we have good tool for editing, which can edit vectors with topology,
   and where all errors are immediately visible on the screen like partialy
   v.digit/50 and fully v.digit/51.
- NTAM is difficult for creating/maintanance: Again, I thing that if a good
   tool for editing is available (which enables for example to select to
   points on existing polygon and all vertices between are added to currently
   drawn one so that we don't need to digitize twice etc.), editing NTAM
   should not take much more time than TAM.
- TAM is necessary for spatial operations: If topology information is
   required, it may be calculated for NTAM also.
- In NTAM is impossible to create good quality data (gaps, overlaps): 
   If tools for checking this errors are available (either after editing or
   during editing), it is not problem.
- NTAM contains duplicate informations (shared boundary), such thing we should
   avoid in information systems: If SW is capable to handle it (is it?:) and
   it is not left for user, I don't see it as a problem. 

Currently I know only about one real disadvantage of TAM: Overlaping, usually 
artificial area objects like bridges and tunnels cannot be represented in 
TAM. If one road is on the bridge and seccond one under the bridge it is 
difficult (impossible?) to do that in TAM. 3D is not solution
as it is too difficult for maintanance and anyway, centroids are assigned 
to areas by x,y only. When I expect that we want everything in one vector 
file, I see only one solution. Overlaping area can be linked to more rows in
one table and each record represents one level (ground and bridge).
This is just idea and it must be proved if this is reasonable.

One argument against NTAM is that boundaries cannot be generalized easily.

Other reasons (less important?) for NTAM could be:
- TAM is more difficult to implement in SW (I think)
- OGR is SF
- PostGIS is SF

and for TAM:
- GDF is TAM
- we like TAM

These are arguments, I know about. If you know about any others, please tell 

Another question is: Is it possible to interchange/share data between TAM and 
TAM -> NTAM is easy (like coverage in OGR, maybe sometimes grass in OGR)
       or v.out.ogr
NTAM -> TAM is more difficult and in GRASS supported in 2 different ways:
    a) import (like v.in.shape), data are converted/cleaned, overlaps are lost
    b) pseudo topology (like shapefiles in g51); area is available 'as is' 
       in NTAM (including overlaps), but some operations cannot be fully
       performed (like v.reclass, v.cutter) - result written in
       GRASS native format is not TAM (must be cleaned)

I must say that I like a bit more idea of TAM, and I discussed this during 
GRASS Conference in Trento with some people (namely R.M, B.R., R.G., D.M., 
R.B.) and in general they support idea of TAM or at least do not protest too 

I am wayting for your comments.


More information about the grass-dev mailing list