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.

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.

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:

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.