[GRASS5] GRASS -> SF

[Chris G. Nicholas]

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 at itc.it]
Sent:	Wed 2/18/2004 9:14 AM
To:	Frank Warmerdam
Cc:	grass5 at 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 at grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5