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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Mauro Carlevaro
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
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

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

Joaquin Jose del Cerro Murciano
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.



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.

Pero...
digamos que nos inspiramos en cierto software comercial al definir algunas partes
de topologia y nos llevamos alguna deficiencia con ello.
No hay forma simple de hacerle llegar a la accion a que primitiva de la geometria
multiparte hace referencia el error detectado.

Una solucion seria dar soporte a ello.
Podriamos añadir al addLine del report un par de parametros, para indicar el
numero de "primnitiva" dentro de la geometria. Y digo dos, por que como tenemos
dos features, para poder hacer referencia la "primitiva" de una u otra
geometria (por cierto, he visto que no estas pasando al informe la segunda
feature).

  report.addLine(self,
              self.getDataSet1(),
              self.getDataSet2(),
              point1,
              point1,
              feature1.getReference(),
              feature2.getReference(),
              primitive1, # Si no procede -1
              primitive2, # Si no procede -1
              False,
              "The point is not coincident."
  )

De esa forma al implementar la accion "Mantener la feature y eliminar solo el punto"
sabriamos que punto del multipunto habria que eliminar.

No se si ves alguna otra solucion "mas simple".
Espero comentarios al respecto.

Un saludo
Joaquin.

El vie., 28 jun. 2019 a las 15:31, Mauro Carlevaro (<[hidden email]>) 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
[hidden email]
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
[hidden email]
gvSIG Association
www.gvsig.com

_______________________________________________
gvSIG_desarrolladores mailing list
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

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

Joaquin Jose del Cerro Murciano
In reply to this post by Mauro Carlevaro
Hola Mauro,
De nuevo para comentarte alguna cosilla mas.

Insistir en la parte de la documentacion.
He visto que en la parte de la wiki, en la secciones "Algorithm design to solve
the problem." has ampliado la descripcion de lo que hace la regla (+1).
Te da una idea bastante buena de lo que va ha hacer la regla... y la accion
asociada a ella.

Comentar un par de cosas...
Falta describir lo que hara cuando se encuentre con geometrias multiparte.
Supongo que primero ha sido picar el codigo y que ahora actualizas la documentacion.

Ahora mismo la documentacion del wiki, es mas de seguimiento del desarrollo que
estas haciendo; pero hay otra documentacion que para mi es casi mas importante
que esa, y que realmente deberia ir a la par.
La documentacion que el usuario puede leer para saber que hace la regla. La
que esta en el json. Esa es tan importante o mas que la del wiki. Debes tener
en cuenta que eso es con lo que contara el usuario para saber si aplica tu
regla, que resultados va a obtener.

Acuerdate de mantenerla actualizada tambien.
Y si se ha de quedar alguna por actualizar, que no sea esa.

Igual que describes el tema de la tolerancia usando un buffer, describe que
va a pasar cuando encuentre geometrias multiparte.

Un saludo
Joaquin

El vie., 28 jun. 2019 a las 15:31, Mauro Carlevaro (<[hidden email]>) 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
[hidden email]
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
[hidden email]
gvSIG Association
www.gvsig.com

_______________________________________________
gvSIG_desarrolladores mailing list
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

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

Joaquin Jose del Cerro Murciano
In reply to this post by Mauro Carlevaro
Hola Mauro,
de nuevo aqui.

He visto que tienes algunas construcciones del estilo:

  if point1.getGeometryType().getName() == "MultiLineLine2D":
    ...

Para filtrar por el tipo de geometria.
Lo primero que he pensado es que estas haciendo una comparacion por "string" cuando
con un entero parece suficiente. Podrias hacer algo como:

  from org.gvsig.fmap.geom.Geometry.TYPES import MULTILINE
  ...

  if point1.getGeometryType().getType() == MULTILINE:
    ...

Eso dice casi lo mismo...
Oh, el casi... que no se si es bueno o malo.
Tu regla no haria nada con multilineas 3D, o con 2DM.
Para pensar... (aplica tambien a puntos, lineas, ...)
aunque los 2DM si que deberias soportarlo.

Bueno, si no nos importan las dimensiones de la geometria, es decir la regla
opera con 2D igual que con 2DM o 3D, es mas rapido usar la comparacion con el
getType() que con el getName().

Comenta que te parece mejor, pros y contras de una u otra.

Mas cosas para pensar...
(Que no solventa ni la forma que tienes ahora mismo, ni la que te he propuesto
aunque no creo que sea relevante ahora).

Cuando trabajamos con lineas o poligonos...
¿ Solo aceptamos lineas y poligonos, no otros tipos de curvas ni superficies (como
circulos o circunferencias) ?

Vale un "Si, solo lineas o poligonos" ;)

Un saludo
Joaquin

El vie., 28 jun. 2019 a las 15:31, Mauro Carlevaro (<[hidden email]>) 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
[hidden email]
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
[hidden email]
gvSIG Association
www.gvsig.com

_______________________________________________
gvSIG_desarrolladores mailing list
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

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

Joaquin Jose del Cerro Murciano
In reply to this post by Mauro Carlevaro
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 (<[hidden email]>) 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
[hidden email]
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
[hidden email]
gvSIG Association
www.gvsig.com

_______________________________________________
gvSIG_desarrolladores mailing list
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

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

Joaquin Jose del Cerro Murciano
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 (<[hidden email]>) 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 (<[hidden email]>) 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
[hidden email]
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
[hidden email]
gvSIG Association
www.gvsig.com


--
--------------------------------------
Joaquin Jose del Cerro Murciano
Development and software arquitecture manager at gvSIG Team
[hidden email]
gvSIG Association
www.gvsig.com

_______________________________________________
gvSIG_desarrolladores mailing list
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

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

Mauro Carlevaro
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 ([hidden email]) 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 (<[hidden email]>) 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 (<[hidden email]>) 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
[hidden email]
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
[hidden email]
gvSIG Association
www.gvsig.com


--
--------------------------------------
Joaquin Jose del Cerro Murciano
Development and software arquitecture manager at gvSIG Team
[hidden email]
gvSIG Association
www.gvsig.com
_______________________________________________
gvSIG_desarrolladores mailing list
[hidden email]
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

_______________________________________________
gvSIG_desarrolladores mailing list
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

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

Mauro Carlevaro
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 ([hidden email]) 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 ([hidden email]) 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 (<[hidden email]>) 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 (<[hidden email]>) 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
[hidden email]
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
[hidden email]
gvSIG Association
www.gvsig.com


--
--------------------------------------
Joaquin Jose del Cerro Murciano
Development and software arquitecture manager at gvSIG Team
[hidden email]
gvSIG Association
www.gvsig.com
_______________________________________________
gvSIG_desarrolladores mailing list
[hidden email]
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

_______________________________________________
gvSIG_desarrolladores mailing list
[hidden email]
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