Selon Wolf Bergenheim <[email protected]>: > On Thu, Apr 17, 2014 at 9:56 AM, Even Rouault > <[email protected]>wrote: > > > Selon Wolf Bergenheim <[email protected]>: > > > > > 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 > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
