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 <[email protected]> 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 >> >> <[email protected]> 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 >> >> >> >> <[email protected]> wrote: >> >> > Selon Paul Ramsey <[email protected]>: >> >> >> 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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
