[gdal-dev] Layer operations, a proposal

[Ari Jolma]

On 04/18/2012 02:32 AM, Frank Warmerdam wrote:
> Ari,
>
> I think this would be an interesting addition.   Would you be willing
> to write up an RFC?

Yes, but I probably want to include a working patch.

>
> I think the layer creation step should be a different call than the
> feature processing step to maximize the chance that folks who need to
> do something very format specific at layer creation can do so and
> still use the generic algorithm for processing the features.

Yes, I think it's best to bring in an empty layer. The attributes need 
some thought too. For example maybe it should be considered an error to 
union two layers with attributes that have the same name but different type.

>
> Your operations appear to be focused on spatial relationships, but
> I've also heard a lot of interest in feature joins on attribute
> fields.  One case is just merging features from a layer with a common
> attribute value.  Another case would be some sort of attribute based
> join between layers.  Hopefully we can use a reasonably similar
> approach for a variety of operations.

Hm.

C = A.Plus(B)

C would contain all features from A and B but obeying the current 
spatial and attribute filters in both layers. The filters could be in 
effect also in the spatial operations. C would have both the fields in A 
and in B.

It does not make much sense to compare the attributes of A and B because 
the join is not spatial in the first place.

>
> I'm curious how you plan to handle the spatial relationships
> efficiently?  An in memory spatial index?  I'd like have the API
> overly constrain how we implement this as I can imagine the internal
> operation implementation evolving over time, and perhaps taking
> different strategies for different styles of input data.  For instance
> an in-memory spatial index might not make much sense for large numbers
> of very simple point features while it would be good for heavy polygon
> features.

I didn't give much thought to it yet and I hope it could be kept 
internal (and why not?). My use case is interactive use where the layers 
do not have so many features or at least one of them has only few. All 
inner loops have the intersects constraint and for that we could compute 
the extent only once.

Regards,

Ari

>
>
> Best regards,
> Frank
>
> On Tue, Apr 17, 2012 at 2:42 PM, Ari Jolma<ari.jolma at gmail.com>  wrote:
>> Folks,
>>
>> I propose a set of new methods for OGR layers (see the PDF). I took the
>> basic ideas from page
>> http://courses.washington.edu/gis250/lessons/Model_Builder/ which seems
>> rather comprehensive. I wrote the pseudo code myself quickly (thus it may
>> not be optimal and may contain bugs - improvement suggestions are of course
>> welcome).
>>
>> I was considering to write these in Perl (on top of the Perl bindings) but
>> probably they could also be in OGR core. Code-wise they would probably go
>> into ogrlayer.cpp.
>>
>> If there is support/interest, I assume I should submit this as a RFC (with a
>> patch)?
>>
>> Best regards,
>>
>> Ari
>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>