[postgis-devel] Polyhedral, 3d and distance

[Olivier Courtin]

On Aug 10, 2010, at 10:31 AM, Nicklas Avén wrote:

Nicklas,

> Ok, but maybe as you comment yourself maybe TIN is a better choice for
> land shape and aim on polyhedral use for buildings.

Well i really don't think landscape should have to be put into database.
They don't have attributes, so they're not really features...

And if someone do, he will got a single huge geometry.
So got performance issue.

But TIN are not only DEM and could be used (also) for building
modelisation.
In fact COLLADA (so Google Earth) deal with TIN

A perfect model for BIM is to support fully ISO 19107 with solids
and 3D related topology.
But right now still no spatial database spec handle it.
And furthermore no such open source geometric libs...

So for now PolyhedralSurface and TIN could be a first step in 3D  
world...


> I think assumptions like that should affect our strategy quite a lot.
> Because if so the polyhedral cases will be quite simple mostly with
> horizontal and and vertical walls.
>
> Then there might also be no gain in searching for shortcuts in
> distance-calculations because most polyhedral geometries will only  
> have
> 4 walls and each wall containing 4 corners. In that case I think the
> overhead cost to do precalculations might be bigger than the gain. But
> if we aim on usage with big and complex polygons and a lot of faces,
> then there might be interesting approaches.

On CityGML LOD 2, geometry are usually not 'that' complex.
But often more complex than only 4 faces ;)

> I think we then should load the geometries into special structures
> before doing the calculations. In the structure there should be the
> plane defined in a solid way. Like three representive points or by an
> equation. So we don't have to deal with that problem many times in te
> same calculation. The structure should also contain the 3d bounding  
> box
> and maybe the center of it. Then I think we have a good start for
> finding shortcuts in the calculations.

Don't forget that PolyhedralSurface could be either 2D or 3D...


For information 2 good books on such a subject,
(both from Morgan Kaufmann):
- Real Time Collision Detection - Christer Ericson
- Geometric tools for computer graphics - Scheider & Eberly


>>> The point is that the central part of this is the plane. How to
>>> handle that if the points
>>> are not exactly on the same plane.
>>
>> It have to be coplanar 'enough'.
>> As they will (quite) never be strictly coplanar.
>>
>
> We need a solid way to determine the plane as good as possible.
> There is applications only caring about the integer part of the
> coordinates. I guess the functions will have to deal with that too.  
> Then
> the error is not just on the last decimals but can be half a meter.

I this case the geometry will simply not be declared as valid.
We could (try to) deal with numerical imprecision, not with  
significant errors :)

But as in 2D right now, you could perfectly store invalid data inside  
PostGIS.

> What about the internal topology inside a polyhedral or a TIN. Is  
> there
> any ways of just storing each vertex once like the vertexes connecting
> the faces and then referencing the vertexes in some way? The gain  
> should
> be primary topological robustness and maybe it could give performance
> gain too.


It's usefull for compliancy with some existant postgis functions to  
have a naive
geometry spaghetti approach.

But you're right it  will also become a good thing to have for some  
spatial analysis
a topological model available beneath.

For PolyhedralSurface a good paper to explain main differences between
available topological model:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5436

--
Olivier