[postgis-users] TIN support yes or no?

[Chris Hermansen]

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
> 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
>   


-- 
Regards,

Chris Hermansen         mailto:chris.hermansen at timberline.ca
tel+1.604.714.2878 · fax+1.604.733.0631 · mob+1.778.232.0644
Timberline Natural Resource Group · http://www.timberline.ca
401 · 958 West 8th Avenue  · Vancouver BC · Canada · V5Z 1E5