[gdal-dev] GDAL/OGR 1.11.0 Release Candidate 1 available for testing

[Even Rouault]

Selon Wolf Bergenheim <wolf+grass at bergenheim.net>:

> On Thu, Apr 17, 2014 at 9:56 AM, Even Rouault
> <even.rouault at mines-paris.org>wrote:
>
> > Selon Wolf Bergenheim <wolf+grass at bergenheim.net>:
> >
> > > I just added a critical fix gor the GME driver that I'd like to get in to
> > > 1.11, so I merged it to the 1.11 branch. Soo technically this might
> > require
> > > a new RC, sorry for that!
> >
> > I'd like to kindly remind to GDAL committers that any commit worth to go
> > to a
> > branch must be accompanied by a ticket describing the problem being fixed,
> > and
> > the ticket number should be referenced in the commit message.
> >
> >
> Ah thx :)
>
>
> > Wolf, how "critical" is it to justify, by itself, a new RC ? It looks more
> > like
> > a new feature, no ? I guess that without the fix the driver is still
> > functional
> > but spatial filters are evaluated on client-side whereas with your commit,
> > they
> > are now evaluated server-side ? Nice to have, but can't that wait a .1
> > point
> > release ?
>
>
> I suppose, but the problem is that without it the whole thing becomes
> useless for large datasets (> 100k features) due to GME restrictions. I
> just thought that it would be good to have a GME driver that works on those
> large tables too. :)

The problem is that at some point we must take a snapshot and say "hey, this is
GDAL 1.11, the latest and greatest, use it please". I think it is OK if new
drivers are still a bit experimental.

Reviewing the commit, I think that it has at least one issue because
SetSpatialFilter() will segfault in switch( poGeomIn->getGeometryType() ) if
passed a NULL geometry, which is perfectly legal, in order to uninstall a
spatial filter.
Did you test the driver with the test_ogrsf utility ? (cd apps; make test_ogrsf)


>
> --Wolf
>