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.
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,
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
