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 NTAMand for TAM:
- GDF is TAM
- we like TAMThese 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@GreenwoodMap.com
www.GreenwoodMap.com