[gdal-dev] ISO WKB

Dmitriy Baryshnikov bishop.dev at gmail.com
Tue Dec 17 12:16:25 PST 2013


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.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,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20131218/88505bc8/attachment.html>


More information about the gdal-dev mailing list