> 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
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
