> 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...).
No, and I whether we ever bother to is an open question. There are a
couple of problems with the OGC specs in this regard:
- They're *hard*, having some really difficult cases in among the
- They're of dubious usefulness in practical work.
That being said, there is actually a project going on here in Victoria
(Canada) which is implementing the full SF spec and the functions. It's
called the 'Java Topology Suite' and being funded by the Canadian and BC
governments. The result will be a complete java implementations of the
SF spec, with robust implementations of things like intersections,
unions, etc. And it'll be released under an open source licence. It may
be useful as a middleware to an OSS GIS suite, or as a source of
algorithms which can be bolted into PostGIS. Either way, a good thing.
> 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.
I think clearly the short-term goal has to be a simple, robust, fast,
feature store. A backend to all the display projects like MapServer,
etc. Right now the API is SQL, with the SQL text representation for the
geometries. There does not seem to be any other developed standard
around for a "higher level" API, like an XML-over-HTTP, floating around
for us to implement.
Another area we have not addressed is projections and metadata. Having
provided the objects, doing an actual implementation has been left as an
exercise to the reader. Once we say something bold like "we support
multiple projections transparently" the amount of require infrastructure
and discipline around required tables and setup of an implementation go
up quite dramatically. Is that kind of suppport a very important