[postgis] Big Database

Paul Ramsey pramsey at refractions.net
Tue Oct 9 16:08:56 PDT 2001



"Roderick A. Anderson" wrote:

> While doing this I think a found a problem with PostGIS - or actually
> OpenGIS. If I understand it correctly you can only have one data type;
> point, line, polygon, in one coordinate system; UTM 11N in a table.
>    This seems to go along with the way most GIS software wants to handle
> the data but is kind of limiting from a database perspective.  If I want
> all the data in an area (BOX) why do I have to query several tables? 

Philosophical and technical issue. To index a Big Bin of Features, you
really need to have them be in the same coordinate system. The obvious
solution is to store everything in lat/lon. The trouble with lat/lon is
that it is a spherical coordinate system and here on earth we limited
human creature tend to perceive the world around us as flat: so the kind
of questions we ask are usually cartesian. One solution is to still
maintain all the data in lat/lon, but provide functions with operate
directly on the spherical coords to product cartesian-style answers. So
I can ask distance(X,Y) and get a crows-path distance in linear units.
The math required to do this is very very involved, because the earth is
not actually spherical.

> And
> shouldn't my GIS or COGO software transform the data to whatever system
> it (or I) want it in.  

Yes, but you should not expect efficient operations if for every feature
in the database, the system has to ask "what coordinate system is this?
ok, change it to somethign else. ok, now do an operation". Far better
that you just design your system to have a unified coordinate system. 

> I see a way around some of these limitations but
> it would be a kludge (use UNIONs) and could fail on a REALLY big query.

You are thinking as someone who is dumping data into a bit bucket, not
someone who is designing a spatial database. A table in a spatial
database will usually comprise a "feature type" which has some
importance with respect to other tables. It does not make alot of sense
to mix your roads and streams up together in one "gis table" when
realistically you will never be querying both featureclasses at the same
time. If all your queries and up looking like "Select blah from
linetable where somthing and featclass = 'road'" then you have something
wrong with your design.

> So I'm still looking and testing but wanted to let those that have been
> so helpful know that I hadn't stopped working on this.

Keep on working on it. Check out the 'ogr' library, I think it has some
reprojection utilities you can use to put everything into one system.
 
-- 
      __
     /
     | Paul Ramsey
     | Refractions Research
     | Email: pramsey at refractions.net
     | Phone: (250) 885-0632
     \_

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get your FREE VeriSign guide to security solutions for your web site: encrypting transactions, securing intranets, and more!
http://us.click.yahoo.com/UnN2wB/m5_CAA/yigFAA/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/ 





More information about the postgis-users mailing list