[Gvsig_desarrolladores] Driver de postgis. 2 errores y un feature request.
Nacho Uve
nachouve en gmail.com
Mar Oct 5 11:39:52 CEST 2010
Propongo que si se hace Code-Sprint en Valencia, un apartado sobre el acceso
a PostGis podría caer. :)
El 5 de octubre de 2010 11:34, Daniel L.S. <pumukovic en hotmail.com> escribió:
> Gracias Fran,
> me pondré manos a la obra. Para cualquier duda te iré comentando.
>
> Un saludo!
>
> ------------------------------
> Date: Tue, 5 Oct 2010 11:09:37 +0200
>
> From: fpenarru en gmail.com
> To: gvsig_desarrolladores en listserv.gva.es
> Subject: Re: [Gvsig_desarrolladores] Driver de postgis. 2 errores y un
> feature request.
>
> Bueno, por fín uno que se preocupa por el asunto!!! :-)
>
> De lo del WFS-T, es que me quedé a medias. Tal y como dices, el que hay
> ahora no está pensado para volumenes grandes de datos. Por eso hablé de
> "terminar el driver, o dejarlo fino". Y se me olvidó hablar de un proyecto
> que está terminado pero no integrado en gvSIG, y que estaría muy bien
> meterlo:
>
> http://en.wikipedia.org/wiki/Binary_XML
> http://www.osor.eu/projects/gvsig-bxml
>
> http://www.google.es/url?sa=t&source=web&cd=2&ved=0CBsQFjAB&url=http%3A%2F%2Fgvsig-desktop.forge.osor.eu%2Fdownloads%2Fpub%2Fevents%2Fjornadas-lac%2F1as-jornadas-lac%2Freports%2FgvSIG_y_GeoServer-Rendimiento_optimo_utilizando_GML_binario.pdf&rct=j&q=binary%20xml%20gvsig&ei=XOmqTO6LJ5uP4gbU4JGSCA&usg=AFQjCNHBJNo1yAdeEgpD9IjVELX2dalH5A&sig2=FSNUvTcsyY2Zi2JAsS2cPw&cad=rja<http://www.google.es/url?sa=t&source=web&cd=2&ved=0CBsQFjAB&url=http://gvsig-desktop.forge.osor.eu/downloads/pub/events/jornadas-lac/1as-jornadas-lac/reports/gvSIG_y_GeoServer-Rendimiento_optimo_utilizando_GML_binario.pdf&rct=j&q=binary%20xml%20gvsig&ei=XOmqTO6LJ5uP4gbU4JGSCA&usg=AFQjCNHBJNo1yAdeEgpD9IjVELX2dalH5A&sig2=FSNUvTcsyY2Zi2JAsS2cPw&cad=rja>
>
> De lo de tocar la estrategia, me juego 5 contra 1 a que tus problemas
> vienen por esta clase:
>
> AttrInTableLabelingStrategy
>
> Para pintar, está haciendo esto:
> // limit the labeling to the visible extent
> FBitSet bs =
> layer.queryByRect(viewPort.getAdjustedExtent());
>
> ReadableVectorial source = layer.getSource();
> SelectableDataSource recordSet = layer.getRecordset();
> recordSet.start();
> boolean reproject=layer.getProjection()!=null &&
> !layer.getProjection().getAbrev().equals(
>
> layer.getMapContext().getViewPort().getProjection().getAbrev()) &&
> (layer.getCoordTrans()!=null);
>
>
> if ((idTextField == -1) || (idTextField >=
> recordSet.getFieldCount())) {
> System.err.println("Ha habido un error. Se ha perdido
> el campo de etiquetado. Probablemente por quitar un join o edición
> externa.");
> return;
> }
>
> for(int i=bs.nextSetBit(0); i>=0 && !cancel.isCanceled();
> i=bs.nextSetBit(i+1)) {
> Value[] vv = recordSet.getRow(i);
>
> que es precisamente lo que toqué yo para evitar un acceso por registro a la
> base de datos. Hay que evitar el recordSet.getRow(i), y acceder como se hace
> en la clase GeneralLabellingStrategy:
>
> IFeatureIterator it = method.getFeatureIteratorByLabelClass(layer, lc,
> viewPort, usedFields);
>
> Por otro lado, el método FBitSet bs =
> layer.queryByRect(viewPort.getAdjustedExtent()); no me gusta mucho, ya que
> te obliga luego a recorrer por registro. Eso es lo que cambié en el proyecto
> que te mencioné, para que en los datset que vienen de base de datos, esas
> query devuelvan un FBitSet ya cargado con las Feature consultadas, y no
> tener que iterar luego por la selección registro a registro. Con eso se
> acelera muchísimo las query (peticiones de información, selecciones) a bases
> de datos como Postgis, y también las consultas de selección gráfica.
>
> Lo de tolerante a cortes, lo puedes hacer con el viejo método de cortar la
> conexión mientras tienes una capa de postgis a otro servidor, y ver por
> dónde falla. Ahí capturas la excepción, y pruebas a reconectar de manera
> transparente al usuario, o avisas, o tumbas la capa y la pones en modo
> desconectada o con errores para que el usuario la recargue cuando se asegure
> de que tiene red.
>
> Saludos, y espero que te sirva.
>
> Fran.
>
>
> El 05/10/2010 10:51, Daniel L.S. escribió:
>
> Hola
>
> Estoy totalmente de acuerdo con Jose Carlos en la importancia que debe
> tener el soporte a Postgis por parte de gvSIG. Somos muchos los que sabemos
> de la importancia de basar un desarrollo sobre esta base de datos espacial,
> incluso sólo haciendo uso de una pequeña parte del grandisimo potencial que
> ésta aporta en cuanto a análisis espacial se refiere.
>
> Por esto es una lástima que en desarrollos como el que comenta Julio o en
> el que trabajo yo, nos veamos en la necesidad prácticamente obligada de
> perder este potencial y buscar alternativas en ocasiones que no cubren la
> totalidad de las necesidades que plantea nuestro caso de estudio.
>
> Como desarrollador me comprometo a reportar cualquier solución que pueda
> ayudar a la comunidad al respecto, y agradezco los esfuerzos que menciona
> Fran se harán por solucionar estos problemas.
>
> Ahora bien, en un intento por buscar una solucion inmediata (aunque
> provisional) a los problemas planteados Fran me planteas la posibilidad de
> cambiar la capa postgis por un wfs-t. Te pongo en situación, la capa Postgis
> con la que trabajo tiene del orden de 50000 registros. ¿Es viable cargar en
> un wfs-t una capa con este volumen de datos?, hice unas pruebas y la memoria
> se desbordaba. De todas maneras te comento que no ponemos en edición la capa
> postgis, persistimos en la base de datos por medio de hibernate y solo
> visualizamos dicha capa desde gvSIG. Pero claro, es posible que hayan varios
> clientes editando registros simultaneamente.
>
> Por otra parte, dejando de lado el problema de edición multiusuario, ¿cómo
> puedo como dices *"tunear el driver tocando esa estrategia para conseguir
> evitar los problemas del etiquetado, y si cambias un poquito el driver de
> PostGIS lo puedes hacer tolerante a desconexiones de la red". *?
>
> Un saludo y muchas gracias.
>
> ------------------------------
> Date: Mon, 4 Oct 2010 22:00:28 +0200
> From: fpenarru en gmail.com
> To: gvsig_desarrolladores en listserv.gva.es
> Subject: Re: [Gvsig_desarrolladores] Driver de postgis. 2 errores y un
> feature request.
>
> Hola.
>
> Con vuestro permiso, cambio el asunto del hilo, que luego aparecemos en
> Google con multitud de errores y en realidad son 2 (eso sí, uno de ellos
> aparecerá mucho en conexiones de red inestables).
>
> Yo también opino que el driver de postgis es importantísimo, y cuando tenga
> tiempo intentaré revisar esos 2 errores (para la 1.11, ya lo avanzo). Eso
> sí, en tiempo libre, y de eso no abunda ultimamente.
>
> Ahora bien, también tengo que reconocer que la configuración adecuada para
> lo que se quiere hacer (edición multiusuario, etiquetado, etc) sería usando
> como intermediario Geoserver y/o MapServer. Y en ese caso, esos 2 errores ya
> no son tales, y es la configuración con la que solemos usar siempre gvSIG
> (un fondo cartográfico renderizado por MapServer como WMS y una o varias
> capas que puedes editar por WFS).
> Con eso, y si gvSIG tuviera un cliente WFS-T (Transaccional) más fino,
> estaría solventado la multiedición, ya que el WFS se ocupa del bloqueo de la
> transacción. Se puede hacer, y se puede mejorar, claro.
>
> Lo que quiero decir es que desde este punto de vista (montas una IDE y te
> conectas con gvSIG), el driver de Postgis pierde la relevancia, y corriges
> (bueno, esquivas) los errores asociados a Postgis (que también aparecen en
> Oracle y cualquier otra base de datos, porque no son errores del driver,
> sino más bien de algunas estrategias de pintado, tal y como ya he dicho).
>
> Saludos.
>
> Fran.
>
> El 04/10/2010 21:15, Jose Carlos Martínez Llario escribió:
>
> Hola Julio, parece un trabajo muy interesante el que habéis realizado. Lo
> de PostGIS contra un sistema tradicional, llamemos por ejemplo shape no solo
> tiene su justificación como tu dices en un número elevado de usuarios sino
> en características como incorporación de comportamiento al modelo de datos
> con reglas topológicas o validación de datos espaciales, uso de integridad
> referencial, valores codificados, incluso el uso de tolerancias acordes con
> la escala, etc. Toda estas mejoras no se pueden aplicar a un modelo
> tradicional y son muy útiles incluso para uso monousuario. De ahi mi interés
> y apoyo a la mejora, extensión o ampliación de este tipo de drivers. Creo
> que tenemos que empezar a cambiar todos a este modelo y por ello creo que el
> apoyo de gvSIG es primordial. El IGN ya lo ha empezado ha realizar con su
> BTA, localGIS también. Yo creo que a lo mejor una buena manera de empezar a
> trabajar sería que todos los desarrolladores como tu que han cambiado o
> detectado algún problema e incluso corregido y que conocéis el uso interno
> de este tipo de drivers pongáis vuestros conocimientos en común, quizás en
> algún tipo de evento o algo.
>
> Saludossss
>
>
>
>
>
> On 04/10/2010 20:29, Julio Torres wrote:
>
> José Carlos, me llamo Julio Torres y no soy desarrollador sino usuario. En
> mi organización estamos trabajando con gvSIG+PostGis desde hace un par de
> años y nuestros datos están publicados mediante Geoserver en el geoportal
> www.idejaen.es.
> Efectivamente hemos detectado fallos en PostGis en ciertos aspectos, más
> relacionados con leyendas y publicación (problemas con el juego de
> caracteres y codificación) que en edición. Hace tiempo realizamos una
> prueba puntual de acceso concurrente en edición a la misma tabla y al mismo
> registro desde 5 puestos de trabajo y la verdad es que no nos dió problemas.
> Lo realizamos a traves de la Intranet corporativa. También es cierto que a
> pesar de no haber tenido problemas en dicha prueba no tengo una confianza
> suficiente en la consistencia del entendimiento gvSIG-Postgis como para
> cambiar definitivamente la metodología de trabajo de shape a PostGIS y
> optamos por el sistema tradicional -poco académico pero eficaz- de asignar
> capas en formato shape a usuarios de carga concretos para evitar posibles
> problemas y tener controlados los cambios. Sí estoy totalmente de acuerdo
> contigo en que este aspecto es fundamental para la extensión del uso de
> gvSIG en corporaciones con un elevado número de usuarios de carga y
> actualización de datos.
> Un saludo, J.Torres
>
> ----- Original Message -----
> *From:* Jose C. Martinez-Llario <jomarlla en cgf.upv.es>
> *To:* Lista de Desarrolladores de gvSIG<gvsig_desarrolladores en listserv.gva.es>
> *Sent:* Monday, October 04, 2010 7:42 PM
> *Subject:* Re: [Gvsig_desarrolladores] Driver de postgis. Multitud de
> errores
>
> Hola a todos,
> Bueno yo solo quería animar el desarrollo y mejora de este driver por la
> comunidad, por los desarrolladores de gvSIG, etc.
>
> Considerando que PostGIS es la única base de datos libre con el suficiente
> potencial para al realización de un modelo de datos cartográfico completo,
> mi opinión es que una herramienta que trabaja con cartografía como gvSIG
> debería mejorar el soporte de esta base de datos. Se que gvSIG es quizás la
> primera solución libre en implementación de protocolos OGC y otras tareas
> pero considero que el acceso a una base de datos espacial debería de haber
> tenido quizás una prioridad más alta desde hace años. Es una pena tener que
> seguir muriendo trabajando con shapes y no poder implementar modelos
> cartográficos que al fin y al cabo es la fuente que debe alimentar a un SIG.
> Ójala esta crisis acabe pronto y se puedan abordar proyectos como el que
> comenta Peñarrubia.
>
> Un saludo,
> José Carlos
>
>
> El 04/10/2010 17:04, Francisco José Peñarrubia escribió:
>
> Hola Daniel.
>
> En algún desarrollo que he participado, hemos tenido que "tunear" un
> poquito el driver de PostGIS, tal y como dices (en realidad, no el driver,
> sino la estrategia que usa la capa de PostGIS). En mi caso, el desarrollo no
> fue publicado, ya que publicarlo suponía más días de trabajo (desacoplar el
> código y pasar toda la batería oficial de pruebas), y el código se entregó
> al cliente tal y como especifica la GPL, pero no se incorporó a la rama
> principal de gvSIG.
>
> Tocando esa estrategia puedes conseguir evitar los problemas del
> etiquetado, y si cambias un poquito el driver de PostGIS lo puedes hacer
> tolerante a desconexiones de la red, que es lo que creo que te debe estar
> pasando.
> En cuanto a edición multiusuario, gvSIG no soporta ese tipo de edición.
> Para ello, es necesario utilizar algún tipo de "middleware" que se ocupe de
> procesar las peticiones de los clientes gvSIG, blockear zonas, registros,
> etc. Eso no es un bug, es más bien una Feature Request. Hace tiempo propuse
> un proyecto para realizar esto, pero llegó la crisis y hubo que recortar....
>
> Este correo lo envías a la lista de desarrolladores, así que entiendo que
> tú lo eres. Tienes 2 opciones entonces (bueno, 3. La tercera es utilizar
> otro software, claro).
> La primera es desarrollarlo tú mismo.
> La segunda, contratar el desarrollo, y lo que te ahorres en licencias,
> invertirlo en hacer que gvSIG se adapte a tus necesidades.
>
> Estaría muy bien, y revertiría en el bien de la comunidad.
>
> En cualquier caso, me lo apunto, y si podemos conseguir algo de tiempo (o
> financiación), le daremos un repaso al etiquetado y los errores de
> desconexión para la versión 1.11 (cuando salga).
>
> Saludos.
>
> Fran.
>
>
>
> El 04/10/2010 13:51, Daniel L.S. escribió:
>
> Me gustaria saber en los proyectos que trabajan con capas postgis si han
> resuelto problemas actuales del driver de gvSIG para Postgis. Hay multitud
> de fallos que hacen prácticamente imposible basar un actual desarrollo sobre
> este driver. Actualmente nos planteamos dejar de utilizar bien gvSIG o bien
> utilizar buscar una solución intermedia con la carto en shape, formato que
> no permite cubrir nuestras necesidades.
>
> Algunos de los errores son:
>
> El etiquetado colapsa cursores desconectando el driver. No nos permite
> etiquetar los registros de una capa postgis por evitar estos errores.
> No soporta edición multiusuario, es decir, si desde diferentes clientes se
> interactúa con la capa postgis ( edición y borrado) se producen
> descoordinaciones con los demás clientes en gvSIG.
> Se producen habitualmente errores tipo Can read postgis driver no siendo
> posible reconectar las capas y haciendo necesaria un arranque de la
> aplicación.
>
> Si alguien tiene soluciones a estos errores agradeceria su colaboracion.
> Desarrolladores de gisEIEL, gvSIG carreteras y demás.
>
> Considero que debe madurar el driver de Postgis de gvSIG para considerar a
> gvSIG una buena herramienta GIS.
>
> Un saludo y gracias.
>
>
> _______________________________________________
> gvSIG_desarrolladores mailing listgvSIG_desarrolladores en listserv.gva.eshttp://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>
>
> --
> Fran Peñarrubia
> Scolab
> www.scolab.es
>
> Asociación gvSIGwww.gvsig.com
>
>
> _______________________________________________
> gvSIG_desarrolladores mailing listgvSIG_desarrolladores en listserv.gva.eshttp://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>
>
>
> ------------------------------
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores en listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>
>
> _______________________________________________
> gvSIG_desarrolladores mailing listgvSIG_desarrolladores en listserv.gva.eshttp://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>
>
>
> _______________________________________________
> gvSIG_desarrolladores mailing listgvSIG_desarrolladores en listserv.gva.eshttp://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>
>
> --
> Fran Peñarrubia
> Scolab
> www.scolab.es
>
> Asociación gvSIGwww.gvsig.com
>
>
> _______________________________________________ gvSIG_desarrolladores
> mailing list gvSIG_desarrolladores en listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>
>
> _______________________________________________
> gvSIG_desarrolladores mailing listgvSIG_desarrolladores en listserv.gva.eshttp://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>
>
> --
> Fran Peñarrubia
> Scolab
> www.scolab.es
>
> Asociación gvSIGwww.gvsig.com
>
>
> _______________________________________________ gvSIG_desarrolladores
> mailing list gvSIG_desarrolladores en listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores en listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>
>
--
Juan Ignacio Varela García
Consultor en tecnologías SIG
Analista-Desarrollador FLOSS
Oficina Técnica Sistemas Información Xeográfica
Consellería de Medio Ambiente, Territorio e Infraestructuras
Dirección Xeral Sostibilidade e Paisaxe (Xunta de Galicia)
http://www.cmati.xunta.es
Tfno: 981.54.17.02
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listserv.gva.es/pipermail/gvsig_desarrolladores/attachments/20101005/53bf6798/attachment.htm
Más información sobre la lista de distribución gvSIG_desarrolladores