[gdal-dev] Call for discussion on RFC 64: Triangle, Polyhedral surface and TIN
Even Rouault
even.rouault at spatialys.com
Wed Dec 7 02:09:03 PST 2016
> 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).
Yes that's indeed a limitation. A function to do the de-duplication and get an indexed
triangulation could be added later. We don't strictly need to store the ID (unless preserving
the actual value of the ID is needed ? if so, yes using M could be a workaround). The
deduplication can be done later by building a map from point coordinates to an integer index
while iterating over the geometries. The performance should be O(N*log(N)) where N is the
total number of vertices.
This RFC paves the ground for later functionalities, and in its current state, should already be
useful for exchanges between formats like PostGIS / GML / Shapefile.
>
> 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.
Actually TopoJSON is a bit of mixed topological format. Lines and polygons can use shared
arcs, but the vertices themselves are repeated among arcs that share the same vertices, so
you could have inconsistencies and checking for them is not immediate. See
https://github.com/topojson/topojson-specification
--
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20161207/0aaf63ff/attachment-0001.html>
More information about the gdal-dev
mailing list