[gdal-dev] ISO WKB

[Even Rouault]

Le mardi 17 décembre 2013 21:38:44, Dmitriy Baryshnikov a écrit :
> In this case, the
> 
> getXXXGeometryType()
> 
> is more logic, than
> 
> int getGeometryType(OGRwkbVariant eVariant) { return
> (eVariant == wkbVariantOgc) ? getGeometryType()  :
> getIsoGeometryType(); }

ah ok, I see your point. The idea was just a proposal to offer an helper method 
to avoid typing in the exportToWkb() of each geometry subclass :
 (eVariant == wkbVariantOgc) ? getGeometryType()  : getIsoGeometryType();

That getGeometryType(OGRwkbVariant eVariant) could be a protected method of 
OGRGeometry class, so that it remains an internal implementation detail. 

> 
> Best regards,
>      Dmitry
> 
> 18.12.2013 0:32, Even Rouault пишет:
> > Le mardi 17 décembre 2013 21:16:25, Dmitriy Baryshnikov a écrit :
> >> Hi,
> >> 
> >> I afraid that we come to situation where:
> >> 
> >> getGeometryType()
> >> getIsoGeometryType()
> >> getRFCGeometryType()
> >> ...
> >> getBlahBlahGeometryType()
> >> 
> >> Why not have only one method and only one enum (as GDAL origin - single
> >> abstract data model to the calling application for all supported
> >> formats). I think all ISO specific things should be internal and driver
> >> specific. So, we will get single GDAL enum of geom types.
> > 
> > I don't see it a problem if we have different getXXXGeometryType() or
> > exportToXXXX() methods in OGRGeometry, provided that they document well
> > the standard/document they implement. The ISO WKB encoding is a
> > standard, so it can be a legitimate interface of OGRGeometry, and could
> > potentially be used in several drivers ( actually if you look at
> > OGRSpatialReference class it has a lot of import / export methods to
> > various exotic formats, only used by one driver ).
> > 
> >> Best regards,
> >> 
> >>       Dmitry
> >> 
> >> 17.12.2013 18:09, Mateusz Loskot пишет:
> >>> On 17 December 2013 09:03, Even Rouault <even.rouault at mines-paris.org>
> > 
> > wrote:
> >>>> Selon Paul Ramsey <pramsey at cleverelephant.ca>:
> >>>>> Back to this, is it OK?
> >>>> 
> >>>> As said in
> >>>> http://lists.osgeo.org/pipermail/gdal-dev/2013-December/037738.html, I
> >>>> feel a bit unconfortable with the extension of the OGRwkbGeometryType
> >>>> enumeration that has possible impacts on other parts of OGR. There's
> >>>> perhaps a time where we will touch it, but I'd expect it to ideally
> >>>> embrace Z, M, ZM, circular geometries at once. And that would deserve
> >>>> a RFC.
> >>>> 
> >>>> What do you think of keeping it an internal enumeration of OGR, since
> >>>> that's probably all you need for now ?
> >>>> 
> >>>> "Or have a separate OGRwkbIsoGeometryType enumeration { wkbPointIso,
> >>>> ... wkbGeometryCollectionIso, wkbPointIsoZ, ...
> >>>> wkbGeometryCollectionIsoZ }, a getIsoGeometryType() method that
> >>>> returns it, and the exportToWkb() methods that calls int
> >>>> getGeometryType(OGRwkbVariant eVariant) { return (eVariant ==
> >>>> wkbVariantOgc) ? getGeometryType()  :
> >>>> getIsoGeometryType(); }"
> >>>> 
> >>>> I'd be happy to hear about other GDAL developers opinion on this.
> >>> 
> >>> IMHO, each format based on a particular spec/standard should be
> >>> supported with a separate interface (enum + functions)
> >>> per format/standard.
> >>> 
> >>> Best regards,

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html