[Gvsig_desarrolladores] Duda acerca del tratamiento de los CRS
Jose Carlos Martinez Llario
jomarlla en cgf.upv.es
Sab Abr 7 23:16:25 CEST 2012
On 07/04/2012 22:44, junquero wrote:
> Hola
>
> Efectivamente, gvSIG si soporta cambio de CRS, fué una confusión mía. Sin
> embargo, pienso que si que confía en la base de datos espacial para realizar
> la conversión, y estoy de acuerdo en que es raro, puesto que es posible que
> no todas las BD espaciales lo soporten, y al menos debería haber algún
> parámetro que indicara si la base de datos soporta dicha transformación o
> no.
>
> Respecto a JASPA, por concretar más, no digo que no soporte la función
> ST_Transform, sino que no soporta la transformación en la sentencia que
> utiliza gvSIG. Lo concreto algo más...
>
> La sentencia que usa gvSIG para obtener los datos cuando la región a mostrar
> es más pequeña que en Envelope es la siguiente (a modo de ejemplo):
>
> Select asBinary("GEOM"), "GID" , "GID" from "PUBLIC"."CARRETERAS" where (
> intersects(GeomFromText('POLYGON ((XYLIST))', 'EPSG:23030'), envelope(GEOM))
> )
>
> Si te fijas, en GeomFromText utiliza una sintaxis que tras la geometría,
> especifíca el CRS. Esta sintaxis a JASPA no le gusta nada y da error de
> sintaxis.
Esa sintaxis no es compatible Jaspa, pero tampoco OGC ni PostGIS. Me da
la impresión que el SQL que muestras no es el SQL que gvsig
manda a la base de datos, sino uno intermedio. ME parece recordar en un
taller de Cesar Ordiñana que gvSIG 2 parseaba el sql sustituyendo cierto
seudocodigo en el sql pero no me hagas mucho caso pq en gvsig 2 estoy
algo más que verde. Has comprobado el SQL en el log de postgres o h2?
>
> Si por el contrario, se usa otra sintaxis parecida:
>
> Select asBinary("GEOM"), "GID" , "GID" from "PUBLIC"."rivers" where (
> intersects(GeomFromText('SRID=23030;POLYGON ((4633.081699633056
> 5916.746136865342, 4633.081699633056 6298.454746136866, 5081.357593965176
> 6298.454746136866, 5081.357593965176 5916.746136865342, 4633.081699633056
> 5916.746136865342))'), envelope(GEOM)) )
Esa si que es la sintáxis correcta.
>
> El error que da es que los SRSID de las geometrías para la función
> intersects debe ser la misma. En concreto el error es el siguiente:
>
> Exception calling user-defined function: "ST_Intersects([B en 8f3d27,
> [B en 1f7cdc7): The geometries must have the same SRID: found SRIDs 23030 and
> 4326"; SQL statement:
> Select asBinary("GEOM"), "GID" , "GID" from "PUBLIC"."rivers" where (
> intersects(GeomFromText('SRID=23030;POLYGON ((4633.081699633056
> 5916.746136865342, 4633.081699633056 6298.454746136866, 5081.357593965176
> 6298.454746136866, 5081.357593965176 5916.746136865342, 4633.081699633056
> 5916.746136865342))'), envelope(GEOM)) ) [90105-157] 90105/90105
Pero es que esto también es normal, tanto en PostGIS, Jaspa u otra base
de datos espacial (que yo sepa) no puedes hacer operaciones en geom en
diferente srid. El GEOM de envelope está en 4326.
ummm...ya recuerdo lo que pasa.
Aqui si que hay ua diferencia entre PostGIS y Jaspa, PostGIS utiliza el
tipo BBOX en la devolución de envelope, este tipo no lleva información
de srid. Jaspa utiliza tipos compatibles luego utiliza el tipo POLYGON
para devolución de envelope. Podrías probar a utilizar st_setsrid
(st_envelope(geom), 23030) ? creo que debería funcionar.
>
> Me da la sensación, ya que soy principiante en gvSIG, de que esto es porque
> en gvSIG se ha confiado en la conversión de coordenadas en la BD espacial,
> porque la sentencia SQL se construye en la clase
> org.gvsig.fmap.mapcontext.layers.vectorial.IntersectsEnvelopeEvaluator.
>
> En esta clase, antes se hacía la conversión de coordenadas, pero la zona de
> código que la hacía ahora está comentada. Adjunto el código fuente de la
> clase donde se observa que en el constructor está comentada la parte donde
> se realiza la conversión de coordenadas.
>
> package org.gvsig.fmap.mapcontext.layers.vectorial;
>
> import org.cresques.cts.IProjection;
>
> import org.gvsig.fmap.dal.exception.DataEvaluatorRuntimeException;
> import org.gvsig.fmap.dal.feature.Feature;
> import org.gvsig.fmap.dal.feature.FeatureAttributeDescriptor;
> import org.gvsig.fmap.dal.feature.FeatureType;
> import org.gvsig.fmap.geom.Geometry;
> import org.gvsig.fmap.geom.operation.GeometryOperationException;
> import org.gvsig.fmap.geom.operation.GeometryOperationNotSupportedException;
> import org.gvsig.fmap.geom.operation.towkt.ToWKT;
> import org.gvsig.fmap.geom.primitive.Envelope;
> import org.gvsig.tools.evaluator.AbstractEvaluator;
> import org.gvsig.tools.evaluator.EvaluatorData;
> import org.gvsig.tools.evaluator.EvaluatorException;
>
> public class IntersectsEnvelopeEvaluator extends AbstractEvaluator {
>
> private Envelope envelope;
> private String geomName;
> private String envelopeWKT = null;
> private Envelope envelopeTrans;
> private boolean isDefault;
> private String srs;
>
> public IntersectsEnvelopeEvaluator(Envelope envelope,
> IProjection envelopeProjection, FeatureType featureType,
> String geomName) {
> FeatureAttributeDescriptor fad = (FeatureAttributeDescriptor) featureType
> .get(geomName);
>
> this.isDefault = featureType.getDefaultGeometryAttributeName().equals(
> geomName);
> this.envelope = envelope;
> // this.srs = envelopeProjection.getAbrev();
> // this.projection=CRSFactory.getCRS(fad.getSRS());
> // this.envelopeProjection=envelopeProjection;
> // ICoordTrans ct = null;
> // if (!this.srs.equals(fad.getSRS())) { // FIXME comparación
> // ct = envelopeProjection.getCT(fad.getSRS());
> // }
> // if (ct != null) {
> // this.envelopeTrans = envelope.convert(ct);
> // } else {
> this.envelopeTrans = envelope;
> // }
> this.geomName = geomName;
>
> this.srs = envelopeProjection.getAbrev();
>
> this.getFieldsInfo().addMatchFieldValue(geomName, envelopeTrans);
>
> }
>
> public Object evaluate(EvaluatorData data) throws EvaluatorException {
> Envelope featureEnvelope;
> if (isDefault) {
> featureEnvelope = ((Feature) data.getContextValue("feature"))
> .getDefaultEnvelope();
> } else {
> featureEnvelope = ((Geometry) data.getDataValue(geomName)).getEnvelope();
> }
> return new Boolean(envelopeTrans.intersects(featureEnvelope));
>
> }
>
> public String getName() {
> return "intersets in envelope";
> }
>
> public String getSQL() {
>
>
> if (envelopeWKT == null) {
> try {
> envelopeWKT = (String) envelope.getGeometry().invokeOperation(
> ToWKT.CODE, null);
> } catch (GeometryOperationNotSupportedException e) {
> throw new DataEvaluatorRuntimeException(e);
> } catch (GeometryOperationException e) {
> throw new DataEvaluatorRuntimeException(e);
> }
> }
>
> return " intersects(GeomFromText('" + envelopeWKT + "', '" + srs
> + "'), envelope(" + geomName + ")) ";
> }
> }
>
>
>
>
>
> --
> View this message in context: http://osgeo-org.1560.n6.nabble.com/Duda-acerca-del-tratamiento-de-los-CRS-tp4694794p4696055.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
Más información sobre la lista de distribución gvSIG_desarrolladores