[gdal-dev] Call for discussion on RFC 64: Triangle, Polyhedral surface and TIN

[Michael Sumner]

On Wed, 7 Dec 2016 at 07:41 Even Rouault <even.rouault at spatialys.com> wrote:

> On mardi 6 décembre 2016 20:31:57 CET Michael Sumner wrote:
>
> > Thanks Even,
>
> >
>
> > Does a TriangulatedSurface consist of separate Triangles, all with each
>
> > three vertices stored explicitly? I.e. is there no shared vertex pool
> that
>
> > primitives use via index?
>
>
>
> Yes, the TriangulatedSurface is a collection of separate triangles. No
> smart optimization here. We stick to the simple features model.
>
>
>
> >
>
> > That seems to be what simple features dictates, but it's unclear to me
> how
>
> > applications should work with it. Is vertex de-duplication to be be done
> at
>
> > each conversion, or is there a way to carry those indexes through?
>
>
>
> Apart from shapefile/filegdb triangle strip/fan that could be considered
> as a kind of vertex indexing, the WKT/WKB representation (and thus the
> exchanges with PostGIS) don't have that.
>
>
>
> Actually you could retrieve an indexed view of the TIN by using the
> GDALTriangulationCreateDelaunay() API
>
> ( http://www.gdal.org/gdal__alg_8h.html#a498205ae5f4f0ec9f43e5c65bb392060
> ), although it is a bit overkill to recompute a triangulation from a set of
> triangles... (and the triangulation it will return will generally not be
> the original one)
>
>
>

Thanks Even, I was thinking of preserving an indexed mesh, with (for
example) a constrained triangulation. Simple features will ingest this, but
once it comes back out vertex de-duplication would be enough to restore the
indexing. You'd need some record of vertex identity after they are expanded
out on each triangle, but there's no internal way to ID them in simple fs
(except maybe by using M).

I feel that simple features is not particularly useful in this regard,
though fine as a one-way output from triangulation sources. I think
TopoJSON is similar, in that all vertices are explict, there's no index
-but because they are all integer-scaled in the context of the graph,
there's no numerical difficulties with uniqueness.  Interested to hear
other views, though appreciate that this is pretty off-topic.

Cheers, Mike.




> Even
>
>
>
> >
>
> > Cheers, Mike
>
> >
>
> > On Wed, Dec 7, 2016, 03:22 Even Rouault <even.rouault at spatialys.com>
> wrote:
>
> > > Hi,
>
> > >
>
> > >
>
> > >
>
> > > This is a call to discuss the proposed RFC 64: Triangle, Polyhedral
>
> > > surface and TIN
>
> > >
>
> > >
>
> > >
>
> > > https://trac.osgeo.org/gdal/wiki/rfc64_triangle_polyhedralsurface_tin
>
> > >
>
> > >
>
> > >
>
> > > ~~~~~
>
> > >
>
> > >
>
> > >
>
> > > Summary:
>
> > >
>
> > >
>
> > >
>
> > > As of now, the OGRGeometry class (the base class from which all the
>
> > > subtypes are derived) is limited to OGRCompoundCurve,
> OGRCircularString,
>
> > > OGRLinearRing, OGRMultiLineString, OGRMultiPoint, OGRMultiPolygon,
>
> > > OGRMultiCurve, OGRSimpleCurve, OGRCurvePolygon and OGRPolygon.
>
> > >
>
> > >
>
> > >
>
> > > This RFC addresses the addition of the following new geometries in
>
> > > OGRGeometry:
>
> > >
>
> > > * Triangle - A subset of polygons, the fundamental difference is that
> it
>
> > > is made of 3 nodes only (actually 4, with the last one being the
>
> > > repetition
>
> > > of the first one) and ONLY ONE exterior boundary and NO interior
> polygons.
>
> > >
>
> > > * PolyhedralSurface - A 3D figure made exclusively of Polygons.
>
> > >
>
> > > * TriangulatedSurface - A subset of PolyhedralSurface; a 3D figure
> which
>
> > > consists exclusively of Triangles.
>
> > >
>
> > >
>
> > >
>
> > > ~~~~~
>
> > >
>
> > >
>
> > >
>
> > > I've rebased and extended the work done by Avyav during last GSoc on
> top
>
> > > of current trunk, where it passes our continuous integration tests. I
>
> > > think
>
> > > we should consider merging it soon as it can easily rot if kept longer
> in
>
> > > a
>
> > > branch (the refresh from my previous branch dating to end of August was
>
> > > rather painful)
>
> > >
>
> > >
>
> > >
>
> > > Even
>
> > >
>
> > >
>
> > >
>
> > > --
>
> > >
>
> > > Spatialys - Geospatial professional services
>
> > >
>
> > > http://www.spatialys.com
>
> > > _______________________________________________
>
> > > gdal-dev mailing list
>
> > > gdal-dev at lists.osgeo.org
>
> > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
-- 
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20161207/f9108e1f/attachment.html>