On 04/25/2012 04:31 PM, Even Rouault wrote:
Hum, I'm surprised that it has survived your testing ;-) : GetSpatialFilter() might return NULL (in fact, in the general case, it will), so GetSpatialFilter()->clone() should segfault.
Fixed
CPLMalloc() cannot return NULL. Internally, it will abort if the memory allocation failed. So you can just remove the if (!mapInput) // if (!mapMethod) tests afterwards, or use VSIMalloc() instead. For consistency, memory allocated with CPLMalloc()/VSIMalloc() should be freed with CPLFree()/VSIFree(), and not free(). (There's an alternate memory allocator that does consistency checking that can be enabled by defining #define DEBUG_VSIMALLOC in port/cpl_vsisimple.cpp)
I changed to using VSIMalloc and VSIFree. Also fixed the case when there are no fields. BTW, there are still some memory allocations (new objects) that are not checked.
For the final implementation, the new methods that are the object of the RFC will need Doxygen doc.
to be done
I don't see a strong reason to publish OGR_F_SetFieldsFromWithMap() in the C API. This is mostly usefull for internal purposes for now.
Removed
About SetFieldsFrom(), it also changes SetFID() and SetStyleString(). This is a bit counter-intuitive. It will be indeed interesting to make SetFeatureFrom() call SetFeatureFrom() to avoid code duplication.
Removed and made SetFrom (with map) to call SetFieldsFrom.
As far as the RFC is concerned, do you intend writing tests in the autotest suite for the new methods ?
I attached to the wiki page an initial test. For that I needed to add the methods to the Python bindings (actually, to make them work). For that I needed to do a similar thing as I did for Perl, i.e., put the callback bindings code into a separate file. I also had to fix a bit the Python progress function typemaps.
The initial test just tests simple cases for geometries. But enough to raise concern if the Clip method is implemented correctly. It seems to me that it should clip out areas from the input layer that are not covered by *any* feature in method layer. This still needs to be looked into.
Thus the to do list: - docs - check the logic of Clip and possibly other methods - the progress calls The page: http://trac.osgeo.org/gdal/wiki/rfc39_ogr_layer_algebra Ari
Best regards, Even
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
