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.roua...@mines-paris.org> > > > > wrote: > >>>> Selon Paul Ramsey <pram...@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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev