[gdal-dev] ISO WKB

[Paul Ramsey]

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.rouault at 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  
> (pramsey at 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.rouault at 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.rouault at 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  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20131213/ee10c9ea/attachment.html>