Landon,
It depends on what you intend to do with the data. For
example, if it's your responsibility (i.e you are the
authoritative source) to maintain a parcel database, then
you might model the corners, boundaries, and parcels as
separate objects in separate tables, related by table
joins, with lots of schema-specific tools for maintaining
parcel lineage, boundary topology, and point coordinate
history, etc.
On the other hand, if you are a land use planner, never
edit the corners and just intend to use it as a "base"
layer, then pack the geometry into a single attribute, with
one row per parcel (and be prepared to get updates from the
authoritative source).
To go even further, if you never do queries on the
parcel attributes, then render all the parcel geometry to a
tiled raster and use it as a backdrop.
As others have pointed out, the main reason to go to a
simpler storage scheme is to improve query/render
performance. Or to quote Albert Einstein: "Make everything
as simple as possible, but not simpler." [than you need]
Excellent spatial data modeling question!
Brent Fraser
GeoAnalytic Inc.
Calgary, Alberta
----- Original Message -----
From: "Landon Blake" <[EMAIL PROTECTED]>
To: <[email protected]>
Cc: "Mark Dennehy" <[EMAIL PROTECTED]>
Sent: Friday, November 30, 2007 1:19 PM
Subject: RE: [Geowanking] Storing Simple Geometries in a
RDBMS Model
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
_______________________________________________
Geowanking mailing list
[email protected]
http://lists.burri.to/mailman/listinfo/geowanking
