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 
(<hectort...@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 
(<hectort...@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@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
jjdelce...@gvsig.com
gvSIG Association
www.gvsig.com
 
_______________________________________________
gvSIG_desarrolladores mailing list
gvSIG_desarrolladores@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
jjdelce...@gvsig.com
gvSIG Association
www.gvsig.com

_______________________________________________
gvSIG_desarrolladores mailing list
gvSIG_desarrolladores@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

Responder a