[postgis-users] TIN support yes or no?

[Martin Davis]

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
> 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
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022