.. include-document:: org.gvsig.fmap.dal/reference-links
   :rest:

.. include-document:: org.gvsig.tools/reference-links
   :rest:


En ocasiones nos encontramos que dependiendo de algunas condiciones ajenas
a los datos en si mismos, no seria necesario disponer de un conjunto completo
de los fenómenos de un *almacén*, y si el *almacén* conociese cierta
información podría realizar optimizaciones en como recoge o recorre los
fenómenos que contiene para devolverlos a la aplicación. Esta información
adicional que no forma parte de los filtros u ordenaciones es lo que
denominamos contexto.

Nótese que cuando se indica una información de contexto para que el *almacén*
haga uso de ella y optimizar el acceso a los datos, la información que
nos devuelve la consulta no sera rigurosa. Por ejemplo, cuando estamos accediendo
a un servicio remoto de recuperación de fenómenos para pintarlos, si suministramos
a la consulta información de la escala, este puede obviar traerse del servidor
los fenómenos que no sean representativos de la escala a la que se este
trabajando e incluso simplificar las geometrías para optimizarlas en
función de la escala a la que van a ser usadas. Esto constituiría una optimización
durante el pintado de los datos, pero la información descargada nadie nos asegura
que fuese rigurosa. Así cuando vallamos a usar los datos para aplicar geoprocesos
o estemos interesados en realizar edición sobre ellos, nunca deberíamos indicar
en la consulta información de contexto.

Actualmente la única información de contexto prefijada que se trata en la
librería de acceso a datos es la *escala*. Se puede indicar información de contexto
adicional a modo de pares clave-valor. Hay que tener en cuenta que aunque se
especifique información de contexto, si el *almacén* no sabe como tratar
esa información de contexto, esta no se usará.

Imaginemos que estamos trabajando con capas de puntos obtenidas a partir de
un vuelo LIDAR. La cantidad de fenómenos asociado a esa fuente de datos puede
ser altísima, así que a la hora de pintar esos fenómenos nos gustaría que
tratase de hacer todas las optimizaciones que pudiese y, muy probablemente,
el uso de la información de escala a la cual voy a usar esos datos permita
acelerar mucho su acceso. Así podríamos indicar esa información al
obtener la colección de fenómenos.


.. code-block:: java

    FeatureQuery query = store.createFeatureQuery();
    query.setScale(scale);
    features = store.getFeatureSet(query);

    ...

    features.dispose();

Esta información de contexto podría acumularse a las otras informaciones de
ordenación o filtrado de una consulta.

.. code-block:: java

    FeatureQuery query = store.createFeatureQuery();
    query.getOrder().add("NOMBRE",true);
    query.setFilter( manager.createExpresion("NOMBRE like 'a%'") );
    query.setScale(scale);
    features = store.getFeatureSet(query);

    ...

    features.dispose();

Otra forma alternativa de indicar la escala como información de contexto seria:

.. code-block:: java

    FeatureQuery query = store.createFeatureQuery();
    query.getOrder().add("NOMBRE",true);
    query.setFilter( manager.createExpresion("NOMBRE like 'a%'") );
    query.setQueryParameter("Scale",scale);
    features = store.getFeatureSet(query);

    ...

    features.dispose();

De esta forma podrían indicarse otros valores de contexto que el
*almacén de datos* pueda utilizar para optimizar su consulta.

Es de recalcar que nadie nos garantiza que el *almacén* sepa hacer uso
de esa información para optimizar el acceso a los datos. Simplemente
ponemos a disposición del *almacén* esa información por si le puede ser
de utilidad. Y que si especificamos información de contexto, los datos
que devuelve la consulta no serán rigurosos.