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

[David D Gray]

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 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>