[postgis] Structure and Topology questions

[mbdavis]

I'm no expert on temporal database systems in general, and spatio-temporal
systems in particular, but it seems to me that the crucial issue with
spatio-temporal DBMSes would be the indexing.  Time introduces a third
dimension into the equation, over and above the 2 dimensions of the spatial
data.  Now it may be that this can be handled simply by adding standard
linear indexes for the temporal data, but I can imagine that it would be
more efficient to combine the temporal data with the spatial data in a
3-dimensional index.  Would the GIST index available in PostgreSQL allow you
to construct a suitable index for 3-dimensional data?  Would this have
implications on the datatypes used to support temporal (i.e. would the
temporal data and the spatial data need to be contained in a single object
to allow building a GIST index?).

I think there are some other issues with spatio-temporal systems as well,
but they may have more to do with what the time dimension means in the
context of spatial data rather than with implementation issues.  The
standard work on the subject I believe is Gail Langran's book.  Paul, since
she lives in Victoria it might be worth discussing it with her!

Martin



-----Original Message-----
From: Paul Ramsey [mailto:pramsey at refractions.net]
Sent: Sunday, July 29, 2001 8:17 PM
To: postgis at yahoogroups.com
Subject: Re: [postgis] Structure and Topology questions


Adrian Custer wrote:
> 
> I have some questions about the project that I hoped someone could
> clarify.
> 
> Someone said recently that PostGIS only supported 2-D +1 not true 3D. Is
> this correct and if so could someone explain why this is being done?

It's a question of semantics. GIS systems are sometimes labelled 2.5D if
they can store 3D coordinates but generally ignore them for processing
purposes. Most 3D GIS systems are in fact 2.5D. IE: things like 'does
line X and line Y intersect' are calculated with respect to the X/Y
plane only.

> Also the GML spec is still 2-D. I understood that PostGIS wanted to
> support GML so what will it do about the lack of the third dimension?

Same thing we have done with Well Known Text and Well Known Binary: an
enlightened hack. You can force full OGC compliant behavior by just
forcing your features to be 2D before outputting them. For Well Known
Binary, Dave followed Frank Wamerdam's spec on 3D WKB features, which is
a rational shoehorning of the OGC spec into a third dimension. For Well
Known Text there's just an extra coordinate for any 3D points. Same
thing will happen with GML.

> PostGIS is ignoring the temporal nature of goemetric objects right now.
> Is the vision envetually to support this? I've run across quite a few
> situations where the same object must be represented differently at
> different times. 

Give us an idea of how a temporal implementation might impact the
PostGIS design? Remember, you have a whole relational database to work
with in PostgreSQL -- does PostGIS itself need changes to support
temporality, or can a good database design encapsulate all the necessary
concepts? I admit right up front that I've read no works on temporality,
my experience is entirely related to versioning systems implemented in
some of the BC provincial data sets.

> What is the plan to develop/ construct topology? Is the vision that we
> will be able to import a shapefile into a PostGIS layer and have it
> construct the topology for complex queries to be done through the
> database? I realize this is for the future but I didn't know if that was
> the eventual plan. Does anyone have good information sources on the
> constructioon of toplogical relationships in a realational database for
> line networks, directed line networks (e.g. rivers), and plane objects
> (e.g. a complete polygon coverage like a soil map)?

The plan right now is to wait-and-see for a decent specification to
follow. There are some preliminary specs for coverages and networks
available from OGC, but in unrelated topic areas. We could probably use
them as a guidepost, but until Simple Features are close to done do not
have plans to advance in that direction. (Unless so directed by a
client. :) Like Adrian, I would love some references to works giving
ideas on how best to represent coverages and networks in a spatial
RDBMS.


To unsubscribe from this group, send an email to:
postgis-unsubscribe at yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Small business owners...
Tell us what you think!
http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/PhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
postgis-unsubscribe at yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/