[postgis-users] TIN support yes or no?

[Burgholzer,Robert]

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
rwburgholzer at deq.virginia.gov
804-698-4405
Open Source Modeling Tools:
http://sourceforge.net/projects/npsource/

-----Original Message-----
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] 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
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users