[gdal-dev] Call for discussion on RFC 49: Curve geometries

[Even Rouault]

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
> (even.rouault at spatialys.com) 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
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com