[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