[Freegis-list] Re: [OSVecDB] PostGIS Features

[Allan Doyle]

There's a new chunk of geometry info in the OGC RFP that's out right now,
which may fill in the gaps, but may  also be a bit on the complex/overkill
side. See http://www.opengis.org/info/press/033001Geom_RFP.htm

There is also extensive work going on in the GML side of things to add
topology and other  things. I don't know how much of that info is publicly
available, but you could check the galdosinc.com site.

Galdos is also releasing a GML Java implementation on sourceforge.
https://sourceforge.net/projects/gml4j

	Allan

"Eric G. Miller" wrote:
> 
> On Tue, Jun 05, 2001 at 09:02:43PM -0700, Paul Ramsey wrote:
> > Hi folks, I came across this list by accident after our first release:
> > I'm one of the people from Refractions involved in the PostGIS work (not
> > one of the smart ones, just a talkative one). Right now what we have is
> > a core set of functionality, things like:
> [snip]
> > The question we're asking ourselves now is: what next? Some things are
> > on the list already:
> >
> > - Testing testing. Loading some big datasets, building some big indexes.
> > - A gml() output function which renders output features in GML. This
> > could be useful in a feature server.
> > - More complete and better organized documentation. Right now things are
> > a little snagletoothed.
> 
> I haven't gotten a chance to look closely at PostGIS, but does it
> support all of the functions of the OGC docs?  What I've read, it seems
> like they aren't all there (like union/intersect, etc...).
> 
> > Longer term, it seems clear to us that any useful spatial database also
> > has to support a coverage topology. There are going to be datasets which
> > fit a coverage model and can get great leverage by using one. Other
> > datasets fit a simple features schema better. But really, the system
> > needs both.
> 
> Coverage topology would be nice for (routes, regions, networks, etc...).
> GeometryCollection is a terrible way to implement such things.  It may
> eventually be more practical to use lower level database primitives,
> rather than the big complex struct.  In theory, it should be possible to
> map the graph representation to a set of related tables, but it's
> non-trivial to manage.  Also, it diverges from the OGC spec.  Seems
> likely that keeping all datasets in one "Features" table will not be
> very efficient unless each dataset has it's own database (too bad
> postgresql doesn't *yet* support schemas).
> 
> I think a valid question to consider is whether this repository will
> function as a data development repository, or mostly for serving up data
> for display/query.
> 
> > However, short term suggestions is what we really need. Is anyone
> > thinking of using something like postgis in a project? If so, what kind
> > of features would it require?
> 
> I'm very interested.  I'm currently on a new GIS Library Architechture
> committee and folks are very interested in a generic but scalable
> library that is not tied to any vendor's product and metadata (FGDC/ISO)
> handling.  Please feel free to contact me directly.
> 
> --
> Eric G. Miller <egm2 at jps.net>
> ----------------------------------------
> OpenSource Vector Database Discussion List
> See http://gdal.velocet.ca/projects/osvecdb/ for subscription, unsubscription
> and other information.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allan Doyle                     adoyle at intl-interfaces.com
International Interfaces        +1 781 433 2695 (Office)
http://www.intl-interfaces.com  +1 781 254 9484 (Mobile/Voicemail)