[GRASSLIST:5035] Re: Grass Data Model used for areas
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
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
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)
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-user