[Gvsig_desarrolladores] Driver de postgis. 2 errores y un feature request.
Francisco José Peñarrubia
fpenarru en gmail.com
Mar Oct 5 11:09:37 CEST 2010
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
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
> <http://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 <mailto:jomarlla en cgf.upv.es>
> *To:* Lista de Desarrolladores de gvSIG
> <mailto: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 list
> gvSIG_desarrolladores en listserv.gva.es <mailto:gvSIG_desarrolladores en listserv.gva.es>
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>
>
> --
> Fran Peñarrubia
> Scolab
> www.scolab.es <http://www.scolab.es>
>
> Asociación gvSIG
> www.gvsig.com <http://www.gvsig.com>
>
>
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores en listserv.gva.es <mailto: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
> <mailto: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 <mailto: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 <mailto:gvSIG_desarrolladores en listserv.gva.es>
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>
>
> --
> Fran Peñarrubia
> Scolab
> www.scolab.es <http://www.scolab.es>
>
> Asociación gvSIG
> www.gvsig.com <http://www.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
--
Fran Peñarrubia
Scolab
www.scolab.es
Asociación gvSIG
www.gvsig.com
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listserv.gva.es/pipermail/gvsig_desarrolladores/attachments/20101005/9df552d4/attachment.htm
Más información sobre la lista de distribución gvSIG_desarrolladores