[Gvsig_desarrolladores] [SoC] New rules for the Topology Framework in gvSIG Desktop- Reporte semana 5

Jue Jul 11 14:15:49 CEST 2019

 Hola, agradezco a Joaquin y Óscar que me hicieron notar que omiti agregar
la lista de correo de la comunidad en el intercambio que hemos estado
teniendo para resolver el tratamiento de geometrías multiparte y algunas
dudas que se me han ido planteando. En base a todo esto me encuentro
analizando la lógica implementada para cada una de las reglas.
Agradeciendo desde ya cualquier sugerencia o aporte.
Saludos
Mauro

------------------------------

Hola Mauro,
te voy comentando algunas cosas en varios correos.

En este sobre las geometrias multiparte.

He visto que has introducido el que las dos reglas puedan trabajar con
geometrias
multiparte (multipoint y multiline).

Introducir esto, ademas de la correcta implementacion de las reglas y
acciones
asociadas a ellas, plantea algun problema extra, que no se si se da en tu
caso,
aunque es facil que si.

Primero te comento lo facil.
Para mustBeCoincidentWithPointRule, has declarado en su factoria que acepte
multipoint para su segundo dataset. Creo que si te entra un multipoint ahi
tu
codigo no dara los resultados esperados.
Tambien habra algun problema cuando no se pueden usar indices espaciales.
Creo que ambas cosas pueden ser sencillas de corregir, asi que echa un
vistazo
al codigo y me comentas cual es el problema y como solucionarlo.
Espero que me digas algo de esto.

Cuando es una geometría simple se le pasa los índices espaciales de la
geometría en cuestión pero no tengo claro qué sucede cuando es multiparte, por
ejemplo:
geometrias multiparte....
Un MULTIPOINT, MULTILINE o MULTIPOLYGON. Significa, que en lugar de ser un
punto son una coleccion de puntos; pero la coleccion entera en si es una
sola geometria.
Por ejemplo, se quiere representar el perfil de un pais. No siempre podre
hacerlo con un solo poligono. Si el pais tiene islas, por ejemplo,
necesitare un poligono por cada isla, y todos los poligonos los agrupare en
una sola geometria de tipo MULTIPOLYGON.

Las geometrias multi-parte son geometrias compuestas geometrias primitivas
o simples.

Tampoco hay que perder de vista, que la unidad con la que trabaja el marco
de topologia, no es la geometria. Es la feature. Que se corresponderia con
todas las columnas de la tabla sobre la que estamos trabajando.

No hay que perder de vista que alterar una geometria multiparte, eliminando
algunas de las partes de esta, puede dejar valores incongruentes en el
resto de atributos de la feature. Asi que ese tipo de decisiones siempre
debe tomarlas el usuario.

Volviendo al ejemplo de los paises, supongamos que una columna es la
poblacion. Si elimino una isla, puede que la poblacion ya no se corresponda
con el area que delimita la geometria.

Entonces lo que tenemos es:
>
> public TopologyReportLine addLine(
>
> TopologyRule rule,
>
> TopologyDataSet dataSet1,
>
> TopologyDataSet dataSet2,
>
> Geometry geometry,
>
> Geometry error,
>
> FeatureReference feature1,
>
> FeatureReference feature2,
>
> boolean exception,
>
> String description
>
> );
>
>
> De lo anterior no entiendo, la parte de geometry, geometry es la propia
> geometría que se está analizando pero por qué se pasa dos veces la
> geometría?
>
>
>
Primero entendamos que son esos dos argumentos.
Ninguno de ellos son la geometria que estas procesando. Puede coincidir;
pero no lo son.
El primero, "geometry" representa el/los "objetos" sobre los que se ha
producido el error. Muchas veces sera la geometria de entrada, pero otras
puede que sea
mas adecuado que sean otra cosa. Por ejemplo, una capa de poligonos y
queremos comprobar que no se solapan. Cuando encontramos dos poligonos que
se solapan, la geometria asociada al informe
de error, podria ser el primer poligono, o el segundo, o los dos, ya que
los dos estan involucrados. Tu decides en cada regla que vas a poner en esa
geometria para que el usuario se haga una idea de que esta pasando.

¿ Y el segundo argumento de tipo geometria, error ?
Pues este una geometria que representa al error que se ha dado. Por
ejemplo, con el solape de poligonos estaria bien que fuese una geometria
que represente el area que solapan. Esta se presentara "en rojo" al usuario.

Decidir que va en cada una de estas geometrias para una regla dada forma
parte del analisis que se haga sobre la regla.
Cuando pienso voy ha hacer tal regla topologica, debo pensar, en cuales van
a ser mis datos de entrada, de que tipo. Una descripcion clara en lenguaje
de usuario sobre que va ha comprobar la regla y que va a considerar un
error.
Que va a añadir al informe de errores para que el usuario identifique bien
el problema. Y que acciones correctoras tendra disponibles el usuario ante
un error.

Con esto quiero decir que el valor de estas dos geometrias no es algo a
tomar a la ligera e improvisar mientras codifico. He de pensarlo cuando
analizo lo que  voy ha hacer, y decirdir que voy a poner para cada regla.
No hay atajos, hay que pensarlo.

En el siguiente if cuando no se trabaja con multipartes:
report.addLine(self,
self.getDataSet1(),
self.getDataSet2(),
point1,
point1,
feature1.getReference(),
None,
False,
"The point is not coincident."
)

if ….:

report.addLine(self,

self.getDataSet1(),

self.getDataSet2(),

point1.getPointAt(i),

point1.getPointAt(i),

feature1.getReference(),

None,

False,

"The point is not covered by endpoint."

)

Lo otro mas complicado...
Si llega un multipoint en el primer dataset y alguno de sus puntos no
coincide con un punto del segundo dataset... ¿ que acciones tendria
disponibles ?
Podria:
- Eliminar la feature entera, todo el multipoint, que es lo que has
implementado. O todos los puntos del multipoint coinciden con alguno del
segundo dataset o si hay alguno que no los elimino todos.

- Mantener la feature y eliminar solo el punto del multipoint que no
coincide con ninguno del segundo dataset. Esto plantea hilar mas fino... ¿
Y si se   eliminan todos los puntos del multipoint ? ¿ Borramos entonces la
feature entera ?

No se trata ahora de decidir si me gusta mas una accion que la otra, son
dos acciones perfectamente razonables por parte de un usuario.

Deberiamos implementar las dos.

Mi idea sería eliminar solo el punto del multipoint pero no tengo claro
como hacerlo, sigo probando para entender mejor. Si se eliminan todos los
puntos del multipoint me parece que se eliminaría la feature entera ?

Bueno, mas arriba he comentado sobre multipaters y features.

Eliminar la feature es eliminar no solo la parte geometrica de ella, es
eliminar la linea de la tabla.

Y aqui vuelvo a insitir.
La unidad es la feature, una linea de una tabla.
La geometria es solo un atributo de la feature, sea simple o multiparte, es
solo un atributo de esta.

Por ejemplo, una tabla de puntos que identifican a vehiculos. Cada linea de
mi tabla tendra la matricula, el seguro del coche, cuantos asientos lleva,
quien es el propietario... y su posicion, por ejemplo.

Si mi regla decide que hay que eliminar la geometria, por que no se
superpone, por ejemplo con una carretera, estoy eliminando toda la feature
completa.

Cuando trabajo con multipartes, tengo opcion de bien eliminar la feature
entera, o eliminar una parte de la geometria. Y eso significa que el
usuario debe tener las dos opciones. Nosotros, cuando estamos codificando
la regla, no conocemos la semantica de los datos de la feature, y no
podemos tomar la decicion de descartar una de las dos opciones.

Feature son los atributos, columnas, asociadas a una linea de la tabla (y
la geometrias no es mas que un atributo mas).

El mar., 2 de jul. de 2019 a la(s) 14:13, Mauro Carlevaro (
mauroctecno en gmail.com) escribió:

> Hola, Joaquín muchas gracias por todos los comentarios y las
> explicaciones, hay algunas consultas que las había hablado con Óscar pero
> me comentó que las iba a entender mejor en breve ya que está armando un
> documento para ayudarnos a entender en profundidad todo el código, porque
> hay cosas que las solucione en base al código desarrollado por ti y por
> Óscar pero tenía algunas dudas. Termino de procesar bien toda la
> información que nos pones en el mail y sobre todo hacer algunas pruebas
> más, ya que con la parte de geometrías multi tengo dudas, así contesto con
> más propiedad y les planteo las dudas que me queden, gracias!!!!
> Saludos
> Mauro.
>
> El lun., 1 de jul. de 2019 a la(s) 13:49, Joaquin Jose del Cerro Murciano (
> jjdelcerro en gvsig.org) escribió:
>
>> Hola Mauro, Hector...
>> no se si Oscar os ha comentado algo al respecto.
>>
>> Cuando estais desarrollando haceis...
>>
>> Analisis...
>> Simplificando, que vamos ha hacer y como.
>>
>> Implementacion, testing, documentacion, commits...
>> El trabajo diario mientras lo vamos acabando.
>>
>> Pull requests...
>> Devolvemos al proyecto padre los cambios en nuestro proyecto.
>>
>> Y... falta una cosa mas.
>> ¿ Como podemos pasar a otros usuarios lo que hemos hecho para que lo
>> prueben ?
>> Nos falta...
>> Generar paquetes de instalacion.
>>
>> No se si Oscar os paso enlace a como hacerlos, asi que os dejo aqui un
>> enlace
>> donde cuenta muy rapidamente como hacerlo.
>>
>>
>> https://github.com/jjdelcerro/HelloWorld/blob/master/doc/publish_my_script-es.rst#crear-una-release
>>
>> Haceis el paquete de la regla que mas avanzada tengais y pasarme el
>> enlace al
>> fichero gvspki en GitHub para que pruebe a subirlo al repositorio de
>> paquetes
>> de gvSIG desktop 2.5 y asi comprobar que un usuario podria instalarselo y
>> funciona.
>>
>> Un saludo
>> Joaquin
>>
>> El lun., 1 jul. 2019 a las 18:31, Joaquin Jose del Cerro Murciano (<
>> jjdelcerro en gvsig.org>) escribió:
>>
>>> Hola Mauro...
>>> Tanto en mustBeCoincidentWithPointRule como en
>>> mustBeCoveredByEndpointOfPointRule
>>> has ido metiendo codigo para gestionar los multiparte... echale una
>>> ojeada,
>>> repetir dos, o tres lineas de codigo vale, pero cuando son ya treinta,
>>> creo que
>>> toca sacar un metodo o funcion para ello.
>>>
>>> Por ejemplo, en mustBeCoincidentWithPointRule, la parte que:
>>>
>>> - hace el buffer
>>> - lanza el query
>>> - calcula si los puntos debueltos por el query estan en el buffer
>>> - añade al informe de errores el error si se da.
>>>
>>> podria ir a un metodo que se encargue de calcular eso, y luego
>>> podria usarse en mas de un sitio.
>>>
>>> Ademas, las correcciones, en caso de que las hayan, afectaran solo a un
>>> sitio,
>>> y no alla donde se repita el codigo.
>>>
>>> Tienes algo parecido en el mustBeCoveredByEndpointOfPointRule, solo que
>>> aqui
>>> aun son mas las lineas duplicadas.
>>>
>>> Si le echas un vistazo y no lo ves claro comentalo por aqui.
>>>
>>> Un saludo
>>> Joaquin
>>>
>>> El vie., 28 jun. 2019 a las 15:31, Mauro Carlevaro (<
>>> mauroctecno en gmail.com>) escribió:
>>>
>>>> Hola, envío el reporte semanal correspondiente al periodo del 24 al 30
>>>> de
>>>> Junio.
>>>>
>>>> Qué pude completar esta semana?
>>>> * Estudio de la regla Points must be covered by line
>>>> * Se agregó la consideración de que se tenga multipuntos en la regla
>>>> Must be
>>>> coincident with.
>>>> * Desarrollo de la primera parte del código de la regla Points must be
>>>> covered by lin para la integración.
>>>> * Se continuó mejorando la documentación, se agrego una sección sobre el
>>>> plan de testing.
>>>>
>>>> Qué voy a hacer la próxima semana?
>>>> * Realizar la integración de la regla Points must be covered by line
>>>> con el
>>>> framework de topología.
>>>> * Optimizar el algoritmo desarrollado.
>>>> * Testear y depurar el código desarrollado.
>>>> * Seguir documentando todo el proceso.
>>>>
>>>> Hay algún problema, bloqueo?  No hay problema de bloqueo.
>>>>
>>>> Referencias:
>>>>     Reporte semana 5. Link:
>>>>
>>>> https://github.com/Maureque/gvsig-gsoc2019-topology/wiki/5a.-Report-Week-5-(June-24th-to-June-30th)
>>>>     Regla Points must be covered by line. Link:
>>>>
>>>> https://github.com/Maureque/gvsig-gsoc2019-topology/wiki/5.-Points-must-be-covered-by-line
>>>>     Wiki GitHub, link:
>>>> https://github.com/Maureque/gvsig-gsoc2019-topology/wiki
>>>>     Wiki OSGeo, link:
>>>>
>>>> https://wiki.osgeo.org/wiki/New_rules_for_the_Topology_Framework_in_gvSIG_Desktop
>>>>
>>>> Saludos,
>>>> Mauro
>>>>
>>>>
>>>>
>>>> --
>>>> Sent from:
>>>> http://osgeo-org.1560.x6.nabble.com/gvSIG-desarrolladores-f4163512.html
>>>> _______________________________________________
>>>> gvSIG_desarrolladores mailing list
>>>> gvSIG_desarrolladores en 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
>>>>
>>>
>>>
>>> --
>>> --------------------------------------
>>> Joaquin Jose del Cerro Murciano
>>> Development and software arquitecture manager at gvSIG Team
>>> jjdelcerro en gvsig.com
>>> gvSIG Association
>>> www.gvsig.com
>>>
>>
>>
>> --
>> --------------------------------------
>> Joaquin Jose del Cerro Murciano
>> Development and software arquitecture manager at gvSIG Team
>> jjdelcerro en gvsig.com
>> gvSIG Association
>> www.gvsig.com
>> _______________________________________________
>> gvSIG_desarrolladores mailing list
>> gvSIG_desarrolladores en 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
>>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listserv.gva.es/pipermail/gvsig_desarrolladores/attachments/20190711/9154fb39/attachment.html>