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

[Paul Ramsey]

Super!

-- 
Paul Ramsey
http://cleverelephant.ca
http://postgis.net

On November 5, 2014 at 9:57:44 AM, Even Rouault (even.rouault at spatialys.com) 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  
> (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  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20141105/19a7e409/attachment-0001.html>