[Gvsig_usuarios] Re: gvSIG: Reproyección: Puerto Rico

[Diego Guerrero]

Hola, Iván.

Voy teniendo más claro lo que pasa en gvSIG o, mejor dicho, lo que pasa con la 
base de datos EPSG. El problema es que en esta base de datos las unidades del 
CRS EPSG:3991 (las unidades de su proyección) son pies, es decir, asume que 
los datos que cargas están en pies, por lo que se aplica un factor de 
conversión a metros al cargar la capa, produciendo un desplazamiento y 
escalado.

En el caso de los parámetros (como por ejemplo false_easting) no hay problema 
con las unidades, puesto que gvSIG hace la conversión internamente: 500000 ->  
152.400,3048... ya que conoce las unidades en las que están estos parámetros.

Creo que hay otro problema en la definición que EPSG:3991, y es que los 
parámetros standard_parallel_1 y standard_parallel_2 están intercambiados, 
aunque de esto no estoy totalmente seguro.

Estos problemas podrás solventarlos cuando se publique la nueva versión de 
gvSIG, ya que podrás crear un CRS nuevo a partir del existente pero 
corrigiendo este error. Mientras tanto estoy buscando la forma de que lo 
arregles en la versión que tienes, espero conseguirlo.

Saludos, 

	Diego Guerrero.

El Friday 11 July 2008 14:38:32 escribió:
> Saludos y gracias:
>
> Aquí también ha dado problemas ese cambio entre datums.
>
> Desde mi experiencia con ESRI he tenido que modificar el parámetro de
> unidades de pies a metros. Afortunadamente el programa hacía el cómputo
> entre pies y metros. Esto se traducía en el easting de 500.000 a
> 152.400,3048.....
>
> Aún en workstation ArcInfo la traslación de datums era mucho más fácil de
> hacer y definir.
>
> Luego con Manifold GIS las capas no alineaban porque Manifold usa la
> definición del Puerto Rico Datum y no la de NAD27.
>
> No sé qué es lo que está pasando con gvSIG, pero no es el único que ha
> tenido problemas con esa transformación.
>
> Si los datos no escalan bien, creo que debería ser una diferencia en las
> unidades de medida al convertir.
>
> ---------------------------
> Iván Santiago
> Information Technologies
> Office of Management and Budget
> <https://mail.ogp.gobierno.pr/exchweb/bin/redir.asp?URL=https://mail.ogp.go
>bierno.pr/exchweb/bin/redir.asp?URL=http://www.ogp.gobierno.pr/>
> 787.977.9200 x 4252
> Calle Cruz 254
> PO Box 9023228
> San Juan, PR 00902-3228
> -66°05'07.25",18°26'54.74"(WGS84)
>
> ________________________________
>
> From: Diego Guerrero [mailto:diego.guerrero en uclm.es]
> Sent: Fri 7/11/2008 8:04 AM
> To: Ivan Santiago
> Subject: Re: gvSIG: Reproyección: Puerto Rico
>
>
> Hola,
>
> He podido cargar correctamente las tres capas que me has pasado en una
> vista de gvSIG, pero para ello he tenido que utilizar una nueva
> funcionalidad que aun no se a publicado (espero que se publique en breve) y
> que permite crear CRSs personalizados a partir de su definición en WKT. He
> creado los CRS correspondientes a NAD27-Cónica Conforme de Lambert y
> NAD27-versal Universal de Mercator, a partir del contenido de los ficheros
> .prj que acompañan a los .shp (simplemente copiando y pegando, creo que
> esto será bastante útil cuando se publique). Aun tengo que averiguar por
> qué no obtengo los mismos resultados al utilizar EPSG:3991 para reproyectar
> pg_hdspc40.shp. La reproyección de pg_hdspcutm40.shp usando el CRS
> EPSG:3920 si produce el mismo resultado que si uso el CRS creado a partir
> del contenido del .prj.
>
> Seguiré informándote de mis conclusiones.
>
> Saludos,
>
>         Diego Guerrero.
>
> El Thursday 10 July 2008 15:50:48 escribió:
> > Saludos:
> >
> >
> >
> > Envío un ejemplo hidrográfico en distintos sistemas de coordenadas:
> >
> > State Plane, NAD83, metros
> >
> > State Plane, Puerto Rico Datum 1940 (Alias NAD27, según ESRI), metros
> >
> > UTM Zona 20N, Puerto Rico Datum (Alias NAD27), metros.
> >
> >
> >
> > Un detalle curioso es que cuando usé otro programa "Manifold GIS", tuve
> > problemas de desplazamiento cuando quise pasar los datos a SPCNAD27.  El
> > ejemplo en utm 40 reproyectó más o menos, dejando una diferencia de dos
> > metros.  Manifold usa sus propios algoritmos para la reproyección.  Ellos
> > dicen que los que hay son imprecisos.  Allá ellos; yo no sé.
> >
> >
> >
> > Finalmente los archivos que envío fueron reproyectados desde un archivo
> > hidrográfico original en State Plane, NAD83 (HARN).  Este a su vez fue
> > reproyectado o transformado a NAD83 y a NAD27 con proyecciones 1. Cónica
> > Conforme de Lambert y 2. Transversal Universal de Mercator.
> >
> >
> >
> > Espero se pueda averiguar qué es lo que está pasando, o si es que estoy
> > haciendo algo mal.
> >
> >
> >
> >
> >
> > Aprovecho para preguntar si tienes que ver también con el desempeño del
> > gvSIG en cuanto a las funciones analíticas de solape.  La función Union
> > no me trabajó con un ejemplo de caps de áreas.  Después de unos minutos,
> > gvSIG me devolvió un mensaje de error la jerga de java....
> >
> >
> >
> > null com.vividsolutions.jts.util.AssertionFailedException: unable to
> > assign hole to a shell
> > com.vividsolutions.jts.util.Assert.isTrue(Assert.java:71)
> > com.vividsolutions.jts.operation.overlay.PolygonBuilder.placeFreeHoles(Po
> >ly gonBuilder.java:223)
> > com.vividsolutions.jts.operation.overlay.PolygonBuilder.add(PolygonBuilde
> >r. java:84)
> > com.vividsolutions.jts.operation.overlay.PolygonBuilder.add(PolygonBuilde
> >r. java:69)
> > com.vividsolutions.jts.operation.overlay.OverlayOp.computeOverlay(Overlay
> >Op .java:180)
> > com.vividsolutions.jts.operation.overlay.OverlayOp.getResultGeometry(Over
> >la yOp.java:127)
> > com.vividsolutions.jts.operation.overlay.OverlayOp.overlayOp(OverlayOp.ja
> >va
> >
> >:66)    
> >: com.vividsolutions.jts.geom.Geometry.difference(Geometry.java:1084)
> >
> > com.vividsolutions.jts.precision.EnhancedPrecisionOp.difference(EnhancedP
> >re cisionOp.java:127)
> > com.iver.cit.gvsig.geoprocess.impl.difference.fmap.DifferenceVisitor.visi
> >t( Unknown Source)
> > com.iver.cit.gvsig.fmap.operations.strategies.DefaultStrategy.process(Unk
> >no wn Source)
> > com.iver.cit.gvsig.geoprocess.impl.union.fmap.UnionGeoprocess$UnionMonito
> >ra bleTask.run(Unknown Source)
> > com.iver.utiles.swing.threads.MonitorableDecoratorMainFirst.run(Unknown
> > Source)
> > com.iver.andami.PluginServices$1.construct(PluginServices.java:400)
> > com.iver.utiles.swing.threads.SwingWorker$2.run(Unknown Source)
> > java.lang.Thread.run(Unknown Source)
> >
> >
> >
> >
> >
> > Es posible que los shapefiles fuente hayan tenido algún error geométrico.
> > Eso lo tengo que corroborar.
> >
> >
> >
> > Por otro lado intenté hacer la función Unión "Juntar" primero usando el
> > Sextante.  Este terminó mucho más rápido y pude ver la geometría
> > combinada pero no me devolvió la tabla de atributos con los valores
> > unidos. Solamente se pueden ver los valores de la tabla de la primera
> > capa usada para el proceso "juntar".  ¿Qué podrá estar pasando?
> >
> >
> >
> >
> >
> > Gracias por la ayuda.
> >
> >
> >
> > ---------------------------
> >
> > Iván Santiago
> >
> > Information Technologies
> >
> > Office of Management and Budget
> >
> > 787.977.9200 x 4252
> >
> > Calle Cruz 254
> >
> > PO Box 9023228
> >
> > San Juan, PR 00902-3228
> >
> > -66°05'07.25",18°26'54.74"(WGS84)
> >
> >
> >
> > -----Original Message-----
> > From: Diego Guerrero [mailto:diego.guerrero en uclm.es]
> > Sent: Thursday, July 10, 2008 7:28 AM
> > To: Ivan Santiago
> > Subject: Re: gvSIG: Reproyección: Puerto Rico
> >
> >
> >
> > Hola.
> >
> >
> >
> > Aunque un poco tarde, he podido sacar tiempo para hacer unas pruebas más
> > sobre
> >
> > este asunto.
> >
> >
> >
> > En la nueva versión de la extensión de gestión de CRSs (JCRS), que está
> > en
> >
> > fase de pruebas y próxima a su publicación, los parámetros del CRS:3991
> >
> > aparecen como indicas en correos anteriores (false_easting = 152400.3048
> > en
> >
> > metros). Aun así al cargar las capas que adjuntabas se muestran igual que
> > en
> >
> > la versión publicada de gvsig, es decir, cb_hydspc40.shp aparece escalado
> > y
> >
> > desplazado al reproyectarlo en una vista que tenga el CRS EPSG:32161, lo
> > que
> >
> > me hace pensar que la conversión a metros ya se está haciendo
> > internamente en
> >
> > esta versión, aunque en la información del CRS no aparezca así.
> >
> >
> >
> > ¿Tienes algún otro ejemplo de capas en ambos sistemas (EPSG:32161 y
> >
> > EPSG:3991)? ¿Podrías enviármelas para ver si se comportan de la misma
> > manera
> >
> > al reproyectarlas con la nueva versión de la extensión?
> >
> >
> >
> > Saludos,
> >
> >
> >
> >       Diego Guerrero.
> >
> > El Thursday 19 June 2008 12:25:58 escribió:
> > > Hola.
> > >
> > >
> > >
> > > Soy uno de los desarrolladores de la gestión de Sistemas de Referencia
> > > de
> > >
> > > gvSIG.
> > >
> > >
> > >
> > > Disculpe por no haberle atendido antes, pero no me ha sido posible.
> > >
> > > Estoy haciendo algunas pruebas en base a los mensajes que se han
> > >
> > > intercambiado en la lista sobre este asunto. Tan pronto como tenga
> > > alguna
> > >
> > > conclusión se lo comunico.
> > >
> > >
> > >
> > > Saludos,
> > >
> > >
> > >
> > >     Diego Guerrero Sevilla.