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