Hola, gracias a los dos por las respuestas. Y sí, tienes razón, el error
era que volví a caer en la implementación el lugar del API... fallo mio,
me pongo a buscar y buscar y si no me fijo caigo en el mismo error sin
darme cuenta.
He decidido poner la opción 2, has dicho que tiene un rendimiento
aceptable así que es más que suficiente y si se asegura que seguirá
aunque cambie la versión sí o sí, prefiero este método y si alguien
viene después que yo al proyecto al menos no tendrá que preocuparse de
nuevo por este problema.
Un saludo y gracias de nuevo a los dos.
El 20-12-2016 04:49 PM, Joaquin Jose del Cerro Murciano escribió:
> El 20 de diciembre de 2016, 11:31, Iago Alonso Alonso <ialo...@enxenio.es>
> escribió:
>
>> Hola, me gustaría saber si se usa algún manager para la clase Converter, ya
>> que en una clase tengo:
>>
>> import org.gvsig.fmap.geom.util.Converter; *Marcado como deprecated*
>>
>> y en una línea se usa:
>>
>> <variable> = Converter.jtsToGeometry(geoJTS); *Marcado como deprecated*
>>
>> Así que buscando por el código he encontrado una clase "Converter.java"
>> ubicada en "org.gvsig.desktop.compat.cdc" ->
>> "org.gvsig.fmap.geom.generalpath.util" marcada como deprecated y otra clase
>> en el mismo directorio llamada "UtilFunctions.java" marcada como deprecated
>> también. He seguido buscando y he encontrado un DefaultGeometryManager
>> (import org.gvsig.fmap.geom.impl.DefaultGeometryManager;) que implementa a
>> GeometryManager, por lo que en el código es el que utilizo:
>>
>> Geometry igeo = null;
>> if (elemento != null) {
>> com.vividsolutions.jts.geom.Geometry geoJTS =
>> elemento.getElementoInfraestructura().getGeometria();
>> try {
>> DefaultGeometryManager geomManager = new DefaultGeometryManager() <- añadida
>> (GeometryManager no tiene ese método)
>> igeo = geomManager.createFrom(geoJTS); <- Da error de "The method
>> createFrom(String) in the type DefaultGeometryManager is not applicable for
>> the arguments (Geometry)"
>>
>> igeo = Converter.jtsToGeometry(geoJTS); **Deprecated** (la que quiero
>> eliminar)
>> } catch (CreateGeometryException e) {
>> e.printStackTrace();
>> }
>>
>> .....................
>>
>> }
>>
>> Pero si voy a la clase "DefaultGeometryManager" (package
>> org.gvsig.fmap.geom.generalpath) veo que hay un método "createFrom" que
>> recibe un "Geometry":
>>
>> public Geometry createFrom(com.vividsolutions.jts.geom.Geometry geom) throws
>> GeometryException {
>> return Converter.jtsToGeometry(geom);
>> }
>>
>> Pero cuando hago geomManager.<buscar métodoDefault> me salen todos los
>> createForm menos ese (sólo me aparecen los de createFrom(String wkt, String
>> srs), createFrom(String wkt) y createFrom(byte[] wkb)) y no tengo acceso a
>> ese. ¿Qué estoy haciendo mal? ¿O es que no se tiene acceso a ese método,
>> aunque está como público?
>
> Hola Iago,
> Como ya he comentado muchas veces, en gvSIG tratamos de mantener separado el
> API de la implementacion.
> Una libreria define el API y otra la implementacion.
> Todo lo que hay en la implementacion que no este definido en la libreria del
> API, este declarado como publico o no es implementacion y no deberia usarse
> si quieres que las cosas te vayan en proximas versiones.
>
> ¿Qué estas haciendo mal?
> Mirar en la implementacion para ver que puedes usar.
> Debes mirar solo en el API.
>
> ¿Es que no se tiene acceso a ese método, aunque este como público?
> Pues no, no se debe tener acceso a el.
> De hecho si no tuvieses el jar de la implementacion declarado con el scope de
> "compile" en el pom (como deberia ser) no te compilaria si tratas de usar
> cosas que son propias de la implementacion y no deberias usar.
>
> Acostumbrate a que usar cosas que no estan en el API pueden desaparecer de
> una version a otra.
>
> Si no recuerdo mal creo que era hasta la version 2.2 que estabamos usando
> nuestra propia implementacion de geometrias basada en un GeneralPath de java
> modificado (ya dudo se fue hasta la 2.2 o la 2.1). Luego pasamos ha hacer una
> implementacion de nuestro API basandonos en la libreria de JTS. Pero nadie te
> garantiza que en un futuro no volvamos a cambiar la implementacion de nuevo.
> Lo que si mantendremos en la medida de lo posible es el API (en la 2.3 hemos
> introducido cambios en el API, mas que nada por que habian algunos errores de
> concepto que se reflejaban en el y hemos decidido subsanarlos hasta donde
> hemos considerado que podiamos hacerlo sin destrozar todo). Con esto que
> quiero decir... pues dos cosas, uno, no uses la implementacion, dos, no
> asumas que debajo de las geometrias de gvSIG hay geometrias de jts ya que eso
> es dependiente de la implementacion actual.
>
> Comentado todo esto...
> ¿ Si tengo una geometria de JTS como la convierto a una geometria de gvSIG ?
> (que es tu problema)
>
> Asi de forma rapida, dos opciones, pero antes de comentarlas hablo de una
> funcionalidad que esta en el manager de geometrias poco usada habitualmente.
>
> La libreria de geometrias tiene como funcionalidad ofrecer un sorporte minimo
> para manejar geometrias. Construirlas, guardarlas, preguntar por sus
> componentes, ... y poco mas.
> ¿ Y que se penso inicialmente dejar fuera ?
> Pues la idea fue que quedaran fuera las distintas operaciones que se pueden
> hacer entre geometrias. Intersecciones, buffers, distancias...
> De hecho en hasta la version 2.2 estaban fuera de la implemetacion de
> geometrias. Si ves en el API de Geometry encuentras cosas como:
>
> public double distance(Geometry other) throws
> GeometryOperationNotSupportedException, GeometryOperationException;
>
> Y puede sonar estraño las excepciones que puede lanzar.
> GeometryOperationNotSupportedException, es lanzada si la implememtacion no
> soporta esa operacion.
>
> Bien y ... ¿ Que tiene que ver eso con tu problema ?
>
> Pues la cosa esta en que en la libreria de geometrias se puede registrar
> operaciones con geometrias. Las mas basicas estan en el API como metodos de
> geometrias, pero ni siquiera eso significa que esten implementadas o que
> esten en la libreria de la implementacion. De hecho en gvSIG 2.2 estaban en
> una libreria aparte.
>
> Actualmente, ademas de las operaciones basicas que hay declaradas en el API
> de Geometry, pueden registrarse otras operaciones, como por ejemplo para
> convertir de y desde geometria-JTS a geometria-gvSIG. En la implementacion
> actual, y supongo que por lo basico de la operacion, mientras se puede
> mantener estaran en proximas versiones de la libreria de geometrias.
>
> Asi que volviendo a la pregunta inicial...
> ¿ Si tengo una geometria de JTS como la combierto a una geometria de gvSIG ?
>
> Dos opciones.
> Opcion 1.
> Pues puedes usar la operacion "fromJTS". Seria algo como:
>
> com.vividsolutions.jts.geom.Geometry jtsgeom = null;
> GeometryManager geomManager = GeometryLocator.getGeometryManager();
>
> // Construimos un contexto de operacion y dejamos en el la geometria
> // que queremos convertir.
> GeometryOperationContext context = new GeometryOperationContext();
> context.setAttribute("JTSGeometry", jtsgeom);
> Geometry geom = (Geometry)
> geomManager.invokeOperation(GeometryManager.OPERATIONS.FROMWKB, context);
>
> Ahora mismo dudo que se este usando en gvSIG esta operacion, asi que si te da
> algun problema puedes comentarlo.
> Y nadie te garantiza que este siempre disponible, es muy probable que si,
> pero...
>
> Opcion 2.
> Esta funcionara siempre, ya que es una funcionalidad basica para gvSIG.
> Usa WKB para construir la geometria de gvSIG.
>
> com.vividsolutions.jts.geom.Geometry jtsgeom = null;
>
> com.vividsolutions.jts.io.WKBWriter jtswriter = new
> com.vividsolutions.jts.io.WKBWriter();
> byte[] bytes = jtswriter.write(jtsgeom);
>
> GeometryManager geomManager = GeometryLocator.getGeometryManager();
> Geometry geom = geomManager.createFrom(bytes);
>
> Mi consejo es que uses la operacion si precisas altas prestaciones. En la
> implementacion de la operacion normalmente intentaremos ser lo mas eficientes
> posible. Si el alto rendimiento no es muy relevante usa WKB. Para que te
> hagas una idea, todo el trasiego de geometrias entre gvSIG y PosgisSQL se
> hace a traves de WKB, pasando por el createFrom(byte[]) del manager, y tiene
> un rendimiento aceptable.
>
> Espero que te sirva
>
> Un saludo
> Joaquin
>
>> Un saludo y gracias.
>> _______________________________________________
>> gvSIG_desarrolladores mailing list
>> gvSIG_desarrolladores@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:
>> https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores [1]
>
> --
> --------------------------------------
> Joaquin Jose del Cerro Murciano
> Development and software arquitecture manager at gvSIG Team
> jjdelce...@gvsig.com
> jjdelce...@gvsig.org
> gvSIG Association
> www.gvsig.com [2]
> www.gvsig.org [3]
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores@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:
> https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
Links:
------
[1]
https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
[2] http://www.gvsig.com
[3] http://www.gvsig.org_______________________________________________
gvSIG_desarrolladores mailing list
gvSIG_desarrolladores@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:
https://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
