Ah, right, it’s exposed. Unfortunate, because it means that the OGC/ISO variant problem leaks into more external things than just WKB. I wonder how many people test dimensionality with getCoordinateDimension and how many do it with (wkb25DBit & getGeometryType()), no way to know unfortunately
P. -- Paul Ramsey http://cleverelephant.ca http://postgis.net On December 13, 2013 at 1:21:40 PM, Even Rouault (even.roua...@mines-paris.org) wrote: Le vendredi 13 décembre 2013 21:51:57, Paul Ramsey a écrit : > Actually, I think changing the contract on getGeometryType to only ever > returning the basic (non-3d) type would clean up driver implementation > code a bit. Grepping for it in the drivers, you see a lot of > > CPLAssert(wkbFlatten(poGeom->getGeometryType()) == wkbPoint) > > and > > || (poLine->getGeometryType() != wkbLineString > && poLine->getGeometryType() != wkbLineString25D) ) > > and very few unqualified calls to it. This would have impacts on drivers, but also on external code since OGR_G_GetGeometryType() is the C mapping of OGRGeometry::getGeometryType() There are also OGRGeomField::GetType(), OGRFeatureDefn::GetGeomType() and OGRLayer::GetGeomType() (and their C equivalents) that return wkbGeometryType. I imagine that if we change the contract of OGRGeometry::getGeometryType(), they should also behave similarly, for consistency. So we have a backward compatibility issue here, which must be carefully weighted in. > > P. > > -- > Paul Ramsey > http://cleverelephant.ca > http://postgis.net > > On December 13, 2013 at 12:00:34 PM, Paul Ramsey > (pram...@cleverelephant.ca) wrote: > > I’ve pushed up some work to do this > > https://github.com/pramsey/gdal/tree/isowkb > > I had to change *two* method signatures, which I don’t really like, both > exportToWkb and getGeometryType needed a variant parameter added. The > problem is that getGeometryType returns the full WKB type, with > dimensionality encoded, which makes it somewhat duplicative of > getCoordinateDimension. In an ideal world, getGeometryType would only > return the type number, and dimensionally information would be inferred > from getCoordinateDimension. > > Then only the exportToWkb signature would need a variant parameter. > > importFromWkb also was changed to ingest the ISO variant if that’s what > it’s fed. No changes to signature required there. > > P. > > -- > Paul Ramsey > http://cleverelephant.ca > http://postgis.net > > On December 12, 2013 at 2:58:05 PM, Even Rouault > (even.roua...@mines-paris.org) wrote: > > Le jeudi 12 décembre 2013 23:39:25, Paul Ramsey a écrit : > > I’ve been looking over the code, and I think I can make importFromWkb > > consume ISO inputs with relatively minor changes. (during the geometry > > type determination in the concrete types, it looks easy enough to add a > > little logic to deal with ISO type numbers) For exportToWkb, I’m > > wondering if maybe an optional parameter (wkbVariant?) that defaults to > > wkbVariantOGC would be sufficient? > > Sounds good to me. Is "wkbVariantOGC" the variant currently implemented ? > Is our 3D support really compliant with an OGC standard ? > > > 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. > > Are you sure about that ? > > See : > >>> from osgeo import ogr > >>> ogr.CreateGeometryFromWkb(g.ExportToWkb()).ExportToWkt() > > 'LINESTRING EMPTY' > > >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING > > EMPTY').ExportToWkb()).ExportToWkt() > 'LINESTRING EMPTY' > > >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('LINESTRING > > EMPTY').ExportToWkb()).ExportToWkt() > 'LINESTRING EMPTY' > > >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POLYGON > > EMPTY').ExportToWkb()).ExportToWkt() > 'POLYGON EMPTY' > > >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTILINESTRING > > EMPTY').ExportToWkb()).ExportToWkt() > 'MULTILINESTRING EMPTY' > > >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('MULTIPOLYGON > > EMPTY').ExportToWkb()).ExportToWkt() > 'MULTIPOLYGON EMPTY' > > >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('GEOMETRYCOLLECTION > > EMPTY').ExportToWkb()).ExportToWkt() > 'GEOMETRYCOLLECTION EMPTY' > > The only exception is POINT EMPTY due to the lack of wkb representation for > it > > >>> ogr.CreateGeometryFromWkb(ogr.CreateGeometryFromWkt('POINT > > EMPTY').ExportToWkb()).ExportToWkt() > 'POINT (0 0)' > > > Fortunately the only substantial difference for ISO WKB is the type > > number. > > > > 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. > > > > Then I’ll start asking about ‘m’ dimensions :) > > That's a fresh new land to explore... > > > P. > > > > -- > > Paul Ramsey > > http://cleverelephant.ca > > http://postgis.net > > > > On December 12, 2013 at 2:33:41 PM, Even Rouault > > (even.roua...@mines-paris.org) wrote: > > > > Le jeudi 12 décembre 2013 21:36:42, Paul Ramsey a écrit : > > > Hey all, > > > Is there already a facility for writing out ISO-standard WKB in GDAL? > > > The biggest difference is the wkbGeometryType number for the case of > > > 3d features. OGR currently uses the old extended SFSQL adopted by > > > PostGIS. ISO (naturally) did their own thing. As far as I can see, > > > there’s no support there now, or is there? P. > > > > Hi Paul, > > > > no, there's no support for ISO WKB yet. We still stick to > > http://home.gdal.org/projects/opengis/twohalfdsf.html > > > > I can imagine we could have exportToISOWkb() method in OGRGeometry*. Or > > we could add an extra boolean argument bISOWkb to the existing > > exportToWkb(). Not sure about WkbSize() : does the size of ISO WKB blobs > > differ from the unofficial WKB ? > > > > Even > > > > -- > > Geospatial professional services > > http://even.rouault.free.fr/services.html > > -- > Geospatial professional services > http://even.rouault.free.fr/services.html -- Geospatial professional services http://even.rouault.free.fr/services.html
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
