[Gvsig_usuarios] proyecciones raras y costes anisotropicos enSEXTANTE

Jue Jul 10 20:16:49 CEST 2008

Estoy de acuerdo, de hecho en muchas operaciones no hay que visualizar 
nada. La solución, en su caso, debería tener en cuenta que se debe poder 
trabajr con la Tierra en su conjunto y no sólo con fragmentos más o 
menos grandes de ella.
Por cierto Víctor, eso de "proyecciones raras" no sé, no sé...   :-)

De todas formas mi problema sigue ahí. Pego abajo mi primer correo 
porque el hilo ha cambiado dos veces y sospecho que no sería fácil de 
encontrar:

---------------
Saludos a todos
Ya he visto que el tema de las proyecciones es siempre conflictivo y os 
planteo ahora un problema de esos que parece tiene difícil solución en 
gvSIG.
Estoy trabajando con análisis de coste anisotrópico en Sextante, 
calculando costes de desplazamientos de aves migratorias sobre el viento.
La zona es el Atlántico desde 50ºN a 50ºS y los datos los tengo 
proyectados a Mercator (clásica, no transversa) con meridiano central 
25º Oeste.
Mi problema surge a la hora de asignar/definir la proyección a la 
vista/capas en gvSIG: no hay código EPSG que se ajuste a esa proyección. 
Esto no es sorprendente ya que es una proyección hecha a medida de los 
datos y condcionada por los análisis que hay que hacer.
Me ha parecido entender de otros correos y de buscar en la documentación 
sobre proyecciones en gvSIG que no es posible definir proyecciones a 
medida.

Datos complementarios:
- buscando "mercator" dentro de los códigos EPSG no sale ninguna opción 
adecuada
- dentro de los códigos ESRI figura la 54004 World_Mercator D_WGS_1984 
pero al elegirla (aún antes de analizar qué es exactamente) gvSIG peta y 
se cierra (pero este es otro problema porque sospecho que tampoco me 
valdría si no puedo definir el merididano central)
- dentro de los códigos de la IAU aparecen dos códigos: 39974 y 39975, 
ambos como  Earth_Mercator_AUTO y Datum D_Earth_2000. Lamentablemente no 
he encontrado nada de documentación sobre los códigos de la IAU, sobre 
la diferencia entre el 39974 y 39975, sobre el significado de ese 
"AUTO", soore el datum D_Earth_2000, ni sobre el comportamiento de 
gvSIG/Sextante si llego a definirlo sobre mis datos.

Una opción sería EPSG:9804 o EPSG:9805 pero ninguna está soportada por 
gvSIG y de todas formas debería ser configurable

Os agradecería enormemente algún comentario sobre:
   a. la posibilidad o no  de definir proyecciones con parámetros a 
medida (y, en su caso, cómo se hace)
   b. alguna solución alternativa aunque sea aproximada
   c. sobre la influencia o no de definir un proyección errónea en los 
resultados de análisis de coste anisotrópico

Una alternativa podría ser transformar los datos actuales a geográficas 
WGS84 (EPSG:4326) pero necesitaría saber qué consecuencias tiene eso en 
el cálculo de coste anisotrópico (estamos trabajando de grados y sus 
dimensiones no son iguales a diferentes latitudes) ¿soporta esto Sextante?

En fin, un problema que espero que alguien pueda ayudarme a solucionar 
en cuyo caso queda invitado a tapas de jamón ibérico cuando pase por 
Mérida. Además, dentro de poco tendré qye trabajar en el Océano Pacífico 
con lo que esto se reproducirá y aumentará  :-(
Gracias anticipadas.
--------------------------------------------

DAVID HERNANDEZ LOPEZ escribió:
>
> Alguna reflexión acerca de los cálculos con coordenadas geodésicas.
> El problema de las coordenadas geodésicas (latitud y longitud, ya sea 
> sobre esfera o elipsoide) es, tal y como apunta acertadamente 
> Felicísimo, que no es un sistema isométrico de coordenadas, dicho de 
> forma sencilla, una variación similar sobre ambos parámetros 
> (diferencial de latitud y diferencial de longitud) en cualquier punto, 
> no se corresponde con un mismo desplazamiento lineal sobre la 
> superficie ya que los radios de curvatura de los parámetros varían de 
> un punto a otro de la superficie. Una solución "parcial" al problema 
> es trabajar con latitud isométrica y longitud, ya que estos si que 
> definen una parametrización isométrica del elipsoide o la esfera (con 
> las expresiones adecuadas para cada superficie) y que no es sino 
> utilizar una representación similar a la proyección de Mercator (en la 
> que las coordenadas abcisa y ordenada no son sino el producto del 
> semieje mayor(o radio) por el incremento de longitud respecto al 
> meridiano origen, y por la latitud isométrica, respectivamente).
> En cualquier caso, lo recomendable sería que los algoritmos de 
> cálculos de parámetros métricos: distancias, ángulos y superficies, en 
> cualquier problema, detectarán el CRS de la información y convirtieran 
> a otro óptimo para el cálculo: proyección equivalente, conforme, 
> esfera de Jacobi, ... No es tan complejo. En mi opinión debería ser 
> responsabilidad de la función que recibe la geometría para resolver el 
> cálculo y no del sistema de visualización, resultando opaco al usuario.
>
>
> -----Mensaje original-----
> De: gvsig_usuarios-bounces en runas.cap.gva.es en nombre de "Ángel M. 
> Felicísimo"
> Enviado el: jue 10/07/2008 14:25
> Para: Lista de Usuarios de gvSIG
> Asunto: Re: [Gvsig_usuarios] proyecciones raras y costes anisotropicos 
> enSEXTANTE
>
> Hola Victor,
> No. ningún SIG que yo conozca es capaz de trabajar con las distancias
> "correctas". La solución más elegante sería que se trabajara con las
> localizaciones en grados y que el SIG calculara las distancias correctas
> en cada pixel. Sin embargo, ese problema me parece complejo porque
> afecta al propio núcleo de los programas, pensados siempre para trabajar
> con sistemas cartesianos simples (quiero decir con escala uniforme en
> los ejes) y en dos dimensiones.
> Deduzco que si meto los datos en grados Sextante los tratará como
> unidades uniformes en el cálculo de coste ¿no es así?
> Esto, de todas formas, me precupa menos que lo otro, es un problema que
> tengo que asumir y que afecta a una minoría que trabajamos con grandes
> extensiones.
> Saludos
> Angel
>
> Victor Olaya escribió:
> > Independientemente del problema con las proyecciones correctas o no,
> > SEXTANTE utiliza para el cálculo de costes unitarios (de una celda a 
> otra),
> > las distancias entre celdas, y trabajando con ese tipo de proyección esa
> > distancia realmente no va a ser constante, sino muy variable. Me 
> temo que
> > habrá que introducir las modificaciones oportunas para trabajar en esas
> > circunstancias y ademas con extensiones de terreno tan amplias.
> >
> > Mi pregunta es si realmente otros SIG hacen eso, que no lo tengo tan
> > claro... (o simplemente es que a mi se me ha pasado considerar esto...)
> >
> > Saludos
> >
> > Victor
> >
> > _______________________________________________
> > gvSIG_usuarios mailing list
> > gvSIG_usuarios en runas.cap.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://runas.cap.gva.es/mailman/listinfo/gvsig_usuarios
> >
> > No virus found in this incoming message.
> > Checked by AVG - http://www.avg.com
> > Version: 8.0.138 / Virus Database: 270.4.7/1543 - Release Date: 
> 09/07/2008 18:32
> >
> >
> >
> >  
>
>
> --
> Ángel M. Felicísimo
> Escuela Politécnica
> Universidad de Extremadura
> --------------------------
> E-mail: amfeli en unex.es
> Móvil: +34-659523529
> Grupo de Investigación: http://www.unex.es/unex/grupos/grupos/kraken
> Blog personal: http://golemp.blogspot.com/
>
> _______________________________________________
> gvSIG_usuarios mailing list
> gvSIG_usuarios en runas.cap.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://runas.cap.gva.es/mailman/listinfo/gvsig_usuarios
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.138 / Virus Database: 270.4.7/1544 - Release Date: 10/07/2008 7:37
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> gvSIG_usuarios mailing list
> gvSIG_usuarios en runas.cap.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://runas.cap.gva.es/mailman/listinfo/gvsig_usuarios
>   

-- 
Ángel M. Felicísimo
Escuela Politécnica
Universidad de Extremadura
--------------------------
E-mail: amfeli en unex.es
Móvil: +34-659523529
Grupo de Investigación: http://www.unex.es/unex/grupos/grupos/kraken
Blog personal: http://golemp.blogspot.com/