[Gvsig_desarrolladores] Duda acerca del tratamiento de los CRS

["Jose Manuel Vivó Arnal ( Chema )]

El 09/04/12 10:08, junquero escribió:
> Hola José Carlos
>
> He seguido tus indicaciones y efectivamente funciona. La sentencia:
>
> Select asBinary("GEOM"), "GID" , "GID" from "PUBLIC"."rivers" where (
> intersects(ST_GeomFromEWKT('SRID=23030;POLYGON ((4022.6022689993083
> 5607.723706191383, 4022.6022689993083 6252.487920771555, 4779.808807976464
> 6252.487920771555, 4779.808807976464 5607.723706191383, 4022.6022689993083
> 5607.723706191383))'), st_setsrid (st_envelope(GEOM), 23030)) )
>
> si que produce el resultado esperado.
>
> Sin embargo, sigo encontrando la dificultad de que para hacer que funcione
> he tenido que tocar en gvSIG el código fuente de la clase
> IntersectsEnvelopeEvaluator, que se encuentra en el paquete
> org.gvsig.fmap.mapcontext.layers.vectorial.
>
> Pienso que sería deseable que la construcción de dicha sentencia no recayera
> en dicha clase, sino que debería ser el driver el que la construyera, puesto
> que es el driver el que conoce las capacidades del backend, sin embargo no
> veo la manera de hacerlo de una forma elegante. La única forma que veo
> actualmente es capturar las sentencias SQL que llegan al driver, buscar la
> expresión regular de la sentencia SQL construida por la clase
> IntersectsEnvelopeEvaluator, y sustituirla por la propia del driver, sin
> embargo creo que no es la mejor manera de hacerlo.
>
> No se si esto es más o menos lo que indicabas cuando decías que gvSIG 2
> parseaba el sql sustituyendo cierto seudocodigo en el sql.
>
> Esperaré a ver si Cesar Ordiñana lee este post y me puede dar algún consejo.
>
> Gracias.
>
>
>
>
>
>
> --
> View this message in context: http://osgeo-org.1560.n6.nabble.com/Duda-acerca-del-tratamiento-de-los-CRS-tp4694794p4715363.html
> Sent from the gvSIG desarrolladores mailing list archive at Nabble.com.
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores en listserv.gva.es
> Para ver histórico de mensajes, editar sus preferencias de usuario o darse de baja en esta lista, acuda a la siguiente dirección: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores

Efectivamente, ahora mismo los providers de de BBDD hace eso.

Ya que en la parte de FMAP no es posible, (ni debe en ningún caso) 
distinguir el tipo de "provider" (es el nombre que se utiliza en DAL) el 
filtro debe ser idéntico y válido para todos.

Este problema ya lo encontramos con el provider de MySQL y PostGIS. 
¿Como hacemos que los filtro funcione en ambos?, la única solución que 
encontramos en ese momento fue que siempre usamos una sintaxis concreta 
y cada "provider" ajustase el filtro, si podía.

Ten en cuenta que los filtros *siempre* se evalúan en el cliente, ya se 
haya hecho algún proceso en la parte de servidor o no. Esto es necesario 
ya que el filtro puede tener condiciones y lógica que no esté 
implementadas en el servidor.

Para futuras versiones creo que se planteó usar una estructura de 
objetos para definir los filtros, pero, en ese momento, no encontramos 
ninguna librería que encajase en los requisitos y no había recursos para 
iniciar el desarrollo.

Coincido contigo que no es una solución "elegante" tener que transformar 
el filtro a base de expresiones regulares para ajustarlo a nuestro 
provider, pero fue una solución de compromiso dadas las necesidades y 
los plazos.

Espero haberte sido de ayuda.

Un Saludo.
Chema.
-- 
Jose Manuel Vivó Arnal
DiSiD Technologies S.L. (http://www.disid.com)