<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;">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… </div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">I feel like the best bet is to be consistent, but provide two consistent modes</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">- ISO mode, using the ISO defined type numbers for *all* types/dimensionalities</div><div id="bloop_customfont" style="margin: 0px;"><span style="color: rgb(0, 0, 0); font-family: Helvetica, Arial; font-size: 13px;">- Backwards/OGC mode, using the old </span>wkb25DBit mask for all types.</div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;">Of course, I could be wrong, maybe a snaggletooth is better, but it doesn’t pass the smell test for me</div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;">P.</div> <div id="bloop_sign_1415209065170563840" 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 7:01:32 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>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 geometry
<br>collections). It was modeled from the geometry class hierarchy of the
<br>"OpenGIS Simple Feature Access Part 1 : Common Architecture" (in its 1.1.0
<br>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 arcs,
<br> 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
<br> 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
<br> 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></div></div></span></blockquote></body></html>