[postgis-users] TIN support yes or no?

Martin Davis mbdavis at refractions.net
Mon Sep 22 14:10:06 PDT 2008


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




More information about the postgis-users mailing list