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
