<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Super!</div> <div id="bloop_sign_1415210648408752896" class="bloop_sign">

        <title></title>

        <div>

            <br>

        </div>

        -- <br>

        Paul Ramsey<br>

        http://cleverelephant.ca<div>http://postgis.net

</div>

<script type="application/ld+json">

{

  "@context": "http://schema.org",

  "@type": "em",

  "name": "John Doe",

  "jobTitle": "Graduate research assistant",

  "affiliation": "University of Dreams",

  "additionalName": "Johnny",

  "url": "http://www.example.com",

  "address": {

    "@type": "PostalAddress",

    "streetAddress": "1234 Peach Drive",

    "addressLocality": "Wonderland",

    "addressRegion": "Georgia"

  }

}

</script>

</div> <br><p style="color:#000;">On November 5, 2014 at 9:57:44 AM, Even Rouault (<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>Paul,

<br>

<br>Thanks for your remarks

<br>

<br>> My only concern/note here is with regard to the WKB type numbers for

<br>> features with a Z. The RFC seems to say that the numbers for the curve

<br>> types will be ISO numbers, while the numbers for the old SFS types will be

<br>> the backwards compatible ones. This puts OGR into an ugly snaggletooth

<br>> situation, where the WKB emitted is not really consistent. In some ways

<br>> it’s worse than PostGIS…  

<br>

<br>The RFC text might be not clear enough. Actually this is just for the OGR  

<br>enumeration. When emitting WKB with wbkIsoVariant, fully compliant ISO SQL/MM  

<br>Part3 / SFA 1.2.1 is emitted. That's how I can be compatible with PostGIS 2  

WKB/EWKB.

<br>Said otherwise, there's a decoupling between the values used in the OGR  

<br>enumeration and what is emitted by exportToWkb()

<br>

<br>>  

<br>> I feel like the best bet is to be consistent, but provide two consistent

<br>> modes

<br>>  

<br>> - ISO mode, using the ISO defined type numbers for *all*

<br>> types/dimensionalities - Backwards/OGC mode, using the old wkb25DBit mask

> for all types.

<br>

<br>- exportToWkb(wkbIsoVariant) emits compliant ISO SQL/MM Part3 / SFA 1.2.1 for  

<br>all geometries

<br>- exportToWkb(wkbVariantOldOgc) use the wkb25DBit for the "old" geometries,  

<br>and ISO SQL/MM Part3 / SFA 1.2.1 for the new one. This is admitedly a bit odd.  

<br>We could use the wkb25Dbit trick for the new geometries, but I didn't see the  

<br>point. Although that wouldn't be a huge deal to continue using th wkb25DBit  

for them too. Would be perhaps clearer.

<br>- exportToWkb(wkbVariantPostGIS1) uses the wkb25DBit for all geometry types,  

and uses PostGIS 1.X codes for CurvePolygon, MultiCurve and MultiSurface.

<br>

<br>Even

<br>

<br>>  

<br>> --  

<br>> Paul Ramsey

<br>> http://cleverelephant.ca

<br>> http://postgis.net

<br>>  

<br>> On November 5, 2014 at 7:01:32 AM, Even Rouault

<br>> (even.rouault@spatialys.com) wrote:

<br>>  

<br>> Hi,

<br>>  

<br>> This is a call for discussion on RFC 49: Curve geometries

<br>>  

<br>> http://trac.osgeo.org/gdal/wiki/rfc49_curve_geometries

<br>>  

<br>> Below the summary :

<br>> """

<br>> The current geometry model in GDAL 1.X makes use of points, lines, polygons

<br>> and aggregations of them (multipoints, multilines, multipolygons and

<br>> geometry collections). It was modeled from the geometry class hierarchy of

<br>> the "OpenGIS Simple Feature Access Part 1 : Common Architecture" (in its

<br>> 1.1.0 version).

<br>>  

<br>> This RFC covers the addition of new geometry types that have been added in

<br>> ISO/IEC 13249 Part 3 Spatial (abreviated as ISO SQL/MM Part 3):

<br>> * circular string: a circular arc, or a sequence of connected circular

<br>> arcs, each of them describe by 3 points: the first point of the arc, an

<br>> intermediate point and the final point

<br>> * compound curve: a sequence of connected curves, either line strings or

<br>> circular strings

<br>> * curve polygon: polygon consisting of one outer ring, and zero or more

<br>> inner ring. Each ring can be one of the curve implementations: line

> strings, circular strings, compound curves.

<br>> * multicurve: a collection of curves (line strings, circular strings,

<br>> compound curves)

<br>> * multisurface: a collection of surfaces (polygons, curve polygons)

<br>>  

<br>> The scope of this RFC consists in :

<br>> * adding the new geometry classes to the existing geometry class hierarchy,

<br>> with the corresponding importer and exporter of WKT (Well Known Text) and

<br>> WKB (Well Known Binary) encodings

<br>> * adding methods to convert those curve geometries into their approximated

<br>> linear version, and to do the reverse operation

<br>> * upgrading some of the drivers that can support such geometries : GML (and

> indirectly NAS, WFS), PostGIS/PGDump, GeoPackage, SQLite, CSV, VRT.

<br>> """

<br>>  

<br>> Have a good reading,

<br>>  

<br>> Even

<br>>  

<br>> --

<br>> Spatialys - Geospatial professional services

<br>> http://www.spatialys.com

<br>> _______________________________________________

<br>> gdal-dev mailing list

<br>> gdal-dev@lists.osgeo.org

<br>> http://lists.osgeo.org/mailman/listinfo/gdal-dev

<br>

<br>--  

<br>Spatialys - Geospatial professional services

<br>http://www.spatialys.com

<br></div></div></span></blockquote></body></html>