gvSIG wishlist #3153
Estudiar la migracion a la libria org.gvsig.proj en gvSIG.
| Status: | Outdated | Spent time: | - |
|---|---|---|---|
| Priority: | Normal | ||
| Category: | - | ||
| Target version: | 1.0.0 | ||
| Severity: | Minor |
Description
La libreria org.gvsig.proj define un API y una implementacion de ese API basada en java a traves de la libreria proj4j.
Tanto el API como la implementacion tienen carencias. Habria que evaluar dos tipos de cosas:
- Compatibilizar el API de esta libreria con el de org.gvsig.projection (IProjection/ICoordTrans) para que se pueda hacer una transicion paulatina al nuevo API.
- Identificar y evaluar las deficiencias de la libreria org.gvsig.proj.
- Evaluar si es viable y que coste puede tener el usar proj4 directamente a traves de JNA para implementar el API.
Entre las deficiencias que actualmente tiene la libreria, al estar basada en proj4j arrastra las que esta pueda tener como son:
- No soporta el uso de regilla. Existen implementaciones java para la carga y aplicacion de regillas como jgridshift que podriamos ver de usar.
- No soporta algun tipo de transformaciones. Habria que averiguar que axactamente.
- Tiene su propia base de translaciones entre EPSG y cadenas proj4. Habria que estudiar disponer de una libreria que nos permitiese transladar la informacion de una BBDD de EPSG a cadenas proj4 para poder actualizar la bbdd facilmente. Si acabamos usando proj4 por debajo parece que se le puede pedir a proj4 que lo haga automaticamente si este esta configurado correctamente (http://trac.osgeo.org/proj/wiki/FAQ#HowdoIuseEPSGcoordinatesystemcodeswithPROJ.4)
- El interface de usuario deja mucho que desear.
- Deberiamos disponer de una forma comodo de que se puedan dar de alta nuevos sistemas de referencia.
History
#1
Updated by Joaquín del Cerro Murciano over 9 years ago
- Target version set to 1.0.0
#2
Updated by Cesar Martinez Izquierdo about 9 years ago
Hola Joaquín,
He estado echando un ojo al API de org.gvsig.proj, y he detectado las siguientes deficiencias que sería interesante resolver antes de migrar a ella:
- El tipo de proyección (UTM, LAEA, LCC, etc) no está disponible de una
forma evidente en CoordinateReferenceSystem (se podría obtener
"parseando" el resultado de getDefinition(), pero ver comentario
siguiente...)
- Según se describe en la API, el método CoordinateReferenceSystem.getDefinition
parece dependiente de la implementación (¿podría
devolver una definición PROJ o un WKT dependiendo de la implementación?)
- Según se describe en la API, el método CoordinateReferenceSystem.getDefinition
puede incluir una transformación. Creo que es una mala decisión no
distinguir entre el CRS y la transformación. Entiendo que este método
puede resultar cómodo para persistencia, pero puede traer más problemas
que beneficios, por ejemplo: ¿Cómo distingo a partir de la API si un CRS incluye una
transformación o no? Si tengo un CRS con transformación, cómo obtengo
la definición del mismo CRS sin transformación? ¿si uso un equals() para
comparar un CRS con transformación y el mismo CRS sin transformación,
debe devolver true o false?
- Sólo es posible construir un CRS a partir de autoridad+código, o dicho
de otra forma, no es posible construir un CoordinateReferenceSystem a
partir de un tipo de proyección, unos parámetros de proyección, un datum
y un elipsoide, lo cual sería necesario para construir CRSs de usuario
- No hay forma de obtener todas las transformaciones disponibles entre
dos CRSs concretos. CoordinateReferenceSystem.getTransformation devuelve
una única transformación. Esto sería necesario para la interfaz de
selección de transformación
- No hay forma de obtener el orden de ejes de una proyección (axis order).
En algunos casos podría obtenerse indirectamente parseando getDefinition,
pero el PROJCS de un WKT se puede definir con un código EPSG y el axis
order no estaría disponible en estos casos. Esta información es necesaria
para interpretar correctamente los servicios OGC
- Sería muy interesante poder crear un CoordinateReferenceSystem a partir
de una definición en WTK (útil para shapefiles) o una definición proj4
(útil para persistencia). También la operación inversa (obtener
definición proj4 o WKT desde un CoordinateReferenceSystem)
#3
Updated by Joaquín del Cerro Murciano almost 8 years ago
- Status changed from New to Outdated