Super! -- Paul Ramsey http://cleverelephant.ca http://postgis.net
On November 5, 2014 at 9:57:44 AM, Even Rouault ([email protected]) wrote: Paul, Thanks for your remarks > My only concern/note here is with regard to the WKB type numbers for > features with a Z. The RFC seems to say that the numbers for the curve > types will be ISO numbers, while the numbers for the old SFS types will be > the backwards compatible ones. This puts OGR into an ugly snaggletooth > situation, where the WKB emitted is not really consistent. In some ways > it’s worse than PostGIS… The RFC text might be not clear enough. Actually this is just for the OGR enumeration. When emitting WKB with wbkIsoVariant, fully compliant ISO SQL/MM Part3 / SFA 1.2.1 is emitted. That's how I can be compatible with PostGIS 2 WKB/EWKB. Said otherwise, there's a decoupling between the values used in the OGR enumeration and what is emitted by exportToWkb() > > I feel like the best bet is to be consistent, but provide two consistent > modes > > - ISO mode, using the ISO defined type numbers for *all* > types/dimensionalities - Backwards/OGC mode, using the old wkb25DBit mask > for all types. - exportToWkb(wkbIsoVariant) emits compliant ISO SQL/MM Part3 / SFA 1.2.1 for all geometries - exportToWkb(wkbVariantOldOgc) use the wkb25DBit for the "old" geometries, and ISO SQL/MM Part3 / SFA 1.2.1 for the new one. This is admitedly a bit odd. We could use the wkb25Dbit trick for the new geometries, but I didn't see the point. Although that wouldn't be a huge deal to continue using th wkb25DBit for them too. Would be perhaps clearer. - exportToWkb(wkbVariantPostGIS1) uses the wkb25DBit for all geometry types, and uses PostGIS 1.X codes for CurvePolygon, MultiCurve and MultiSurface. Even > > -- > Paul Ramsey > http://cleverelephant.ca > http://postgis.net > > On November 5, 2014 at 7:01:32 AM, Even Rouault > ([email protected]) wrote: > > Hi, > > This is a call for discussion on RFC 49: Curve geometries > > http://trac.osgeo.org/gdal/wiki/rfc49_curve_geometries > > Below the summary : > """ > The current geometry model in GDAL 1.X makes use of points, lines, polygons > and aggregations of them (multipoints, multilines, multipolygons and > geometry collections). It was modeled from the geometry class hierarchy of > the "OpenGIS Simple Feature Access Part 1 : Common Architecture" (in its > 1.1.0 version). > > This RFC covers the addition of new geometry types that have been added in > ISO/IEC 13249 Part 3 Spatial (abreviated as ISO SQL/MM Part 3): > * circular string: a circular arc, or a sequence of connected circular > arcs, each of them describe by 3 points: the first point of the arc, an > intermediate point and the final point > * compound curve: a sequence of connected curves, either line strings or > circular strings > * curve polygon: polygon consisting of one outer ring, and zero or more > inner ring. Each ring can be one of the curve implementations: line > strings, circular strings, compound curves. > * multicurve: a collection of curves (line strings, circular strings, > compound curves) > * multisurface: a collection of surfaces (polygons, curve polygons) > > The scope of this RFC consists in : > * adding the new geometry classes to the existing geometry class hierarchy, > with the corresponding importer and exporter of WKT (Well Known Text) and > WKB (Well Known Binary) encodings > * adding methods to convert those curve geometries into their approximated > linear version, and to do the reverse operation > * upgrading some of the drivers that can support such geometries : GML (and > indirectly NAS, WFS), PostGIS/PGDump, GeoPackage, SQLite, CSV, VRT. > """ > > Have a good reading, > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
