[gdal-dev] RFC 39
ari.jolma at gmail.com
Thu Apr 26 06:33:31 EDT 2012
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.
> 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
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.
> 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
Thus the to do list:
- check the logic of Clip and possibly other methods
- the progress calls
The page: http://trac.osgeo.org/gdal/wiki/rfc39_ogr_layer_algebra
> Best regards,
More information about the gdal-dev