[GRASSLIST:5052] Re: Grass Data Model used for areas

[Richard Greenwood]

Hello Radim,

You have done a very good job of looking at the topological options and 
presenting them in an objective way. As you stated, the main advantage of 
the NTAM is that it is easier to show overlapping areas. There are many 
instances where overlaps and gaps truly exists in the real world, and being 
able to model them in the GIS is nice. But the ability to link one area to 
more than one record would address this problem in a TAM.

Many of the problems in both models are due to poor editing tools. In the 
TAM, it is easy to break the topology when editing. Similarly, in the NTAM, 
it is easy to create un-intended gaps and overlaps when editing. If the 
editing tools are designed with the topological model in mind, then many 
problems can be avoided. Unfortunately, we are so often forced to use a CAD 
program, which knows nothing of topology, to edit out work.

Also, it would be nice to be able to edit more than one map, or layer, at a 
time. For example, if I move a parcel line, that line may also define a 
municipal boundary stored in a different map (or layer). If I update parcel 
line, I would like to also have the municipal boundary update.

Rich



At 01:59 PM 11/22/2002 +0100, you wrote:

>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
>TAM x NTAM and TAM in GRASS:
>
>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)
>- SFS is NTAM
>- OGR is SF
>- PostGIS is SF
>- SDE is NTAM
>
>and for TAM:
>- GDF is TAM
>- we like TAM
>
>These are arguments, I know about. If you know about any others, please tell
>us.
>
>Another question is: Is it possible to interchange/share data between TAM and
>NTAM?
>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
>much.
>
>I am wayting for your comments.
>
>Radim

Richard W. Greenwood, PLS
(307) 733-0203
Rich at GreenwoodMap.com
www.GreenwoodMap.com