[gdal-dev] RFC 39

[Ari Jolma]

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
>