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<[email protected]> 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
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
