Some reasons why it might be interesting to consider alternative data
structures for TINs:
- there's a lot of overhead for storing individual triangles
- it's nice to have the topology of the TIN stored explicitly, and there
might be better ways to do this than in a pure relational schema
I can't think of any more efficient indexes than a standard spatial
index, but there might be something there.
On the other hand, trying to go beyond individual triangles seems like
it would be significantly more complex. For large volume datasets it
might be worth it, though.
I think Oracle might have done some rocket science in this area - it
might be worth looking at.
Chris Hermansen wrote:
My curiosity is getting the better of me.
Why not store the TIN as individual triangle polygons? Is there an
indexing strategy for looking up TIN triangles that's more efficient
than GIST-tree?
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
