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. <pumuko...@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: fpena...@gmail.com > To: gvsig_desarrolladores@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: fpena...@gmail.com > To: gvsig_desarrolladores@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 <jomar...@cgf.upv.es> > *To:* Lista de Desarrolladores de gvSIG<gvsig_desarrolladores@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_desarrollado...@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_desarrollado...@listserv.gva.eshttp://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores > > > > ------------------------------ > _______________________________________________ > gvSIG_desarrolladores mailing list > gvSIG_desarrolladores@listserv.gva.es > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores > > > _______________________________________________ > gvSIG_desarrolladores mailing > listgvsig_desarrollado...@listserv.gva.eshttp://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores > > > > _______________________________________________ > gvSIG_desarrolladores mailing > listgvsig_desarrollado...@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@listserv.gva.es > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores > > > _______________________________________________ > gvSIG_desarrolladores mailing > listgvsig_desarrollado...@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@listserv.gva.es > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores > > _______________________________________________ > gvSIG_desarrolladores mailing list > gvSIG_desarrolladores@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
_______________________________________________ gvSIG_desarrolladores mailing list gvSIG_desarrolladores@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores