[GRASS5] GRASS -> SF

[Frank Warmerdam]

Radim Blazek wrote:
> Hi all,
> 
> I would like to hear your suggestions on how to represent 
> GRASS vectors as simple features. Probably this is not precise, 
> I did not studied all OGC documents, I mean how to represent 
> GRASS vectors in free GIS software which uses OGC specifications, 
> for example OGR, PostGIS, QGIS.
> 
> How to divide GRASS features in one vector to appropriate layers?
> 
> Note that features in GRASS vector may have attributes
> in different tables or may be without attributes. Boundaries 
> forms areas but it may happen that some boundaries are not closed
> (such boundaries would not appear in polygon layer).
> Boundaries may have attributes. All types may be mixed in one vector.
> 
> Simply, GRASS vector is a jungle and I am looking for a way 
> how to represent this flexible format in software like OGR without making
> to much confusion between users.

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

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.

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.

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.

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.

    We discussion options for special topology support in OGR some time ago (last
    summer?) but I haven't done anything about it at this time.

I may have missed it, but I would like to see a GRASS Vector Data Model document
prepared.  This might possibly be a part of the vector format document, though
ideally as a part of a users manual with references off to a format document.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent