Le jeudi 19 décembre 2013 00:50:06, Paul Ramsey a écrit : > 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.
Yes, looks good (except some generated files that accidently were committed). > > 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. There are a lot of possible ideas for a GDAL 2 ( http://trac.osgeo.org/gdal/wiki/GDAL20Changes ). Multiple geometry columns is indeed a recent addition ( http://trac.osgeo.org/gdal/wiki/rfc41_multiple_geometry_fields ), but it doesn't break the C API. To tag a GDAL 2, we would probably need something more disruptive (although hopefully not too disruptive !) since GDAL 2 will sound to people's hears : "ah, maybe I have to adapt my code that has worked for the last past 10 years" Not sure when this will happen... > > 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 -- Geospatial professional services http://even.rouault.free.fr/services.html _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
