I would add:
- specification of a abstract data model which allows optimization of
storage and querying to take place without affecting client code
Hmmm... sounds like all the same reasons why someone might want to store
rasters in a database... 8^)
Burgholzer,Robert wrote:
I think this is very interesting as well. Why store "TIN structure in a
database"?? On the surface, I think that it is reasonable to say, for
the same reason that you store anything other than strings and floats in
a database? The answer is so that you can have robust access to query
logic, independent of a specific file system, integrated with SQL, and
in the case of TIN's, potentially exploitable via geo-processing
queries. This would offer a very powerful advantage.
In many cases, the TIN can be a substitute for raster data, a highly
efficient one (not in all cases of course). For terrain modelers, this
could be fantastic.
$0.02,
r.b.
Robert W. Burgholzer
Surface Water Modeler
Office of Water Supply and Planning
Virginia Department of Environmental Quality
[EMAIL PROTECTED]
804-698-4405
Open Source Modeling Tools:
http://sourceforge.net/projects/npsource/
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Kevin Neufeld
Sent: Monday, September 22, 2008 4:27 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] TIN support yes or no?
Courtin Olivier wrote:
On Sep 20, 2008, at 6:44 PM, Paul Ramsey wrote:
Paul,
and I have a hard time reconciling that to the
real use-case needs of TIN-in-database (really large,
region-spanning,
billion-face TINs).
Well, why want to store such kind of TIN structure into a database ?
:)
So one doesn't have to recompute a surface repeatedly. I'm currently
working on a project where I need to build up a surface model on a
provincial scale, computing the overlay of streams and other
hydrographic features. Since I only have the resources to build a small
portion of the entire surface at a time, I'm forced to generate a very
small surface, and with a large buffered area, slowly pan over the
entire province, thus generating the TIN in the overlapping buffered
areas repeatedly (estimated to take a total time 1200 CPU hours).
Having a reusable TIN stored in the database is rather appealing.
This is of particular interest: streaming TIN generation - nice!
http://www.cs.unc.edu/~isenburg/papers/ilsst-tin2dem-06.pdf
Cheers,
Kevin
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
