[gdal-dev] Layer operations, a proposal
even.rouault at mines-paris.org
Thu Apr 19 09:20:53 EDT 2012
Selon Ari Jolma <ari.jolma at gmail.com>:
> On 04/19/2012 03:04 PM, Even Rouault wrote:
> >> http://trac.osgeo.org/gdal/wiki/rfc39_ogr_layer_algebra
> > 3) I'm wondering if it would not be more appropriate to separate the
> creation of
> > fields of the output layer in a separate method that might be called, or
> > before the real operation. For example IdentifyPrepare() for Identity().
> I don't understand your reasoning behind this. I get the point of
> separating the field map computations, but don't see why or how that
> would necessitate the *Prepare methods.
The rationale was that people could be interested in just a few fields from
input and/or method layers, and thus prefer to create them manually instead of
XXXX() doing it for them.
> > This way the XXXXXPrepare() would not need to check that CreateField()
> > succeeds because XXXX() could work with an output layer with no fields at
> > Checking that there are not fields with same name would not be necessary
> > that case the value from B would override the value from A).
> It is possible to have fields with same names in OGR. Having a field
> with same name does not mean that they are semantically same. Probably
> more often not. I think the method could be easier to understand if
> there is no value override.
True. In that case, one could imagine to add an option one day to provide the
mapping of the fields from the input and/or method layers to the fields of the
output layer to avoid any ambiguities, but that seems unnecessary for now.
For example, let's suppose that input and method layer have both a field F.
The user would create manually in C, 2 fields F1 and F2
And he would provide an option "FIELD_MAPPING=F1:input.F,F2:method.F"
Well, in a first step, we can perhaps take your proposal, and the above
suggestion would then skip the field creation step.
> Other comments are fine, thanks.
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
More information about the gdal-dev