Hola a todos.
Una pregunta que suelen hacer los desarrolladores que habiendo desarrollado aplicaciones para gvSIG 1 pasan a desarrollar con gvSIG 2 es…

¿ como puedo  obtener una feature concreta por posición ?

Es una operación que se realizaba habitualmente en gvSIG 1.
La respuesta rápida es que no se puede. Dicho esto comentaré algunas opciones para rodearlo.

El API de acceso a datos de gvSIG 2 esta pensado para que se acceda de forma óptima tanto a fuentes de datos locales, como pueda ser un shape, como a remotas, entre las que hemos dedicado una especial atención el acceso a BBDD relacionales. Acceder por posición a una feature de un shape es relativamente simple y eficiente. De hecho, es posiblemente el acceso natural al shape. Apenas tiene coste. Sin embargo, cuando estamos accediendo a una tabla de una BBDD relacional, el acceso por posición, además de no ser nada eficiente, puede que no nos dé los resultados que deseamos. Cuando intentemos recuperar features de una BBDD, suponiendo que está correctamente configurado el servidor, el coste más alto solemos encontrarlo en la latencia de la red, pudiendo estar incluso alrededor del segundo el coste de recuperar una feature, y costando lo mismo recuperar una que mil. Como el API de acceso a datos de gvSIG es el mismo independientemente de la fuente de datos a la que se este accediendo, la decisión que se tomó en su diseño fue ofrecer un API que pudiese usarse tanto para fuentes de datos locales, como el shape, como remotas, como una BBDD, eliminándose la funcionalidad de acceso aleatorio de este.

Dicho así, tan rotundamente, no es del todo cierto. El API incluye una forma de acceso aleatorio, que no por posición. Podemos obtener de una Feature su FeatureReference para más tarde poder volver a recuperar la Feature entera. Esta recuperación posterior de la Feature provocará un acceso a la fuente de datos para hacerlo, así que deberíamos tener cuidado con el uso de esta funcionalidad. Además, la FeatureReference implementa el interface Persistent, lo que nos permite almacenar referencias a features en la persistencia del proyecto o del plugin de forma transparente.

Otra forma de acceso aleatorio sobre una fuente de datos es indicando el parámetro posición al método fastiterator, pero tenemos que tener en cuenta que si la fuente de datos no soporta esa operación se iteraría desde el principio de esta saltando las features previas hasta llegar a la posición indicada. Por suerte, el proveedor de datos de PostgreSQL funcione correctamente a la hora de realizar esta operación.

De todos modos, estas dos operaciones no son lo mas adecuado para acceder por posición a una Feature.

Incluido en el API de acceso a datos se encuentra otra una utilidad que nos permite paginar los datos y acceder a ellos por posición de forma transparente. Dependiendo del tamaño de página que indiquemos y el tipo de explotación que queramos hacer de los datos puede ser una opción aceptable. Evidentemente, para recuperar una sola feature por posición, no es lo aconsejable. Se trata del FeaturePagingHelper. para crear uno de ellos a partir de un FeatureStore se haría con:

...
DataManager manager = DALLocator.getDataManager();
FeaturePagingHelper featurePager = manager.createFeaturePagingHelper(featureStore, query, pageSize);
...

Donde le indicaríamos el FeatureStore sobre el que queremos crear el FeaturePagingHelper, un FetureQuery, que puede ser null si queremos recuperar todas las features sin filtrado, y el tamaño de página que queremos usar.

El FeaturePagingHelper tiene métodos como:

Feature getFeatureAt(long index)

Que nos permite recuperar una Feature por posición, o un:

long getTotalSize()

Que nos permite obtener el número de features totales.
De todos modos el método mas interesante probablemente sea:

List<Feature> asList()

Que nos devuelve un adaptador a List de features basado en el FeaturePagingHelper. Eso nos permite acceder a las features de un FeatureStore como si se tratase de una lista standard de java, funcionando de forma transparente no importa de cual sea la fuente de datos. En gvSIG esto es usando en el documento Tabla y tiene unos rendimientos aceptable.

Bueno, he comentado como podéis rodear el problema del acceso por posición a las Features de un FeatureStore, ahora toca la recomendación. Siempre que sea posible utilizar los iteradores o visitors sobre los FeatureSet. En gvSIG, usar iteradores y visitors es lo más eficiente. Si estáis migrando código a gvSIG y os encontráis algoritmos que se basan en el acceso aleatorio a la fuente de datos, en lugar de intentar migrar el código tal cual, intentad sustituir el algoritmo basado en acceso aleatorio por otro basado en iterar sobre los datos.

Como siempre, espero que os sea de utilidad.

Un saludo a todos.
Joaquin