Application: gvSIG desktop

I can reproduce the issue in build 2247. IMHO it could depend by the GEOMETRY field introduced in gvSIG 2.1, because it worked in gvSIG 1.12. See also #2849.

This issue doesn't depend by the GEOMETRY field, but the evolution of "bindings". Simply the SEXTANTE SelectionFilter is not applied like in the past. That's why each gvSIG geoprocess has a "Selected features" check box in its panel in order to pass those directly to algorithm process. Instead, the SEXTANTE geoprocesses need the application of a SelectionFilter (if we don't want to update all the algorithm classes...):

gvSIG 1.x
(gvVectorLayer.java, package es.unex.sextante.gvsig.core)

   public void create(final FLyrVect flayer) {

      m_Layer = flayer;
      try {
         m_RV = m_Layer.getSource();
         m_Projection = m_Layer.getProjection();
         final FBitSet fbitset = m_RV.getRecordset().getSelection();
         final BitSet bitset = (BitSet) fbitset.clone();
         final SelectionFilter filter = new SelectionFilter(bitset);
         addFilter(filter);
      }
      catch (final Exception e) {
         e.printStackTrace();
      }

   }

gvSIG 2.1
(FlyrVectIVectorLayer.java, package org.gvsig.geoprocess.lib.sextante.dataObjects)

    public void create(final FLyrVect layer) {
        m_Layer = layer;
        try {
            featureStore = layer.getFeatureStore();
            featureType = featureStore.getDefaultFeatureType();
            m_Projection = layer.getProjection();
        } catch (final Exception e) {
            Sextante.addErrorToLog(e);
        }

    }

FYI I've tried with this in FlyrVectIVectorLayer.java and tested with SEXTANTE Buffer:

    public void create(final FLyrVect layer) {
        m_Layer = layer;
        try {
            featureStore = layer.getFeatureStore();
            featureType = featureStore.getDefaultFeatureType();
            m_Projection = layer.getProjection();
            //new code from here
            FeatureSet featureSet = (FeatureSet)featureStore.getFeatureSet();
            FeatureSelection featureSelection = featureStore.getFeatureSelection();
            BitSet fBitSet = new BitSet((int) featureSet.getSize());
            DisposableIterator it = featureSet.fastIterator();
            int i = 0;
            while (it.hasNext()) {
                Feature feature = (Feature)it.next();
                if (featureSelection.isSelected(feature)) {
                    fBitSet.set(i);
                }
                i++;
            }
            it.dispose();
            final BitSet bitset = (BitSet) fBitSet.clone();
            final SelectionFilter filter = new SelectionFilter(bitset);
            addFilter(filter);
        } catch (final Exception e) {
            Sextante.addErrorToLog(e);
        }

    }

...but the selection filter works only when there aren't selected features or all the features are selected. Instead, if there are only some features selected, the Buffer returns an empty layer.

I'm not very used to the sextante APIs, but just in case, my proposal would be to implement a IVectorLayerFilter based on the FeatureSelection and to avoid the BitSet usage. Something like:

public class FeatureSelectionFilter implements IVectorLayerFilter {

   private final FeatureSelection selection;

   public FeatureSelectionFilter(FeatureSelection selection) {
      this.selection = selection;
   }

   public int getLast() {
      // Warning: long to int conversion
      return selection.getSize() - 1;
   }   

   public boolean accept(final IFeature ifeature,
                         final int iIndex) {

      // Replace with the right way to reach the gvSIG Feature from the sextante IFeature
      Feature feature = (Feature)ifeature;
      return selection.isSelected(feature);
   }
}

Even better would be to fully avoid sextante having to perform the filtering itself in the case of the selection, providing it a FeatureSelection, taking into account it implements FeatureSet. But don't really know if it would be feasible.

Hi Cesar,
first of all thank you very much for your useful suggestions. Consider that I'm not a Java professional and I'm not very experienced with SEXTANTE and the new gvSIG APIs, so my question is... How to reach gvSIG Feature from SEXTANTE IFeature? From IFeature we can get Geometry and IRecord (and then its Object[]), but AFAIK there's not a gvSIG Feature constructor (if I remember well, Feature is an interface), but only iterable FeatureSets... Other suggestions?

Hi Antonio,

Sorry I've been taken a look at the current implementation, with the help of Francisco Díaz, and the first proposal about a custom filter is not feasible, there is not any direct relationship between a DAL Feature and the IFeature implementation being used.

By the other way, it seems the second proposal would be more simple to implement, and I think also more efficient. The idea would be to change the implementation of the DALIFeatureIterator class to use the data in the selection instead of the full datasource data, avoiding any filtering. Something like:

  public DALIFeatureIterator(final FLyrVect layer,
        final List<IVectorLayerFilter> filters) {

        m_bIsNextConsumed = true;
        m_Filters = filters;

        FeatureSet set = null;
        try {
            /* CHANGE TO SUPPORT SELECTION */
            FeatureSelection selection = layer.getFeatureStore().getFeatureSelection();
            if (!selection.isEmpty()) {
              set = selection;
            } else {
              set = layer.getFeatureStore().getFeatureSet();
            }
            /* /CHANGE TO SUPPORT SELECTION */
            m_FeatureIterator = set.fastIterator();
        } catch (final DataException e) {
            if (m_FeatureIterator != null) {
                m_FeatureIterator.dispose();
            }
            if (set != null) {
                set.dispose();
            }
        }
    }

The proposal checks if the selection is empty to use it or all the layer's data. But it is not correct, it must be changed to check instead if the user has selected the "Use selection" option in the algorithm form.

I can confirm that it works fine now (thanks Francisco and Cesar), but the update of the Geoprocesses addons is not very user-friendly (see #2944) at least on Windows.