[GRASS5] GRASS -> SF

[Frank Warmerdam]

Chris G. Nicholas wrote:
 > 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,

I would contend that lots of real production work is done without
databases, but nevertheless you are correct that the ability to
hold data in a spatial database is important, and I am pretty sure
it is already implemented in the new GRASS vector architecture.  Though
my vague recollection is that there are performance issues with the
way that PostGIS is currently used from GRASS.  I'm not sure how true
that is.

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

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

> 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?  If there are centroids
how are they associated with their polygon?

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