[GRASS5] GRASS -> SF

[Radim Blazek]

On Wednesday 18 February 2004 18:52, Frank Warmerdam wrote:
> Radim Blazek wrote:
> > In past 4 years, you are probably the second person interested in that,
> > so I don't spend much time documenting data model ...
>
> I sympathize, but I still think it will be valuable if you want people
> to be able to take advantage of the new vector capabilities effectively
> (and without undue hand holding).

GRASS data model is briefly described here
http://www.ing.unitn.it/~grass/conferences/GRASS2002/proceedings/proceedings/pdfs/Blazek_Radim.pdf

I think that important for an effective use of GRASS vectors is to know that:
1) geometry and attributes are stored separately
   (don't read both if it is not necessary (usually it is not))
2) the format is topological (areas build from boundaries)

GRASS model isn't too complex and I am not the only one who can describe it.
I would welcome a document written by native English speaker or simply 
by anyone who can discribe it clearly in English. I can assist.

> > 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?
>
> I agree that this is a common restriction, but by no means universal.
> OpenEV, and PCI's viewers all support hetrogeneous geometries in a single
> layer.  CAD programs (ie. Microstation) generally support diverse
> geometries in a layer.  I think Mapinfo does as well, at least .tab files
> can mix geometry types in a layer.  Of course, in use, even then people
> will often only keep a single type of geometry in a given layer.
>
> I think it would be helpful if the type(s) of geometries present in a layer
> were readily available to application linking to GRASS data.  That would
> make it easier for them to choose to describe a given layer as multiple
> layers of segregated geometry types without having to always assume all
> types are present.  In OGR this is partially accomplished by data sources
> setting the geometry type for a layer if it is restricted.

How geometry type can be set in OGR? I see only SetAttributeFilter
and SetSpatialFilter?

What you suggest may be solution if an application knows about that possibility, 
and supports it. But it may happen that it simply refuses to open 
anythig else than WKBPoint,WKBLine,WKBPolygon.

Would it be acceptable to duplicate features in more layers (if necessary)?
?_point
?_line
?_all     // contains features from both ?_point and ?_line

> > 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)).
>
> I think I still don't get how the boundaries work.  In a well formed
> polygon layer, is the one closed boundary per polygon feature?  

No, polygon may be formed by many boundaries (more primitives but connected).
One boundary is shared by adjacent areas.

+--1--+--5--+
|     |     |
2  A  4  B  6
|     |     |
+--3--+--7--+

1,2,3,4,5,6,7 = 7 boundaries (primitives)
A,B = 2 areas

> If there are centroids how are they associated with their polygon?

Centroid are assigned to area it is within/inside (geometrically).

Radim