[postgis-devel] PostGIS 3D - Points to be discussed

Hugo Mercier hugo.mercier at oslandia.com
Mon Feb 4 07:50:42 PST 2013


Hallo Nicklas,

Le 04/02/2013 00:09, Nicklas Avén a écrit :
> Hallo Olivier and Hugo
>
> First about solids. I am still confused. What tells if a closed
> polyhedral surface is a surface or a solid?
>

There is a 'flag' field within the LWGEOM structure (and GSERIALIZED as 
well). It is not broadly used, but it is here. Setting this flag on says 
the polyhedral surface must be considered as a solid. (If the polyhedral 
is open, it is not valid).

This is not exported to WKB/WKT, but exists when PostGIS functions are 
called (through GSERIALIZED). SFCGAL supports it. You can for instance 
use the 'sfcgal.ST_MakeSolid' function to turn a Polyhedral surface into 
a Solid and apply algorithms on volumes rather than on surfaces.

We alos support 'SOLID' type in WKT. Maybe we should consider extending 
WKB with such a solid support.
If something has to be modified in PostGIS regarding solids, I would 
vote for a whole new 'Solid' type which would also carry interior shells 
(which is not possible for now with a simple flag).

> Next about planes.
>
> When I wrote the distance code for 3D I was struggling some with how to
> handle tha plane of a surface. If there is more than three 3D points
> defining a plane it will in most cases not be coplanar caused by
> precision errors.
> Maybe we should consider a WKB/WKT extension to support SOLID
> Then no matter how good the algorithm is for calculating the distances,
> the answer will not be exact since the stored points defining the
> surface is not coplanar.
>
> In the 3D distance calculations in PostGIS today some average plane is
> calculated. But if it is a need for exact distance values I guess that
> will be a problem.

We faced a similar problem when we had to compute normals of an 
arbitrary polygon. We used the Newell's formula, which is a least 
squares fit.

>
>
>
> I can only see two ways around that to really get exact calculations.
>
> 1) store some definition of the plane in the geometry
> 2) define 3 points in the geometry that defines the plane. The rest of
> the points is regarded as 2D points.
>
> In the second way of doing it the 2D points will not always be xy points
> but xy, xz and yz points depending on the plane.
>

I am not sure to understand the second way. Can you provide some example ?

CGAL has no direct support for distance 3D functions. Our distance3D 
method is for now quite simple. We decompose the geometry using 
triangulation and compute distance to triangles.

-- 
Hugo Mercier
Oslandia



More information about the postgis-devel mailing list