From jjdelcerro en gvsig.org Mon Jul 1 17:41:53 2019 From: jjdelcerro en gvsig.org (Joaquin Jose del Cerro Murciano) Date: Mon, 1 Jul 2019 17:41:53 +0200 Subject: [Gvsig_desarrolladores] [SoC] New rules for the Topology Framework in gvSIG Desktop- Reporte semana 5 In-Reply-To: <1561728697115-0.post@n6.nabble.com> References: <1561728697115-0.post@n6.nabble.com> Message-ID: 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 () 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From jjdelcerro en gvsig.org Mon Jul 1 17:59:14 2019 From: jjdelcerro en gvsig.org (Joaquin Jose del Cerro Murciano) Date: Mon, 1 Jul 2019 17:59:14 +0200 Subject: [Gvsig_desarrolladores] [SoC] New rules for the Topology Framework in gvSIG Desktop- Reporte semana 5 In-Reply-To: <1561728697115-0.post@n6.nabble.com> References: <1561728697115-0.post@n6.nabble.com> Message-ID: 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 () 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From jjdelcerro en gvsig.org Mon Jul 1 18:19:42 2019 From: jjdelcerro en gvsig.org (Joaquin Jose del Cerro Murciano) Date: Mon, 1 Jul 2019 18:19:42 +0200 Subject: [Gvsig_desarrolladores] [SoC] New rules for the Topology Framework in gvSIG Desktop- Reporte semana 5 In-Reply-To: <1561728697115-0.post@n6.nabble.com> References: <1561728697115-0.post@n6.nabble.com> Message-ID: 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 () 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From jjdelcerro en gvsig.org Mon Jul 1 18:31:28 2019 From: jjdelcerro en gvsig.org (Joaquin Jose del Cerro Murciano) Date: Mon, 1 Jul 2019 18:31:28 +0200 Subject: [Gvsig_desarrolladores] [SoC] New rules for the Topology Framework in gvSIG Desktop- Reporte semana 5 In-Reply-To: <1561728697115-0.post@n6.nabble.com> References: <1561728697115-0.post@n6.nabble.com> Message-ID: 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 () 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From jjdelcerro en gvsig.org Mon Jul 1 18:49:12 2019 From: jjdelcerro en gvsig.org (Joaquin Jose del Cerro Murciano) Date: Mon, 1 Jul 2019 18:49:12 +0200 Subject: [Gvsig_desarrolladores] [SoC] New rules for the Topology Framework in gvSIG Desktop- Reporte semana 5 In-Reply-To: References: <1561728697115-0.post@n6.nabble.com> Message-ID: 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 () > 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From hectorth23 en gmail.com Tue Jul 2 12:34:22 2019 From: hectorth23 en gmail.com (Hector Tundidor Hernandez) Date: Tue, 2 Jul 2019 12:34:22 +0200 Subject: [Gvsig_desarrolladores] Creation of new topological rules in gvSIG desktop Message-ID: <5d1b3327.1c69fb81.e1352.b786@mx.google.com> Hola Joaquin, Gracias por los comentarios. Ayer por la tarde subí al GitHub, de nuevo, el código rehecho. Efectivamente, la regla que estoy implementando es el equivalente a la que mencionas. También, he empezado, como comentas, con una simplificación para líneas (no multilíneas) con dos extremos. Con la idea general que comentas, ?Para cada linea, compruebo si el extremo solapa (habra que ver que es solapa, podriamos asumir que solapa=intersecta inicialmente) con alguna linea del dataset (incluida ella misma). Si no solapa con nadie se considerara un error. Y esto habra que hacerlo con los dos extremos.? estoy de acuerdo. Ahora bien, respecto a los términos solapar e intersectar lo que hecho es comprobar si los vértices de cada línea a analizar son iguales a los vértices de otras líneas, y me explico. En cada invocación al método check para cada feature1, línea, a analizar, en el caso de índices espaciales, he creado un diccionario considerando, a priori, todos los vértices de la línea como colgados. Tras realizar el query sobre la línea, comparo cada vértice de esa línea con todos los vértices de las líneas resultantes del filtro. En el caso de que haya vértices iguales, se modifica el diccionario poniendo ese vértice como no colgado . Por último, se recorre cada una de las listas generadas y se notifica como error el vértice colgado. Respecto a lo que comentas del query, ayer me ocurrió una circunstancia con el dataset de líneas (testLine2) disponible en el repositorio. La capa tiene 3 líneas A, B y C. El código analiza A con B y C, B con A, y C con A. No considera analizar B con C ni C con B. Entiendo que esto se debe a que el filtro descarta estas opciones por no estar ?próximas?. No he considerado, todavía, poner un buffer. Sin embargo, ¿no habría un riesgo en el código aún definiendo un buffer y darse una situación similar a la comentada? Tampoco he considerado, todavía, el caso de que el extremo de una línea toque alguna parte de sí mismo. De hecho, lo he descartado en el código. Habría que cambiarlo. Respecto a las acciones, las comentaré más adelante. Un saludo Héctor ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From jjdelcerro en gvsig.org Tue Jul 2 16:09:48 2019 From: jjdelcerro en gvsig.org (Joaquin Jose del Cerro Murciano) Date: Tue, 2 Jul 2019 16:09:48 +0200 Subject: [Gvsig_desarrolladores] Creation of new topological rules in gvSIG desktop In-Reply-To: <5d1b3327.1c69fb81.e1352.b786@mx.google.com> References: <5d1b3327.1c69fb81.e1352.b786@mx.google.com> Message-ID: Hola Hector. El mar., 2 jul. 2019 a las 12:34, Hector Tundidor Hernandez (< hectorth23 en gmail.com>) escribió: > Hola Joaquin, > > > > Gracias por los comentarios. Ayer por la tarde subí al GitHub, de nuevo, > el código rehecho. Efectivamente, la regla que estoy implementando es el > equivalente a la que mencionas. También, he empezado, como comentas, con > una simplificación para líneas (no multilíneas) con dos extremos. Con la > idea general que comentas, > > > > ?Para cada linea, compruebo si el extremo solapa (habra que ver que es > > solapa, podriamos asumir que solapa=intersecta inicialmente) con alguna > linea > > del dataset (incluida ella misma). Si no solapa con nadie se considerara > un error. > > Y esto habra que hacerlo con los dos extremos.? > > > > estoy de acuerdo. Ahora bien, respecto a los términos solapar e > intersectar lo que hecho es comprobar si los vértices de cada línea a > analizar son iguales a los vértices de otras líneas, y me explico. En cada > invocación al método check para cada feature1, línea, a analizar, en el > caso de índices espaciales, he creado un diccionario considerando, a > priori, todos los vértices de la línea como colgados. Tras realizar el > query sobre la línea, comparo cada vértice de esa línea con todos los > vértices de las líneas resultantes del filtro. En el caso de que haya > vértices iguales, se modifica el diccionario poniendo ese vértice como no > colgado . Por último, se recorre cada una de las listas generadas y se > notifica como error el vértice colgado. > > No entiendo lo que persigues procesando todos los vertices de las lineas. Solo los extremos de una linea pueden considerarse nodos colgados. Y no importa lo cerca o lejos que estan de otros vertices de otras lineas mientras no intersecten con otra linea. Lo que importa es si tocan o no otra linea, no otro vertice. Imagina dos lineas de un segmento cada una colocadas formando una T; pero con la mala suerte que al usuario que lo digitalizaba se le fue la mano, y no llegan a tocarse las dos lineas. (He añadido un par de vertices mas en el dibujo) A---------B-----C |a | | | b+--------c No importa cuan lejos de un vertice de (ABC) este el vertice (a). Los cuatro vertices (A), (C), (a) y (c) son nodos colgados, y habra que marcarlos como tal solo por que no interseccionan con ninguna linea, mientras que los vertices (B) y (b) nunca seran nodos colgados. Lo unico que tengo que hacer es coger los extremos de cada linea y ver si intersectan con otras lineas. No veo la necesidad de ir recorriendo vertices. Eso ya lo hace la funcion intersects. Luego, cuando haya que aplicar una accion correctora habra que ver cosas. Como aplicando uno tolerancia ver si (a) intersecciona con alguien, y asi saber si puedo emplear la accion de alargar. Ojo, que alargar no alarga hasta un vertice, lo que no esta tan claro es como hay que alargar (probablemente usar la funcion closestPoints sea una buena primera aproximacion) No veo necesidad de hacer nada con los vertices que no son los extremos de una linea. No juegan en esta regla. Solo intervienen los extremos. Si me estoy rayando me avisas. Un saludo Joaquin > > > Respecto a lo que comentas del query, ayer me ocurrió una circunstancia > con el dataset de líneas (testLine2) disponible en el repositorio. La capa > tiene 3 líneas A, B y C. El código analiza A con B y C, B con A, y C con A. > No considera analizar B con C ni C con B. Entiendo que esto se debe a que > el filtro descarta estas opciones por no estar ?próximas?. No he > considerado, todavía, poner un buffer. Sin embargo, ¿no habría un riesgo en > el código aún definiendo un buffer y darse una situación similar a la > comentada? > > > > Tampoco he considerado, todavía, el caso de que el extremo de una línea > toque alguna parte de sí mismo. De hecho, lo he descartado en el código. > Habría que cambiarlo. > > > > Respecto a las acciones, las comentaré más adelante. > > > > Un saludo > > > > Héctor > > > _______________________________________________ > 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From mauroctecno en gmail.com Tue Jul 2 19:13:43 2019 From: mauroctecno en gmail.com (Mauro Carlevaro) Date: Tue, 2 Jul 2019 14:13:43 -0300 Subject: [Gvsig_desarrolladores] [SoC] New rules for the Topology Framework in gvSIG Desktop- Reporte semana 5 In-Reply-To: References: <1561728697115-0.post@n6.nabble.com> Message-ID: 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: From hectorth23 en gmail.com Wed Jul 3 11:24:18 2019 From: hectorth23 en gmail.com (Hector Tundidor Hernandez) Date: Wed, 3 Jul 2019 11:24:18 +0200 Subject: [Gvsig_desarrolladores] Creation of new topological rules ingvSIG desktop In-Reply-To: References: <5d1b3327.1c69fb81.e1352.b786@mx.google.com> Message-ID: <5d1c743b.1c69fb81.eba88.6a7c@mx.google.com> Hola Joaquin, Sí, se que solo intervienen los vértices que están en los extremos de las líneas. Quizá no me expresé bien o la daba por supuesto. En el código aparece un for recorriendo todos los vértices de las líneas porqué empecé con una simplificación para líneas con dos extremos. Ese bloque de código, puede sustituirse por: dictionary[0] = True dictionary[numVertexLine-1] = True Un saludo Héctor De: Joaquin Jose del Cerro Murciano Enviado: martes, 2 de julio de 2019 16:54 Para: Lista de Desarrolladores de gvSIG Asunto: Re: [Gvsig_desarrolladores] Creation of new topological rules ingvSIG desktop Hola Hector. El mar., 2 jul. 2019 a las 12:34, Hector Tundidor Hernandez () escribió: Hola Joaquin,   Gracias por los comentarios. Ayer por la tarde subí al GitHub, de nuevo, el código rehecho. Efectivamente, la regla que estoy implementando es el equivalente a la que mencionas. También, he empezado, como comentas, con una simplificación para líneas (no multilíneas) con dos extremos. Con la idea general que comentas,   ?Para cada linea, compruebo si el extremo solapa (habra que ver que es solapa, podriamos asumir que solapa=intersecta inicialmente) con alguna linea del dataset (incluida ella misma). Si no solapa con nadie se considerara un error. Y esto habra que hacerlo con los dos extremos.?   estoy de acuerdo. Ahora bien, respecto a los términos solapar e intersectar lo que hecho es comprobar si los vértices de cada línea a analizar son iguales a los vértices de otras líneas, y me explico. En cada invocación al método check para cada feature1, línea, a analizar, en el caso de índices espaciales, he creado un diccionario considerando, a priori, todos los vértices de la línea como colgados. Tras realizar el query sobre la línea, comparo cada vértice de esa línea con todos los vértices de las líneas resultantes del filtro. En el caso de que haya vértices iguales, se modifica el diccionario poniendo ese vértice como no colgado . Por último, se recorre cada una de las listas generadas y se notifica como error el vértice colgado. No entiendo lo que persigues procesando todos los vertices de las lineas. Solo los extremos de una linea pueden considerarse nodos colgados. Y no importa lo cerca o lejos que estan de otros vertices de otras lineas mientras no intersecten con otra linea. Lo que importa es si tocan o no otra linea, no otro vertice. Imagina dos lineas de un segmento cada una colocadas formando una T; pero con la mala suerte que al usuario que lo digitalizaba se le fue la mano, y no llegan a tocarse las dos lineas. (He añadido un par de vertices mas en el dibujo)   A---------B-----C          |a          |          |          |        b+--------c No importa cuan lejos de un vertice de (ABC) este el vertice (a). Los cuatro vertices (A), (C), (a) y (c) son nodos colgados, y habra que marcarlos como tal solo por que no interseccionan con ninguna linea, mientras que los vertices (B) y (b) nunca seran nodos colgados. Lo unico que tengo que hacer es coger los extremos de cada linea y ver si intersectan con otras lineas. No veo la necesidad de ir recorriendo vertices. Eso ya lo hace la funcion intersects. Luego, cuando haya que aplicar una accion correctora habra que ver cosas. Como aplicando uno tolerancia ver si (a) intersecciona con alguien, y asi saber si puedo emplear la accion de alargar. Ojo, que alargar no alarga hasta un vertice, lo que no esta tan claro es como hay que alargar (probablemente usar la funcion closestPoints sea una buena primera aproximacion) No veo necesidad de hacer nada con los vertices que no son los extremos de una linea. No juegan en esta regla. Solo intervienen los extremos. Si me estoy rayando me avisas. Un saludo Joaquin     Respecto a lo que comentas del query, ayer me ocurrió una circunstancia con el dataset de líneas (testLine2) disponible en el repositorio. La capa tiene 3 líneas A, B y C. El código analiza A con B y C, B con A, y C con A. No considera analizar B con C ni C con B. Entiendo que esto se debe a que el filtro descarta estas opciones por no estar ?próximas?. No he considerado, todavía, poner un buffer. Sin embargo, ¿no habría un riesgo en el código aún definiendo un buffer y darse una situación similar a la comentada?   Tampoco he considerado, todavía, el caso de que el extremo de una línea toque alguna parte de sí mismo. De hecho, lo he descartado en el código. Habría que cambiarlo.   Respecto a las acciones, las comentaré más adelante.   Un saludo   Héctor   _______________________________________________ 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From jjdelcerro en gvsig.org Wed Jul 3 11:43:00 2019 From: jjdelcerro en gvsig.org (Joaquin Jose del Cerro Murciano) Date: Wed, 3 Jul 2019 11:43:00 +0200 Subject: [Gvsig_desarrolladores] Creation of new topological rules ingvSIG desktop In-Reply-To: <5d1c743b.1c69fb81.eba88.6a7c@mx.google.com> References: <5d1b3327.1c69fb81.e1352.b786@mx.google.com> <5d1c743b.1c69fb81.eba88.6a7c@mx.google.com> Message-ID: El mié., 3 jul. 2019 a las 11:24, Hector Tundidor Hernandez (< hectorth23 en gmail.com>) escribió: > Hola Joaquin, > > > > Sí, se que solo intervienen los vértices que están en los extremos de las > líneas. Quizá no me expresé bien o la daba por supuesto. En el código > aparece un for recorriendo todos los vértices de las líneas porqué empecé > con una simplificación para líneas con dos extremos. Ese bloque de código, > puede sustituirse por: > > > > dictionary[0] = True > > dictionary[numVertexLine-1] = True > No entiendo para que una simplificacion que no tiene en cuenta que una linea no tiene por que coincidir con otra por un punto que no sea uno de sus vertices y ademas complica el codigo. Olvidate del codigo que has hecho y comentame la aproximacion que he propuesto como la ves. Si crees que hay casos que no contempla o se deja algo importante. Y si no es asi, si ves algun problema para su implementacion. Primero tener claro que hay que hacer. Despues ya vemos cual podria ser una implementacion. Un saludo Joaquin > > Un saludo > > > > Héctor > > > > *De: *Joaquin Jose del Cerro Murciano > *Enviado: *martes, 2 de julio de 2019 16:54 > *Para: *Lista de Desarrolladores de gvSIG > > *Asunto: *Re: [Gvsig_desarrolladores] Creation of new topological rules > ingvSIG desktop > > > > > > Hola Hector. > > > > El mar., 2 jul. 2019 a las 12:34, Hector Tundidor Hernandez (< > hectorth23 en gmail.com>) escribió: > > Hola Joaquin, > > > > Gracias por los comentarios. Ayer por la tarde subí al GitHub, de nuevo, > el código rehecho. Efectivamente, la regla que estoy implementando es el > equivalente a la que mencionas. También, he empezado, como comentas, con > una simplificación para líneas (no multilíneas) con dos extremos. Con la > idea general que comentas, > > > > ?Para cada linea, compruebo si el extremo solapa (habra que ver que es > > solapa, podriamos asumir que solapa=intersecta inicialmente) con alguna > linea > > del dataset (incluida ella misma). Si no solapa con nadie se considerara > un error. > > Y esto habra que hacerlo con los dos extremos.? > > > > estoy de acuerdo. Ahora bien, respecto a los términos solapar e > intersectar lo que hecho es comprobar si los vértices de cada línea a > analizar son iguales a los vértices de otras líneas, y me explico. En cada > invocación al método check para cada feature1, línea, a analizar, en el > caso de índices espaciales, he creado un diccionario considerando, a > priori, todos los vértices de la línea como colgados. Tras realizar el > query sobre la línea, comparo cada vértice de esa línea con todos los > vértices de las líneas resultantes del filtro. En el caso de que haya > vértices iguales, se modifica el diccionario poniendo ese vértice como no > colgado . Por último, se recorre cada una de las listas generadas y se > notifica como error el vértice colgado. > > No entiendo lo que persigues procesando todos los vertices de las lineas. > Solo los extremos de una linea pueden considerarse nodos colgados. > Y no importa lo cerca o lejos que estan de otros vertices de otras lineas > mientras no intersecten con otra linea. > Lo que importa es si tocan o no otra linea, no otro vertice. > > Imagina dos lineas de un segmento cada una colocadas formando una T; pero > con la mala suerte que al usuario que lo digitalizaba se le fue la mano, y > no llegan a tocarse las dos lineas. > > (He añadido un par de vertices mas en el dibujo) > > > A---------B-----C > |a > | > | > | > > b+--------c > > > No importa cuan lejos de un vertice de (ABC) este el vertice (a). > > Los cuatro vertices (A), (C), (a) y (c) son nodos colgados, y habra que > marcarlos como tal solo por > que no interseccionan con ninguna linea, mientras que los vertices (B) y > (b) nunca seran nodos colgados. > > Lo unico que tengo que hacer es coger los extremos de cada linea y ver si > intersectan con otras lineas. > > No veo la necesidad de ir recorriendo vertices. Eso ya lo hace la funcion > intersects. > > > > Luego, cuando haya que aplicar una accion correctora habra que ver cosas. > Como aplicando uno tolerancia ver si (a) intersecciona con alguien, y asi > saber > si puedo emplear la accion de alargar. > Ojo, que alargar no alarga hasta un vertice, lo que no esta tan claro es > como hay que alargar (probablemente usar la funcion closestPoints sea una > buena primera aproximacion) > > No veo necesidad de hacer nada con los vertices que no son los extremos de > una > linea. No juegan en esta regla. Solo intervienen los extremos. > > > > Si me estoy rayando me avisas. > > > > Un saludo > > Joaquin > > > > > > > > Respecto a lo que comentas del query, ayer me ocurrió una circunstancia > con el dataset de líneas (testLine2) disponible en el repositorio. La capa > tiene 3 líneas A, B y C. El código analiza A con B y C, B con A, y C con A. > No considera analizar B con C ni C con B. Entiendo que esto se debe a que > el filtro descarta estas opciones por no estar ?próximas?. No he > considerado, todavía, poner un buffer. Sin embargo, ¿no habría un riesgo en > el código aún definiendo un buffer y darse una situación similar a la > comentada? > > > > Tampoco he considerado, todavía, el caso de que el extremo de una línea > toque alguna parte de sí mismo. De hecho, lo he descartado en el código. > Habría que cambiarlo. > > > > Respecto a las acciones, las comentaré más adelante. > > > > Un saludo > > > > Héctor > > > > _______________________________________________ > 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 > > > _______________________________________________ > 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From hectorth23 en gmail.com Wed Jul 3 13:27:56 2019 From: hectorth23 en gmail.com (Hector Tundidor Hernandez) Date: Wed, 3 Jul 2019 13:27:56 +0200 Subject: [Gvsig_desarrolladores] Creation of new topological rules ingvSIGdesktop In-Reply-To: References: <5d1b3327.1c69fb81.e1352.b786@mx.google.com> <5d1c743b.1c69fb81.eba88.6a7c@mx.google.com> Message-ID: <5d1c9135.1c69fb81.49ffa.bc46@mx.google.com> Hola Joaquin, Efectivamente, en la simplificación solo estaba considerando que la intersección fuera con los extremos de otra línea. La aproximación que has comentado anteriormente me parece adecuada. Para cada línea se comprueba si sus extremos intersectan con alguna otra línea del dataset, incluida ella misma. Si no intersecta se considera error. A priori parece que no se deja nada importante y tampoco veo un problema para su implementación. Un saludo Héctor De: Joaquin Jose del Cerro Murciano Enviado: miércoles, 3 de julio de 2019 11:43 Para: Lista de Desarrolladores de gvSIG Asunto: Re: [Gvsig_desarrolladores] Creation of new topological rules ingvSIGdesktop El mié., 3 jul. 2019 a las 11:24, Hector Tundidor Hernandez () escribió: Hola Joaquin,   Sí, se que solo intervienen los vértices que están en los extremos de las líneas. Quizá no me expresé bien o la daba por supuesto. En el código aparece un for recorriendo todos los vértices de las líneas porqué empecé con una simplificación para líneas con dos extremos. Ese bloque de código, puede sustituirse por:   dictionary[0] = True                             dictionary[numVertexLine-1] = True No entiendo para que una simplificacion que no tiene en cuenta que una linea no tiene por que coincidir con otra por un punto que no sea uno de sus vertices y ademas complica el codigo. Olvidate del codigo que has hecho y comentame la aproximacion que he propuesto como la ves. Si crees que hay casos que no contempla o se deja algo importante. Y si no es asi, si ves algun problema para su implementacion. Primero tener claro que hay que hacer. Despues ya vemos cual podria ser una implementacion. Un saludo Joaquin   Un saludo   Héctor   De: Joaquin Jose del Cerro Murciano Enviado: martes, 2 de julio de 2019 16:54 Para: Lista de Desarrolladores de gvSIG Asunto: Re: [Gvsig_desarrolladores] Creation of new topological rules ingvSIG desktop     Hola Hector.   El mar., 2 jul. 2019 a las 12:34, Hector Tundidor Hernandez () escribió: Hola Joaquin,   Gracias por los comentarios. Ayer por la tarde subí al GitHub, de nuevo, el código rehecho. Efectivamente, la regla que estoy implementando es el equivalente a la que mencionas. También, he empezado, como comentas, con una simplificación para líneas (no multilíneas) con dos extremos. Con la idea general que comentas,   ?Para cada linea, compruebo si el extremo solapa (habra que ver que es solapa, podriamos asumir que solapa=intersecta inicialmente) con alguna linea del dataset (incluida ella misma). Si no solapa con nadie se considerara un error. Y esto habra que hacerlo con los dos extremos.?   estoy de acuerdo. Ahora bien, respecto a los términos solapar e intersectar lo que hecho es comprobar si los vértices de cada línea a analizar son iguales a los vértices de otras líneas, y me explico. En cada invocación al método check para cada feature1, línea, a analizar, en el caso de índices espaciales, he creado un diccionario considerando, a priori, todos los vértices de la línea como colgados. Tras realizar el query sobre la línea, comparo cada vértice de esa línea con todos los vértices de las líneas resultantes del filtro. En el caso de que haya vértices iguales, se modifica el diccionario poniendo ese vértice como no colgado . Por último, se recorre cada una de las listas generadas y se notifica como error el vértice colgado. No entiendo lo que persigues procesando todos los vertices de las lineas. Solo los extremos de una linea pueden considerarse nodos colgados. Y no importa lo cerca o lejos que estan de otros vertices de otras lineas mientras no intersecten con otra linea. Lo que importa es si tocan o no otra linea, no otro vertice. Imagina dos lineas de un segmento cada una colocadas formando una T; pero con la mala suerte que al usuario que lo digitalizaba se le fue la mano, y no llegan a tocarse las dos lineas. (He añadido un par de vertices mas en el dibujo)   A---------B-----C          |a          |          |          |        b+--------c No importa cuan lejos de un vertice de (ABC) este el vertice (a). Los cuatro vertices (A), (C), (a) y (c) son nodos colgados, y habra que marcarlos como tal solo por que no interseccionan con ninguna linea, mientras que los vertices (B) y (b) nunca seran nodos colgados. Lo unico que tengo que hacer es coger los extremos de cada linea y ver si intersectan con otras lineas. No veo la necesidad de ir recorriendo vertices. Eso ya lo hace la funcion intersects.   Luego, cuando haya que aplicar una accion correctora habra que ver cosas. Como aplicando uno tolerancia ver si (a) intersecciona con alguien, y asi saber si puedo emplear la accion de alargar. Ojo, que alargar no alarga hasta un vertice, lo que no esta tan claro es como hay que alargar (probablemente usar la funcion closestPoints sea una buena primera aproximacion) No veo necesidad de hacer nada con los vertices que no son los extremos de una linea. No juegan en esta regla. Solo intervienen los extremos.   Si me estoy rayando me avisas.   Un saludo Joaquin       Respecto a lo que comentas del query, ayer me ocurrió una circunstancia con el dataset de líneas (testLine2) disponible en el repositorio. La capa tiene 3 líneas A, B y C. El código analiza A con B y C, B con A, y C con A. No considera analizar B con C ni C con B. Entiendo que esto se debe a que el filtro descarta estas opciones por no estar ?próximas?. No he considerado, todavía, poner un buffer. Sin embargo, ¿no habría un riesgo en el código aún definiendo un buffer y darse una situación similar a la comentada?   Tampoco he considerado, todavía, el caso de que el extremo de una línea toque alguna parte de sí mismo. De hecho, lo he descartado en el código. Habría que cambiarlo.   Respecto a las acciones, las comentaré más adelante.   Un saludo   Héctor   _______________________________________________ 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   _______________________________________________ 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From jjdelcerro en gvsig.org Wed Jul 3 16:35:05 2019 From: jjdelcerro en gvsig.org (Joaquin Jose del Cerro Murciano) Date: Wed, 3 Jul 2019 16:35:05 +0200 Subject: [Gvsig_desarrolladores] Creation of new topological rules ingvSIGdesktop In-Reply-To: <5d1c9135.1c69fb81.49ffa.bc46@mx.google.com> References: <5d1b3327.1c69fb81.e1352.b786@mx.google.com> <5d1c743b.1c69fb81.eba88.6a7c@mx.google.com> <5d1c9135.1c69fb81.49ffa.bc46@mx.google.com> Message-ID: El mié., 3 jul. 2019 a las 13:27, Hector Tundidor Hernandez (< hectorth23 en gmail.com>) escribió: > Hola Joaquin, > > > > Efectivamente, en la simplificación solo estaba considerando que la > intersección fuera con los extremos de otra línea. La aproximación que has > comentado anteriormente me parece adecuada. Para cada línea se comprueba si > sus extremos intersectan con alguna otra línea del dataset, incluida ella > misma. Si no intersecta se considera error. A priori parece que no se deja > nada importante y tampoco veo un problema para su implementación. > Pues a ello. A ver como queda. Y si se te lia lo comentas. Un saludo Joaquin > > Un saludo > > Héctor > > *De: *Joaquin Jose del Cerro Murciano > *Enviado: *miércoles, 3 de julio de 2019 11:43 > *Para: *Lista de Desarrolladores de gvSIG > > *Asunto: *Re: [Gvsig_desarrolladores] Creation of new topological rules > ingvSIGdesktop > > > > > > > > El mié., 3 jul. 2019 a las 11:24, Hector Tundidor Hernandez (< > hectorth23 en gmail.com>) escribió: > > Hola Joaquin, > > > > Sí, se que solo intervienen los vértices que están en los extremos de las > líneas. Quizá no me expresé bien o la daba por supuesto. En el código > aparece un for recorriendo todos los vértices de las líneas porqué empecé > con una simplificación para líneas con dos extremos. Ese bloque de código, > puede sustituirse por: > > > > dictionary[0] = True > > dictionary[numVertexLine-1] = True > > > > No entiendo para que una simplificacion que no tiene en cuenta que una > linea no tiene por que coincidir con otra por un punto que no sea uno de > sus vertices y ademas complica el codigo. > > > > Olvidate del codigo que has hecho y comentame la aproximacion que he > propuesto como la ves. > > Si crees que hay casos que no contempla o se deja algo importante. > > Y si no es asi, si ves algun problema para su implementacion. > > > > Primero tener claro que hay que hacer. > > Despues ya vemos cual podria ser una implementacion. > > > > Un saludo > > Joaquin > > > > > > Un saludo > > > > Héctor > > > > *De: *Joaquin Jose del Cerro Murciano > *Enviado: *martes, 2 de julio de 2019 16:54 > *Para: *Lista de Desarrolladores de gvSIG > > *Asunto: *Re: [Gvsig_desarrolladores] Creation of new topological rules > ingvSIG desktop > > > > > > Hola Hector. > > > > El mar., 2 jul. 2019 a las 12:34, Hector Tundidor Hernandez (< > hectorth23 en gmail.com>) escribió: > > Hola Joaquin, > > > > Gracias por los comentarios. Ayer por la tarde subí al GitHub, de nuevo, > el código rehecho. Efectivamente, la regla que estoy implementando es el > equivalente a la que mencionas. También, he empezado, como comentas, con > una simplificación para líneas (no multilíneas) con dos extremos. Con la > idea general que comentas, > > > > ?Para cada linea, compruebo si el extremo solapa (habra que ver que es > > solapa, podriamos asumir que solapa=intersecta inicialmente) con alguna > linea > > del dataset (incluida ella misma). Si no solapa con nadie se considerara > un error. > > Y esto habra que hacerlo con los dos extremos.? > > > > estoy de acuerdo. Ahora bien, respecto a los términos solapar e > intersectar lo que hecho es comprobar si los vértices de cada línea a > analizar son iguales a los vértices de otras líneas, y me explico. En cada > invocación al método check para cada feature1, línea, a analizar, en el > caso de índices espaciales, he creado un diccionario considerando, a > priori, todos los vértices de la línea como colgados. Tras realizar el > query sobre la línea, comparo cada vértice de esa línea con todos los > vértices de las líneas resultantes del filtro. En el caso de que haya > vértices iguales, se modifica el diccionario poniendo ese vértice como no > colgado . Por último, se recorre cada una de las listas generadas y se > notifica como error el vértice colgado. > > No entiendo lo que persigues procesando todos los vertices de las lineas. > Solo los extremos de una linea pueden considerarse nodos colgados. > Y no importa lo cerca o lejos que estan de otros vertices de otras lineas > mientras no intersecten con otra linea. > Lo que importa es si tocan o no otra linea, no otro vertice. > > Imagina dos lineas de un segmento cada una colocadas formando una T; pero > con la mala suerte que al usuario que lo digitalizaba se le fue la mano, y > no llegan a tocarse las dos lineas. > > (He añadido un par de vertices mas en el dibujo) > > > A---------B-----C > |a > | > | > | > > b+--------c > > > No importa cuan lejos de un vertice de (ABC) este el vertice (a). > > Los cuatro vertices (A), (C), (a) y (c) son nodos colgados, y habra que > marcarlos como tal solo por > que no interseccionan con ninguna linea, mientras que los vertices (B) y > (b) nunca seran nodos colgados. > > Lo unico que tengo que hacer es coger los extremos de cada linea y ver si > intersectan con otras lineas. > > No veo la necesidad de ir recorriendo vertices. Eso ya lo hace la funcion > intersects. > > > > Luego, cuando haya que aplicar una accion correctora habra que ver cosas. > Como aplicando uno tolerancia ver si (a) intersecciona con alguien, y asi > saber > si puedo emplear la accion de alargar. > Ojo, que alargar no alarga hasta un vertice, lo que no esta tan claro es > como hay que alargar (probablemente usar la funcion closestPoints sea una > buena primera aproximacion) > > No veo necesidad de hacer nada con los vertices que no son los extremos de > una > linea. No juegan en esta regla. Solo intervienen los extremos. > > > > Si me estoy rayando me avisas. > > > > Un saludo > > Joaquin > > > > > > > > Respecto a lo que comentas del query, ayer me ocurrió una circunstancia > con el dataset de líneas (testLine2) disponible en el repositorio. La capa > tiene 3 líneas A, B y C. El código analiza A con B y C, B con A, y C con A. > No considera analizar B con C ni C con B. Entiendo que esto se debe a que > el filtro descarta estas opciones por no estar ?próximas?. No he > considerado, todavía, poner un buffer. Sin embargo, ¿no habría un riesgo en > el código aún definiendo un buffer y darse una situación similar a la > comentada? > > > > Tampoco he considerado, todavía, el caso de que el extremo de una línea > toque alguna parte de sí mismo. De hecho, lo he descartado en el código. > Habría que cambiarlo. > > > > Respecto a las acciones, las comentaré más adelante. > > > > Un saludo > > > > Héctor > > > > _______________________________________________ > 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 > > > > _______________________________________________ > 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 > > > _______________________________________________ > 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From hectorth23 en gmail.com Fri Jul 5 19:28:58 2019 From: hectorth23 en gmail.com (Hector Tundidor Hernandez) Date: Fri, 5 Jul 2019 19:28:58 +0200 Subject: [Gvsig_desarrolladores] Creation of new topological rules in gvSIG desktop Message-ID: <5d1f88d8.1c69fb81.c0dd2.9da6@mx.google.com> Hola Comunidad, Estoy intentando, dada una polilínea, comprobar si cada uno de sus extremos intersecta con ella misma, ya sea por sus extremos o en otra parte de ella (Por ejemplo, un cuadrado o en forma de P). Una opción podría ser, quizá, dividir la polilínea en líneas e ir comprobando si intersectan. ¿Es una buena opción o se puede abordar de otra manera? Gracias Un saludo Héctor ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From jjdelcerro en gvsig.org Sat Jul 6 12:45:20 2019 From: jjdelcerro en gvsig.org (Joaquin Jose del Cerro Murciano) Date: Sat, 6 Jul 2019 12:45:20 +0200 Subject: [Gvsig_desarrolladores] Creation of new topological rules in gvSIG desktop In-Reply-To: <5d1f88d8.1c69fb81.c0dd2.9da6@mx.google.com> References: <5d1f88d8.1c69fb81.c0dd2.9da6@mx.google.com> Message-ID: El vie., 5 jul. 2019 a las 19:29, Hector Tundidor Hernandez (< hectorth23 en gmail.com>) escribió: > Hola Comunidad, > > > > Estoy intentando, dada una polilínea, comprobar si cada uno de sus > extremos intersecta con ella misma, ya sea por sus extremos o en otra parte > de ella (Por ejemplo, un cuadrado o en forma de P). Una opción podría ser, > quizá, dividir la polilínea en líneas e ir comprobando si intersectan. ¿Es > una buena opción o se puede abordar de otra manera? > Asi sin pensarlo mucho.... ¿ Y si clonas la linea, y le quitas el segmente del extremo, y compruebas si el punto del extremo intersecta con la linea a la que le has quitado el ultimo segmento ? numVertices = linea0.getNumVertices() si numVertices>2 extremo = linea0.getVertex(0) linea1 = linea0.cloneGeometry() linea1.removeVertex(0) si linea1.intersects(extremo) ... linea0 intersecta con sigo misma sino extremo = linea0.getVertex(numVertices-1) linea1 = linea0.cloneGeometry() linea1.removeVertex(numVertices-1) si linea1.intersects(extremo) ... linea0 intersecta con sigo misma ¿ Que opinas ? ¿ Podira funcionar ? > > Gracias > > > > Un saludo > > > > Héctor > > > > > _______________________________________________ > 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From hectorth23 en gmail.com Sat Jul 6 16:50:21 2019 From: hectorth23 en gmail.com (=?UTF-8?Q?H=C3=A9ctor?=) Date: Sat, 6 Jul 2019 16:50:21 +0200 Subject: [Gvsig_desarrolladores] Creation of new topological rules in gvSIG desktop In-Reply-To: References: <5d1f88d8.1c69fb81.c0dd2.9da6@mx.google.com> Message-ID: Hola, A priori parece una buena aproximación. De esta manera se trataría de otra línea distinta, la intersección no sería con ella misma y no daría los problemas de no notificar ningún error por intersectar siempre en el análisis de cada feature. Gracias Un saludo El sáb., 6 de julio de 2019 12:45, Joaquin Jose del Cerro Murciano < jjdelcerro en gvsig.org> escribió: > > > El vie., 5 jul. 2019 a las 19:29, Hector Tundidor Hernandez (< > hectorth23 en gmail.com>) escribió: > >> Hola Comunidad, >> >> >> >> Estoy intentando, dada una polilínea, comprobar si cada uno de sus >> extremos intersecta con ella misma, ya sea por sus extremos o en otra parte >> de ella (Por ejemplo, un cuadrado o en forma de P). Una opción podría ser, >> quizá, dividir la polilínea en líneas e ir comprobando si intersectan. ¿Es >> una buena opción o se puede abordar de otra manera? >> > Asi sin pensarlo mucho.... > ¿ Y si clonas la linea, y le quitas el segmente del extremo, y compruebas > si el punto del extremo intersecta con la linea a la que le has quitado el > ultimo segmento ? > > numVertices = linea0.getNumVertices() > si numVertices>2 > extremo = linea0.getVertex(0) > linea1 = linea0.cloneGeometry() > linea1.removeVertex(0) > si linea1.intersects(extremo) > ... linea0 intersecta con sigo misma > sino > extremo = linea0.getVertex(numVertices-1) > linea1 = linea0.cloneGeometry() > linea1.removeVertex(numVertices-1) > si linea1.intersects(extremo) > ... linea0 intersecta con sigo misma > > ¿ Que opinas ? > ¿ Podira funcionar ? > > >> >> Gracias >> >> >> >> Un saludo >> >> >> >> Héctor >> >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ > 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: From mauroctecno en gmail.com Sat Jul 6 22:00:31 2019 From: mauroctecno en gmail.com (Mauro Carlevaro) Date: Sat, 6 Jul 2019 17:00:31 -0300 Subject: [Gvsig_desarrolladores] [SoC] New rules for the Topology Framework in gvSIG Desktop- Reporte semana 6 Message-ID: Hola, envío el reporte semanal correspondiente al periodo del 01 al 07 de Julio. Qué pude completar esta semana? · Integración de la regla Points must be covered by line con el marco de topología. · Se continúa mejorando la documentación. · Mejora de la documentación explicando como trabajan las reglas cuando las capas son multiparte · Se profundiza el estudio del código para poder entender como procesar capas con geometría multiparte · Estudio de geometrías en 2D, 2DM y 3D para poder evaluar su implementación Qué voy a hacer la próxima semana? · Estudio de la regla Must be properly inside polygons · Optimizar el algoritmo desarrollado. · Testear y depurar el código desarrollado. · Seguir documentando todo el proceso. · Optimizar los algoritmos y construir funciones para disminuir la repetición de código Hay algún problema, bloqueo? No hay problema de bloqueo. Referencias: Reporte semana 6. Link: https://github.com/Maureque/gvsig-gsoc2019-topology/wiki/5b.-Report-Week-6-(July-1st-to-July-7th) Regla Points must be covered by line. Link: https://github.com/Maureque/gvsig-gsoc2019-topology/wiki/5b.-Report-Week-6-(July-1st-to-July-7th) 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. ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From hectorth23 en gmail.com Sun Jul 7 20:38:58 2019 From: hectorth23 en gmail.com (Hector Tundidor Hernandez) Date: Sun, 7 Jul 2019 20:38:58 +0200 Subject: [Gvsig_desarrolladores] Creation of new topological rules in gvSIG desktop - Weekly Report 6 Message-ID: <5d223c3c.1c69fb81.c0a0f.2a3a@mx.google.com> Hola a todos, He actualizado mi página wiki con el informe semanal 6. Cualquier comentario y sugerencia es bienvenida. ¿Qué completé esta semana? Esta semana he continuado desarrollando el código necesario para implementar la regla must not have dangles. Se ha replanteado la aproximación para resolver el problema y se ha desarrollado el código en base a esta nueva aproximación para el caso de índices espaciales. Además, se han añadido nuevas geometrías al fichero de pruebas para comprobar el funcionamiento de la regla. Los ficheros que contienen la regla y las geometrías son: - mustNotHaveDanglesLineRule.py - testLine.shp rule wiki: https://github.com/hecnita/gvsig-gsoc2019-topology/wiki/Rule-Must-not-have-dangles rule repository: https://github.com/hecnita/TopologyRuleMustNotHaveDanglesLine GSoC 2019 wiki: https://github.com/hecnita/gvsig-gsoc2019-topology/wiki/Creation-of-new-topological-rules-in-gvSIG-desktop ¿Qué voy a realizar la próxima semana? La siguiente semana continuaré con el desarrollo de esta regla. En concreto, se implementarán las acciones definidas en la wiki de la regla para resolver posibles violaciones de la regla. Estas acciones son ?extend?, ?trim? y ?snap?. ¿Hay algún problema de bloqueo? En este momento no hay ningún problema de bloqueo. Saludos Héctor ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From mauroctecno en gmail.com Thu Jul 11 14:15:49 2019 From: mauroctecno en gmail.com (Mauro Carlevaro) Date: Thu, 11 Jul 2019 09:15:49 -0300 Subject: [Gvsig_desarrolladores] [SoC] New rules for the Topology Framework in gvSIG Desktop- Reporte semana 5 In-Reply-To: References: <1561728697115-0.post@n6.nabble.com> Message-ID: 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: From mauroctecno en gmail.com Sun Jul 14 05:49:48 2019 From: mauroctecno en gmail.com (Mauro Carlevaro) Date: Sun, 14 Jul 2019 00:49:48 -0300 Subject: [Gvsig_desarrolladores] [SoC] New rules for the Topology Framework in gvSIG Desktop- Reporte semana 7 Message-ID: Hola, envío el reporte semanal correspondiente al periodo del 08 al 14 de Julio. Qué pude completar esta semana? · Estudio de la regla de topología Must be properly inside polygons. · Se continúa mejorando la documentación. · Continuar mejorando la documentación. · Se profundiza el estudio del código para poder procesar capas con geometría multiparte. · Estudio de geometrías en 2D, 2DM y 3D para poder evaluar su implementación. · Optimización de los algoritmos de las reglas anteriores studio de geometrías en 2D y 2DM para poder evaluar su implementación. Qué voy a hacer la próxima semana? · Terminar implementación de la regla Must be properly inside polygons con el marco de topología. · Optimizar el algoritmo desarrollado. · Testear y depurar el código desarrollado. · Seguir documentando todo el proceso. · Concluir reglas anteriores. Hay algún problema, bloqueo? No hay problema de bloqueo. Pero profundizar el estudio en cuanto a diferentes tipos de geometrías, geometrías particulares y distintas dimensiones ha llevado mucho tiempo y a la vez ha sido muy enriquecedor. Con todo esto se pretende definir el abordaje que se realizará en las reglas. Referencias: Reporte semana 7. Link: https://github.com/Maureque/gvsig-gsoc2019-topology/wiki/6a.-Report-Week-7-(July-8th-to-July-14th) Regla Must be properly inside polygons. Link: https://github.com/Maureque/gvsig-gsoc2019-topology/wiki/6.-Must-be-properly-inside-polygons 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. ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From hectorth23 en gmail.com Sun Jul 14 14:58:43 2019 From: hectorth23 en gmail.com (Hector Tundidor Hernandez) Date: Sun, 14 Jul 2019 14:58:43 +0200 Subject: [Gvsig_desarrolladores] Creation of new topological rules in gvSIG desktop - Informe semanal 7 Message-ID: <5d2b26fc.1c69fb81.f6d50.eca9@mx.google.com> Hola a todos, He actualizado mi página wiki con el informe semanal 7. Cualquier comentario es bienvenido. - ¿Qué completé esta semana? Esta semana he arreglado algunas líneas del código de la regla para que funcione correctamente. También, he añadido nuevos parámetros en el informe del inspector de errores debido a que hay una nueva versión del plugin y poder aprovechar algunos de ellos en el código de la acción extender. Además, en relación con la acción, he intentado encontrar una aproximación para resolver el problema de extender. rule wiki: https://github.com/hecnita/gvsig-gsoc2019-topology/wiki/Rule-Must-not-have-dangles rule repository: https://github.com/hecnita/TopologyRuleMustNotHaveDanglesLine - ¿Qué voy a realizar la próxima semana? En principio, la idea para la próxima semana es continuar desarrollando el código necesario para las acciones de extender y recortar a partir de la aproximación establecida para solucionar el problema. También, modificaré el código de la regla para tener en cuenta algunos aspectos como la tolerancia. - ¿Hay algún problema de bloqueo? Ahora mismo no hay ningún problema. Saludos Héctor ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From hectorth23 en gmail.com Mon Jul 15 12:02:57 2019 From: hectorth23 en gmail.com (Hector Tundidor Hernandez) Date: Mon, 15 Jul 2019 12:02:57 +0200 Subject: [Gvsig_desarrolladores] Creation of new topological rules in gvSIG desktop Message-ID: <5d2c4f48.1c69fb81.12b6b.df9d@mx.google.com> Hola, Estoy intentando encontrar una aproximación para resolver el problema de extender una línea en nodos colgados equivalente a la solución que aparece en el siguiente enlace: https://pro.arcgis.com/es/pro-app/help/editing/geodatabase-topology-rules-for-polyline-features.htm#ESRI_SECTION1_D111AE311AFB4DE4ABA90BC12EE8C605 Para el caso de dado una distancia he pensado que por trigonometría quizá pueda resolverse. Se obtiene la pendiente del último segmento de la línea a extender y con la distancia dada se calcula un nuevo vértice desde el nodo colgado. Con este nuevo vértice se crea una nueva línea y si intersecta con otras líneas se obtiene el punto de intersección más cercano que será el vértice necesario para extender la línea. El problema vendría cuando se introduce una distancia con valor 0. ¿Cómo podría extenderse una línea hasta que se alinee con otra entidad lineal? Gracias Saludos Héctor ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From mauroctecno en gmail.com Fri Jul 19 15:20:39 2019 From: mauroctecno en gmail.com (Mauro Carlevaro) Date: Fri, 19 Jul 2019 10:20:39 -0300 Subject: [Gvsig_desarrolladores] [SoC] New rules for the Topology Framework in gvSIG Desktop- Reporte semana 8 Message-ID: Hola, envío el reporte semanal correspondiente al periodo del 15 al 21 de Julio. Qué pude completar esta semana? · Implementación de la regla de topología Must be properly inside polygons. · Se continúa mejorando la documentación. · Testeo y correción de errores del código de la regla actual y las anteriores. · Optimización de los algoritmos. Qué voy a hacer la próxima semana? · Estudio de la regla Contains point · Optimizar el algoritmo desarrollado. · Testear y depurar el código desarrollado. · Seguir documentando todo el proceso. · Concluir reglas anteriores. Hay algún problema, bloqueo? No hay problema de bloqueo. Referencias: Reporte semana 8. Link: https://github.com/Maureque/gvsig-gsoc2019-topology/wiki/6b.-Report-Week-8-(July-15th-to-July-21st ) Regla Must be properly inside polygons. Link: https://github.com/Maureque/gvsig-gsoc2019-topology/wiki/6.-Must-be-properly-inside-polygons 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From hectorth23 en gmail.com Sun Jul 21 14:03:43 2019 From: hectorth23 en gmail.com (Hector Tundidor Hernandez) Date: Sun, 21 Jul 2019 14:03:43 +0200 Subject: [Gvsig_desarrolladores] Creation of new topological rules in gvSIG desktop - Informe semanal 8 Message-ID: <5d34549c.1c69fb81.d2d9f.c316@mx.google.com> Hola a todos, He actualizado mi página wiki. Cualquier comentario es bienvenido. - ¿Qué he completado esta semana? Esta semana he implementado el código necesario para ejecutar las acciones de extender y recortar. También he realizado la depuración de algunos errores, diferentes pruebas con el fichero de pruebas básico y una optimización de algunas partes del código. Además, he completado la wiki con información relevante para esta regla. Los ficheros correspondientes a estas acciones son: extendAction.py trimAction.py rule wiki: https://github.com/hecnita/gvsig-gsoc2019-topology/wiki/Rule-Must-not-have-dangles rule repository: https://github.com/hecnita/TopologyRuleMustNotHaveDanglesLine Informe semanal 8: https://github.com/hecnita/gvsig-gsoc2019-topology/wiki/Weekly-Report-8 - ¿Qué voy a realizar la próxima semana? La próxima semana empezaré el análisis para la nueva regla ?Must be larger than cluster tolerance? y definiré una aproximación para resolver el problema. También, respecto de la regla ?Must not have dangles?, realizaré una serie de tareas enfocadas a testear la regla y las acciones con otros conjuntos de datos, así como a optimizar y depurar una pequeña parte del código. - ¿Hay algún problema de bloqueo? No hay ningún problema de bloqueo. Saludos Héctor ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From jjdelcerro en gvsig.org Sat Jul 27 12:22:00 2019 From: jjdelcerro en gvsig.org (Joaquin Jose del Cerro Murciano) Date: Sat, 27 Jul 2019 12:22:00 +0200 Subject: [Gvsig_desarrolladores] =?utf-8?q?=5BGvsig=5Fusuarios=5D_Dibujar_?= =?utf-8?q?un_c=C3=ADrculo_con_la_librer=C3=ADa_geom?= In-Reply-To: <393757771.5728654.1564140883439.JavaMail.zimbra@alicante-ayto.es> References: <737241750.4756799.1563884111166.JavaMail.zimbra@alicante-ayto.es> <1393138369.4756900.1563884143596.JavaMail.zimbra@alicante-ayto.es> <393757771.5728654.1564140883439.JavaMail.zimbra@alicante-ayto.es> Message-ID: El vie., 26 jul. 2019 a las 13:39, Montes Cámara, Victor (< victor.montes en alicante-ayto.es>) escribió: > Gracias por la respuesta Joaquín. Por cierto la contesto en la lista de > desarrolladores, ya que me equivoqué y la envié a la de usuarios. > > El problema ahora es dibujar el círculo en una capa. Para ello hago lo > siguiente después de la última instrucción > > schema = createSchema() > schema.append("GEOMETRY", "GEOMETRY") > schema.get('GEOMETRY').setGeometryType(CIRCLE,D2M) > > shape = createShape(schema ,CRS='EPSG:25830') > > shape.edit() > shape.append(GEOMETRY=circulo) > shape.commit() > > currentView().addLayer(shape) > > > Me da el siguiente error de ejecución: > > > Error java.lang.RuntimeException: java.lang.RuntimeException: Error > getting geometry type with type = 11, subtype = 2 in