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

[Juanse]

In my research of GIS opensource proyects state of the art, and the
possibilities that a synergic look opens, i ended up evaluating which front
end where available for using with PostgreSQL/PostGIS the selected
opensource spatial backend. My basic question about data model started
because the need to evaluate Grass as the front end OpenSource option for
building the datasets and manipulating the data i search of answers.  The
application we envisage is a multiuser one, ASP flavour one.

The "more than one click" front end option are from one side: programm it
your self over Java, with this last month trend to a gathering off different
OS proyects (see www.geoenabler.com Call for Geo-Spatial Java API ) or use
Grass, that is much more than a front end as we learned from Mr Blazek and
his excelent explanation of Topology. To Tam or Ntam, that is the question!!

I imagine the Tam / Ntam question also applies to the Java Topology Suite
http://www.vividsolutions.com/jts/jtshome.htm, since Geos++ is a C version
of this Suite for the use with PostgreSQL, and OpenEV and Geotools2 as they
connect to the world through GDAL/OGR, but I will like a check to this?

As Mr Greenwood correctly points out the question is what to do when
constructing datasets, or what is more the usual case, how to migrate a Ntam
data set to a Tam data set easily, and most likely viceversa.

¿Are there any consolidated data model for the usual cases where Tam is need
(as the city one mentioned by MR Greenwood: Cadastral actualization, or a
watershed model, etc)? Are there any conventions, agreements, standards for
clasical features (roads, hidro, parcels, administrative boundaries, etc)?

At the end, Mr. Blazek, if I decide to proceed with migrating my dataset to
PostgreSQL/PostGis using ogr2ogr, therefore as OGC-SF, would I be able to
edit (read/write) that data with Grass 5.1. and generate a TAM data model,
with the resulting data stored in Postgres? How?


Juanse
temuko-Chile



 ----- Original Message -----
From: Richard Greenwood <rich at greenwoodmap.com>
To: <GRASSLIST at baylor.edu>
Sent: Sunday, November 24, 2002 8:42 PM
Subject: [GRASSLIST:5052] Re: Grass Data Model used for areas


> 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
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.417 / Virus Database: 233 - Release Date: 08/11/02