Change History (14)

I wrote code years ago in C that would take a cloud of 3D points insert them into a Delaunay triangular surface, then slice the surface triangles with a plane(s) into intersecting edges and then composite rings from the edges. It seems like we are very close to being able to do this in PostGIS. I'm not sure if we have the Delaunay triangularization yet.

So I'm thinking of something like this is the use case, where this would create contour rings for Z at 2, 4, 6, 8, and 10 based on the triangulated surface created from the points. My SQL is probably broken, but it is only to present the idea.

This use case is very broad in its applicability to real world cases. Think of the points as XY as in location of a sensor or some other point of measurement and the Z as the measurement value. Creating a 3D triangulated surface and cutting it with z-planes creates contours of equal value results. Create a vertical plane(s) and you are generating elevation profiles. and if you have 2d path like a bicycle route, a GPS track, etc and extrude that into a vertical panel the intersects the surface, you intersection becomes the measurement profile of the path. If the surface is elevation, then you have an elevation profile, if the measurement was chemical concentrations in a water body and the track is fish, then the profile because an exposure profile for the fish.

So some use cases of this are:

driving distance - compute the costs to the node using Dijkstra and the XY is the node location and Z is the cost.

XY location, Z=altitude, height contours one of the more obvious cases

And I think that being able to build a pipeline of functions like I offered above would be extremely useful. in all of these use cases.

While I do not need it specifically at the moment, anyone trying to render 3D landscapes might want to be able to extract the triangles or might want to be able to apply hillshading to the the triangulated surface and create a postGIS raster as a result. For the hillshading task I believe they would like to get the average normal at the each triangle node, this is needed for both Gouraud and Phong shading algorithms, being able to extract that might be of interest in the future.

News from the GEOS side of things: the C++ port is ready in trunk (to become 3.4.0) and it's now time to expose it trough the C-API. Reading the C++ interface there are 2 possible outputs: a collection of lines or a collection of polygons. The former is smaller, and I guess you could form the latter by passing the former to ST_Polygonize.

So I ended up exposing an API which allows both collection-of-polygons and multlinestring outputs, so it only needs to be decided how to access the functionality from postgis.
How should the function look like to request one or the other, and what should the default be (if any).

where the function returns a set of geometries based on multilinestring_out flag. If true you get multilinestrings if false or absent you get polygons. You mentioned a tolerance so I tossed that in, but what is it for?

I like the set returning function because it is easy to throw ST_Collection() around it if you want a collection but much harder to explode it is you do not want that and it support your idea of pipelining.