[Gvsig_desarrolladores] Driver de postgis. 2 errores y un feature request.
Daniel L.S.
pumukovic en hotmail.com
Mar Oct 5 11:34:28 CEST 2010
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
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:
Cuerpo del mensaje
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
To: Lista
de Desarrolladores de gvSIG
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
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
--
Fran Peñarrubia
Scolab
www.scolab.es
Asociación gvSIG
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
gvSIG_desarrolladores mailing list
gvSIG_desarrolladores en listserv.gva.es
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listserv.gva.es/pipermail/gvsig_desarrolladores/attachments/20101005/38dd6386/attachment.htm
Más información sobre la lista de distribución gvSIG_desarrolladores