Some comments on the TAM/NTAM debate.
Radim Blazek 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:
There is perhaps a need for a TAM standard, but as this is very dynamic (for us now), perhaps we want to wait till we see more where we are going... 5.1 stable? Then, maybe the GRASS team could propose a standard and release an RFC.
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)
May be moving to a situation where TAM takes up more than NTAM. As topological models become more sophisticated, the extra information stored per TE (topological entity), might outrun the duplicate entries of SF (eg).
- 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.
The WAY TO GO. We must concentrate IMHO in future editing facilities in GRASS on a more intuitive interface, but if that is TAM, it means the map must be built incrementally as it is developed (BAYG or 'build as you go'). Also an 'expert' mode must remain avilable, so that terrible errors caused by other peoples' software can be fixed 
- 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.
But the real problem is stability of existing data. I think it likely, that creators of NTAM editors hav probably trod this path already and will be aware of the issues. Still, existing NTAM coverages are very prone to error. TAM has problems of its own - possibly in the early days many people wanted to abandon this method because of all the minor topological errors that arise in their formation, like degenerate areas, lollipops, dangles and the like. But these are structural blemishes that can be mostly elliminated automatically, and what is left highlights changes that ought to be considered and fixed manually. Polygon coverages routinely show slippage of boundaries, and then it is impossible to decide how the map should be fixed.
- TAM is necessary for spatial operations: If topology information is
required, it may be calculated for NTAM also.
It is more difficult to go TAM -> NTAM, and this is where topological cleanliness and information stablity is crucial. If the three corners of a node are misaligned in a polygon (NTAM) coverage the system must not only correct this (see my remarks under previous paragraph), but must make assumptions.
- 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.
The tools that I have seen for these problems do not work perfectly, there are still errors visible in the linework when it is viewed in a TAM coverage (as is). Also, many methods must generate the topolgy 'on the fly', which seems round about to me.
- 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.
Polygon coverages are inherently mutable, and we must remember that the milieu in which we work has a human/social factor as well. Becuase NTAM coverages can get 'out of shape', they will ... and do. as mentioned earlier, also, I don't think software can handle these problems adequately.
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.
It is possible, if difficult. The main point is that you need some kind of attribute, a hidden attribute or 'ghost code' maybe, to specify which TE is on top anyway, both in TAM and NTAM. In both cases you need to know the history of the map's construction to correctly assign level if you have no such index. That is bad information structure, as entities do not 'encapsulate' all the properties of their construction depending, for example, on the sequence of import.
You can build a TAM coverage with overlapping structures, if you assign topological features _locally_ like left/right polygon of a boundary while you are importing/building/editing, instead of holistically at the end. It might be possible to (re)build a map at the end, but overlapping features might not build unambiguously : we have this problem in the stable vector format for lines now.
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.
Agreed that layering is the best approach, and keep the coverages as simple as possible. I would just add: we must distinguish between levels and layers. A layer is an independent coverage, which represents the same spatial range in different ways. For example, a polygon coverage rerpesenting soil classes, and a line coverage representing the boundaries of the same, where attributes of the edges must be emphasised, like hard/soft/landline/now-gone boundary. A level may occur in a layer representing, for example area cover, but such that entities in the same layer might overlap, like roads at a complex motorway junction. This can be handled by 'ghost codes'. There are several levels, and any TE can be aware of only those sharing its level, so if two overlapping areas share one edge, the edge is in two levels, but the other boundaries only in one. The build process then builds the two areas OK. This would be easy to implement in v.build, as it would just be a question of doing separate build runs for each level. Assigning the levels would be more difficult.
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
As above, we can change this so overlaps are not 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)
Regular topology of normal shapefiles can be done with levels method above. But then each shape has its own level, and no 'awareness' of its neighbours.
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
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5