Hey Landon, You probably want to at least skim the OGC 'Open GIS Simple Features Specification for SQL' document: http://portal.opengeospatial.org/files/?artifact_id=829
And then explore how PostGIS implements simple features" http://postgis.refractions.net/ Your wrote "I believe the geometry object is stored in a single field of a database table as a BLOB or a text string that can be parsed by the spatial database engine for processing of spatial queries." A key to this is the spatial indexing. For most queries,assuming proper spatial indexes, the spatial database engine does not need to do anything to parse the geometry object. The needed information is in the spatial indexes. You are coming really close to the terrain of 'Object Relational Mapping,' so looking at that is probably useful: http://en.wikipedia.org/wiki/Object-relational_mapping You are totally bumping into the object-relational impedance mismatch bugaboo... http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Regards, Rich On Nov 30, 2007 12:19 PM, Landon Blake <[EMAIL PROTECTED]> wrote: > Thanks for that response Frank. I find this very interesting. > > It seems that you could model just about any data stored in a RDBMS as > an object in an object-oriented programming language. > > For example: If you were writing a database program for used car lots > you could represent cars as objects instead of data in individual table > cells. But at some point you have to ask, is this worth the effort? I > think that is one advantage of the RDBMS model, you can represent all > types of data without custom programming. > > Still, I wonder if the overhead of an additional engine on top of the > database makes the speed gap small. Have there been any documented > benchmarks that compare this model to others? > > I think I'll see if my friend is interested in running some tests. > > I appreciate the input. > > SLB > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Frank Warmerdam > Sent: Friday, November 30, 2007 11:37 AM > To: [email protected] > Cc: Mark Dennehy > Subject: Re: [Geowanking] Storing Simple Geometries in a RDBMS Model > > Landon Blake wrote: > > What are the limitations or technical challenges that come from a > > different approach, that of storing feature geometries in a database > > using the traditional relational database model? > > > > For example: > > > > A database has a Coordinates table which stores a unique id for each > > coordinate, with a northing, easting, and elevation. The database has > > another Line table which stores a unique id and perhaps the length of > > the line. A third PointsToLines table stores entries that link > > Coordinates to Lines using the unique ids in both tables. Queries > could > > then be executed to obtain all the coordinates that make up a line, > for > > example. > > > > Is there a reason why this technique is not used more frequently? Is > > there popular software that does use this technique to store spatial > data? > > Landon, > > This was the "base model" for the original OGC simple features > specification > for SQL and has been used from time to time. But I believe it is not > widely > used because it is deathly slow. It is expensive to fetch a feature > with it's > geometry, and it's expensive to find out what feature(s) match a > particular > spatial criteria. > > Best regards, > -- > ---------------------------------------+-------------------------------- > ------ > I set the clouds in motion - turn up | Frank Warmerdam, > [EMAIL PROTECTED] > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush | President OSGeo, > http://osgeo.org > > _______________________________________________ > Geowanking mailing list > [email protected] > http://lists.burri.to/mailman/listinfo/geowanking > > > Warning: > Information provided via electronic media is not guaranteed against defects > including translation and transmission errors. If the reader is not the > intended recipient, you are hereby notified that any dissemination, > distribution or copying of this communication is strictly prohibited. If you > have received this information in error, please notify the sender immediately. > > _______________________________________________ > Geowanking mailing list > [email protected] > http://lists.burri.to/mailman/listinfo/geowanking > -- Now offering training and consulting in maximizing corporate efficiency using Web 2.0 tools and techniques. Rich Gibson Chief Scientist (and bottle washer), Locative Technologies http://mappinghacks.com http://geocoder.us http://testingrange.com AIM period3equals _______________________________________________ Geowanking mailing list [email protected] http://lists.burri.to/mailman/listinfo/geowanking
