[GRASS5] GRASS -> SF

[Radim Blazek]

On Wednesday 18 February 2004 18:32, 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.

There are currently 2 "live" links and both are almost dead, i.e. almost nobody
use them, and nobody works on them. 
1) 'postgis' format. Primiteves are stored in PostGIS but topology is build in GRASS.
Last person interested in this format was Martin Pokorny 11/2003, he did some tests
and tried to optimise it. I am wayting for results of his benchmark 
for modified version where everything is done in one transaction.
Are you still here Martin?
This format I want to disable in future versions of 5.7.
2) 'ogr'. Implemented by  Piero Cavalieri, available here:
http://mpa.itc.it/radim/g51/Piero_OGR.tar

Did you experiment with these formats? What do you mean about them?

What are advantages of PostGIS database over GRASS format?
Which GRASS functionality could be used in such mission-critical applications?
How could be GRASS integrated into such applications?

Radim



> -----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/vect
> >or .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