[gdal-dev] ISO WKB

[Paul Ramsey]

I've updated my working branch to match your intent more closely, I hope

https://github.com/pramsey/gdal/tree/isowkb

the iso enumeration is no longer there, and access to iso geometry
types is via a protected method only.

The reason I asked about GDAL2 is that some of the stuff in OGR seemed
new to me (multiple geometry columns, e.g.) and I thought that those
kinds of changes might be leading to a GDAL2 release.

P.

On Wed, Dec 18, 2013 at 1:20 AM, Even Rouault
<even.rouault at mines-paris.org> wrote:
> Le mercredi 18 décembre 2013 06:28:16, Paul Ramsey a écrit :
>> I don't think we should expose the ISO geometry types to the world,
>> they're just for WKB really, so I'll keep that part hidden away. It's
>> a shame we can't get rid of the 25d type variants for gdal2... if not
>> then, when?
>
> Ah, I didn't perceive you wanted to go that far. Well, that's certainly
> something that could be done for a GDAL 2. It would require a RFC to draw the
> battle plan and analyze the impacts.
>
>>
>> Incidentally, is there going to be a GDAL 1.11?
>
> Technically, at that point, no breaking changes have been done in trunk, so
> 1.11 would make sense as a version number.
>
> Even
>
>>
>> P.
>>
>> On Tue, Dec 17, 2013 at 1:50 PM, Even Rouault
>>
>> <even.rouault at mines-paris.org> wrote:
>> > Le mardi 17 décembre 2013 22:38:26, Paul Ramsey a écrit :
>> >> OK, so hide the ISO types from the outside world. No problem.
>> >>
>> >> Is it OK to have getGeometryType and exportToWkb accept wkbVariant
>> >> optional parameters?
>> >
>> > For exportToWkb(), it is just a matter of taste whether to add an
>> > optional parameter or to have a dedicated method.
>> >
>> > For getGeometryType(), as it returns a OGRwkbGeometryType, you can't add
>> > an optional parameter to return values other than OGRwkbGeometryType. My
>> > latest proposal was to have a - protected - "int
>> > getGeometryType(wkbVariant)  { return
>> > (eVariant == wkbVariantOgc) ? getGeometryType()  :
>> > getIsoGeometryType(); }" and a public OGRwkbIsoGeometryType
>> > getIsoGeometryType().
>> >
>> >> P.
>> >>
>> >> On Tue, Dec 17, 2013 at 1:03 AM, 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.
>> >> >
>> >> >> How are we patching back to SVN? I can convert
>> >> >> it into a patch and attach to a ticket, if that's the path.
>> >> >
>> >> > git-svn can be used to bridge the 2 worlds, but in my recent
>> >> > experience it has been painful to use. So generating a patch and
>> >> > applying it is probably easier.
>> >> >
>> >> > 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