[gdal-dev] ISO WKB

[Even Rouault]

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

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html