[gdal-dev] Layer operations, a proposal

[Even Rouault]

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
> not,
> > 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
> all.
> > Checking that there are not fields with same name would not be necessary
> (in
> > 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.
>
> Ari
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>