<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;">Ah, right, it’s exposed. </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;">Unfortunate, because it means that the OGC/ISO variant problem leaks into more external things than just WKB.</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 wonder how many people test dimensionality with getCoordinateDimension and how many do it with (wkb25DBit & getGeometryType()), no way to know unfortunately</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;">P.</div> <div id="bloop_sign_1386970091770062848" class="bloop_sign"><div><br></div><span style="font-family:helvetica,arial;font-size:13px"></span>-- <br>Paul Ramsey<br>http://cleverelephant.ca<div>http://postgis.net</div></div> <br><p style="color:#A0A0A8;">On December 13, 2013 at 1:21:40 PM, Even Rouault (<a href="mailto://even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div>Le vendredi 13 décembre 2013 21:51:57, Paul Ramsey a écrit :

<br>> Actually, I think changing the contract on getGeometryType to only ever

<br>> returning the basic (non-3d) type would clean up driver implementation

<br>> code a bit. Grepping for it in the drivers, you see a lot of

<br>>  

<br>> CPLAssert(wkbFlatten(poGeom->getGeometryType()) == wkbPoint)

<br>>  

<br>> and

<br>>  

<br>>    || (poLine->getGeometryType() != wkbLineString

<br>>     && poLine->getGeometryType() != wkbLineString25D) )

<br>>  

> and very few unqualified calls to it.

<br>

<br>This would have impacts on drivers, but also on external code since  

<br>OGR_G_GetGeometryType() is the C mapping of OGRGeometry::getGeometryType()

<br>

<br>There are also OGRGeomField::GetType(), OGRFeatureDefn::GetGeomType() and  

<br>OGRLayer::GetGeomType() (and their C equivalents) that return wkbGeometryType.  

<br>I imagine that if we change the contract of OGRGeometry::getGeometryType(),  

they should also behave similarly, for consistency.

<br>

<br>So we have a backward compatibility issue here, which must be carefully  

weighted in.

<br>

<br>>  

<br>> P.

<br>>  

<br>> --  

<br>> Paul Ramsey

<br>> http://cleverelephant.ca

<br>> http://postgis.net

<br>>  

<br>> On December 13, 2013 at 12:00:34 PM, Paul Ramsey

<br>> (pramsey@cleverelephant.ca) wrote:

<br>>  

<br>> I’ve pushed up some work to do this

<br>>  

<br>> https://github.com/pramsey/gdal/tree/isowkb

<br>>  

<br>> I had to change *two* method signatures, which I don’t really like, both

<br>> exportToWkb and getGeometryType needed a variant parameter added. The

<br>> problem is that getGeometryType returns the full WKB type, with

<br>> dimensionality encoded, which makes it somewhat duplicative of

<br>> getCoordinateDimension. In an ideal world, getGeometryType would only

<br>> return the type number, and dimensionally information would be inferred

<br>> from getCoordinateDimension.

<br>>  

> Then only the exportToWkb signature would need a variant parameter.

<br>>  

<br>> importFromWkb also was changed to ingest the ISO variant if that’s what

> it’s fed. No changes to signature required there.

<br>>  

<br>> P.

<br>>  

<br>> --  

<br>> Paul Ramsey

<br>> http://cleverelephant.ca

<br>> http://postgis.net

<br>>  

<br>> On December 12, 2013 at 2:58:05 PM, Even Rouault

<br>> (even.rouault@mines-paris.org) wrote:

<br>>  

<br>> Le jeudi 12 décembre 2013 23:39:25, Paul Ramsey a écrit :

<br>> > I’ve been looking over the code, and I think I can make importFromWkb

<br>> > consume ISO inputs with relatively minor changes. (during the geometry

<br>> > type determination in the concrete types, it looks easy enough to add a

<br>> > little logic to deal with ISO type numbers) For exportToWkb, I’m

<br>> > wondering if maybe an optional parameter (wkbVariant?) that defaults to

<br>> > wkbVariantOGC would be sufficient?

<br>>  

> Sounds good to me. Is "wkbVariantOGC" the variant currently implemented ?

> Is our 3D support really compliant with an OGC standard ?

<br>>  

<br>> > It also seems the wkb reader/writer have little handling for empty

> > geometry types. I’d like to add some in, if that’s OK.

<br>>  

> Are you sure about that ?

<br>>  

<br>> See :

<br>> >>> from osgeo import ogr

<br>> >>> ogr.CreateGeometryFromWkb(g.ExportToWkb()).ExportToWkt()

<br>>  

<br>> 'LINESTRING EMPTY'

<br>>  

<br>> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING

<br>>  

<br>> EMPTY').ExportToWkb()).ExportToWkt()

<br>> 'LINESTRING EMPTY'

<br>>  

<br>> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING

<br>>  

<br>> EMPTY').ExportToWkb()).ExportToWkt()

<br>> 'LINESTRING EMPTY'

<br>>  

<br>> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POLYGON

<br>>  

<br>> EMPTY').ExportToWkb()).ExportToWkt()

<br>> 'POLYGON EMPTY'

<br>>  

<br>> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTILINESTRING

<br>>  

<br>> EMPTY').ExportToWkb()).ExportToWkt()

<br>> 'MULTILINESTRING EMPTY'

<br>>  

<br>> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTIPOLYGON

<br>>  

<br>> EMPTY').ExportToWkb()).ExportToWkt()

<br>> 'MULTIPOLYGON EMPTY'

<br>>  

<br>> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('GEOMETRYCOLLECTION

<br>>  

<br>> EMPTY').ExportToWkb()).ExportToWkt()

<br>> 'GEOMETRYCOLLECTION EMPTY'

<br>>  

<br>> The only exception is POINT EMPTY due to the lack of wkb representation for

<br>> it

<br>>  

<br>> >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POINT

<br>>  

<br>> EMPTY').ExportToWkb()).ExportToWkt()

<br>> 'POINT (0 0)'

<br>>  

<br>> > Fortunately the only substantial difference for ISO WKB is the type

<br>> > number.

<br>> >  

<br>> > I’m starting an isowkb branch on my git repo to hold this piece of work,

> > I don’t think it’ll be very big.

<br>> >  

<br>> > Then I’ll start asking about ‘m’ dimensions :)

<br>>  

> That's a fresh new land to explore...

<br>>  

<br>> > P.

<br>> >  

<br>> > --

<br>> > Paul Ramsey

<br>> > http://cleverelephant.ca

<br>> > http://postgis.net

<br>> >  

<br>> > On December 12, 2013 at 2:33:41 PM, Even Rouault

<br>> > (even.rouault@mines-paris.org) wrote:

<br>> >  

<br>> > Le jeudi 12 décembre 2013 21:36:42, Paul Ramsey a écrit :

<br>> > > Hey all,

> > > Is there already a facility for writing out ISO-standard WKB in GDAL?

<br>> > > The biggest difference is the wkbGeometryType number for the case of

<br>> > > 3d features. OGR currently uses the old extended SFSQL adopted by

<br>> > > PostGIS. ISO (naturally) did their own thing. As far as I can see,

<br>> > > there’s no support there now, or is there? P.

<br>> >  

<br>> > Hi Paul,

<br>> >  

<br>> > no, there's no support for ISO WKB yet. We still stick to

<br>> > http://home.gdal.org/projects/opengis/twohalfdsf.html

<br>> >  

<br>> > I can imagine we could have exportToISOWkb() method in OGRGeometry*. Or

<br>> > we could add an extra boolean argument bISOWkb to the existing

<br>> > exportToWkb(). Not sure about WkbSize() : does the size of ISO WKB blobs

<br>> > differ from the unofficial WKB ?

<br>> >  

<br>> > Even

<br>> >  

<br>> > --

<br>> > Geospatial professional services

<br>> > http://even.rouault.free.fr/services.html

<br>>  

<br>> --

<br>> Geospatial professional services

<br>> http://even.rouault.free.fr/services.html

<br>

<br>--  

<br>Geospatial professional services

<br>http://even.rouault.free.fr/services.html

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