If anyone expects this to be more than academic, i.e. in production within mission-critical government and industry applications, GRASS had better support a 'live link' to a real database, like PostGIS.
Chris
-----Original Message-----
From: Radim Blazek [mailto:blazek@itc.it]
Sent: Wed 2/18/2004 9:14 AM
To: Frank Warmerdam
Cc: grass5@grass.itc.it
Subject: Re: [GRASS5] GRASS -> SF
On Tuesday 17 February 2004 19:31, Frank Warmerdam wrote:
Radim Blazek wrote:
> I would like to hear your suggestions on how to represent
> GRASS vectors as simple features ....
Radim,
I skimmed the following document to try to further understand the current
vector data model, but I found it unhelpful on the area of topology.
http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass51/doc/vector/vector
.html#topo
In past 4 years, you are probably the second person interested in that,
so I don't spend much time documenting data model ...
I'm not sure if you are primarily interested in approaches that should
be taken when exporting to a simple features type format, or with how "live
access" should be provided to simple features applications, as you might do
in an OGR driver for GRASS vector format for instance.
I am interested in "live access". For export serves v.out.ogr,
which can be changed later without problems, but layer names for
live access and their meaning should not change frequently.
As I see it there are a few issues:
1) Q: Should different geometry types within a GRASS layer be seperated
into different layers for simple features purposes?A: The simple features data model supports a concept of layers that may
contain all geometry types. Therefore, I don't think you should split
things up into different layers by geometry type by default. This
would be a useful option in an export program though, as many formats (ie.
shapefiles) do have restriction requiring only one geometry type per layer.
That is true, but I worry, that some (many?) applications support only layers
of certain type (point,line,polygon) and they will not work with mixture
of types. Often it is logical, everything is much simpler if legend
has just one symbol etc.
Does anybody know a GIS viewer which can display more types in one layer?
2) Q: Should only the category attribute be considered part of the feature
or also the other fields from tables that can be referenced by the
category.A: I'm not clear about whether vector layers include persistent
references to the table(s) the category should be used to reference, or if
this linkage info is only provided on a command-by-command basis. If there
is a persistent linkage then I think that the default should be to join all
attributes into the feature based on the category id(s). On export both
modes should be supported, with the default being to join if the linkages
is known.
Link to the table is permanent and it is stored in 'dbln' file in vector
directory. Tables are considered to be a part of the vector and g.remove,
for example, deletes linked tables of the vector.
Yes, attributes must be joined with geometry.
3) Q: How should topological relationships be preserved.
A: I am still unclear how this is handled in GRASS. Are areas
represented as boundary objects in GRASS? Do these boundaries include the
whole edge geometry, or just a reference to arcs (GV_LINES) that make up
the boundary? In general I think you should export GV_BOUNDARY objects as
whole polygons, even if it means collecting up arcs to form the polygon
geometry. Topological relationships should be be preserved to the extent
possible as attributes on the features. I am unware of any really widely
accepted convention for this.
GV_BOUNDARY contains geometry and it is used to build areas.
GV_LINE cannot form an area.
I agree, that whole polygons must be available, but boundaries and centroid
in raw form should be available as well (import to another topological GIS,
display errors in data (boundary is not closed)).
Radim
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5