[Gvsig_desarrolladores] problema con geometrías

[Fernando González Cortés]

Hola Fran, 

Este es mas fluido... Busca los comentarios entre tu correo, hay 3 ;).

El vie, 23-12-2005 a las 09:27, Francisco José escribió:
> Hola Fernando.
> 
> Buf, qué denso!!!.
> 
> Vayamos por partes (o multipartes :-) 
> 
> En gvSIG NO se representan los polígonos según esa regla, la de las
> agujas del reloj. Se usa el GeneralPathX famoso, que lo único que hace
> es usar doubles en lugar de float, como ya sabes. Y otro pequeño
> cambio que hiciemos es que cuando se crea, se crea con la regla
> WIND_NON_ZERO.
> 
> De la documentación de Java:
> 
> 
> An EVEN_ODD winding rule means that enclosed regions of the path
> alternate between interior and exterior areas as traversed from the
> outside of the path towards a point inside the region. 
> 
> A NON_ZERO winding rule means that if a ray is drawn in any direction
> from a given point to infinity and the places where the path
> intersects the ray are examined, the point is inside of the path if
> and only if the number of times that the path crosses the ray from
> left to right does not equal the number of times that the path crosses
> the ray from right to left. 
> 
> El motivo es precisamente ese que apuntas. El permitir agujeros dentro
> de multipolígonos, y que haya una regla que lo permita. Si no se hace
> así, efectivamente, no se dibujan bien los agujeros en algunos
> polígonos que vienen de los shapes.
> 
> Y ahora, a lo gordo.
> 1.- Efectivamente, en JTS no usan la misma regla, y hasta ahora no lo
> habíamos tenido en cuenta porque no nos habíamos encontrado con
> polígonos guardados sin chequear antes el órden de los puntos. Vicente
> estos días se ha encontrado con ese problema, y tienes razón, el
> FConverter no lo tiene en cuenta. La solución que hemos adoptado es
> usar la llamada que hay dentro de la clase CGAlgorithms.isCCW() del
> JTS (es decir, comprobar si un array de puntos es "CounterClockWise" o
> no). Si no cumple con lo que queremos, le damos la vuelta 
> al array antes de crear el polígono, y ya se puede guardar. Es decir,
> que creo que hemos llegado a lo mismo que apuntas.

Yo esto lo solucioné en la creación de la geometría, pero será más
óptimo como lo habeis hecho vosotros, supongo que me podré a rueda
cuando salga la 0.6...

> 
> 2.- En cuanto a esto, pues salvo lo del GeneralPathX con la regla
> NON_ZERO, que es la que permite lo de los agujeros en multipolígono,
> también tienes razón. Cuando implementaron JTS, se dieron cuenta que
> para algunos algoritmos necesitaban hacer ciertas suposiciones que no
> estaban en la norma del OGC. El resultado es que las entidades JTS son
> un poquito diferentes a la norma (son cosas que pasan cuando te pones
> a implementar y te das de narices con la realidad), y tendremos que
> tener cuidado con ese tipo de cosas en la edición (pero qué te voy a
> contar a tí :-). El documento donde explica todo esto de las
> suposiciones que hace JTS y que son un poco distintas, para el resto
> de la gente que lo quiera consultar está en:
> http://www.vividsolutions.com/jts/bin/JTS%20Technical%20Specs.pdf
> 
> En este documento, al principio de todo pone:
> JTS attempts to implement the OpenGIS Simple Features Specification
> (SFS) as accurately
> as possible. In some cases the SFS is unclear or omits a
> specification; in this case JTS
> attempts to choose a reasonable and consistent alternative.
> Differences from and
> elaborations of the SFS are documented in this specification.
> The detailed documentation of the class hierarchy and methods will be
> presented in the
> form of JavaDoc for the source code.
> 
> Y luego, por debajo explica todo eso con mucho más detalle.

ok, gracias por la info

sólo me queda pues la duda del shapefile, de la serie de aros en la que
no se puede saber qué agujero es de qué borde...

> 
> 3.- Sí, hace eso. Y por lo que comentas, debe provocar problemas, pero
> no sabemos exáctamente dónde, si puedes concretar.... Supongo que la
> solución sería poner un nuevo hijo a FShape que sea el FMultiPolygon,
> pero el caso es que cuando hice las pruebas con el GeneralPathX, vi
> que se pintaba bien, que se podía seleccionar con él y todo eso, y
> pensé que no ibamos a necesitar distinguir entre un polígono simple y
> uno compuesto. Ahora habrá que replantearlo, porque supongo que
> simplificaría la conversión hacia y desde el JTS, aunque complicaría
> la creación de las entidades, y si lo hacemos para dibujar, pues
> ralentizará la aplicación un poquito. Igual se podría meter esas
> comprobaciones justo antes de convertir, dentro de la clase
> FConverter. ¿Qué opinas?

Vale, este problema sea posíblemente sólo mío, aunque conviene que lo
tengais en cuenta. Creo recordar que al editar postGIS, y terminar la
edición creo una serie de comandos SQL (INSERT, UPDATE y DELETE) que
actualizan la tabla. Obtengo la geometría en JTS y luego obtengo la
representación en WKT. De esa manera obtengo "Polygon(...)" en una tabla
de multipolígonos y eso viola restricciones de la tabla de postgis ya
que no se puede insertar un polígono en una tabla de multipolígonos. No
se si es exactamente así, pero por ahí van los tiros.

saludos y feliz navidad a todos...


> 
> Un saludo, y espero que nos veamos pronto.
> 
> Au.
> 
> Fernando González Cortés escribió: 
> > Defino un par de términos y empiezo:
> > borde = aro externo de un polígono 
> > agujero = aro interno que define un agujero dentro de un borde
> > 
> > Corregidme si me equivoco:
> > 
> > En gvSIG representais los polígonos de la misma manera que el shapefile:
> > El orden de los vértices es contrario a las agujas del reloj para los
> > agujeros y al revés para los bordes. Esto lo entiende así el FConverter,
> > así que toda capa de polígonos que no siga este modelo fallará al
> > realizar alguna operación que requiera JTS. 
> > 
> > Lo primero es que todo formato deberá devolver los polígonos y
> > multipolígonos según ese modelo y que por tanto los que vengan de dxf,
> > postgis, etc tendrán que transformarse ya que en postgis por lo menos no
> > es necesario almacenar los polígonos con los vértices en un orden
> > determinado. Incluso tendrán que transformarse algunos shapefiles que no
> > sigan estrictamente la especificación.
> > 
> > Lo segundo es que creo que en la especificación de shapefile te viene
> > una serie de aros. De estos, sabes cuál es un agujero y cual es un borde
> > por la orientación de los polígonos. Lo que no sabes es qué agujero
> > pertenece a qué borde si no compruebas la relación topológica. Aun
> > comprobandola, puede ser que un agujero pueda pertenecer a varios bordes
> > si estos se solapan. La consecuencia de esto es que no se puede
> > almacenar sin pérdida de información un multipolígono con agujeros en
> > shapefiles. Esto me parece raro, siendo el shapefile tan usado... Pero
> > leyendo la especificación es lo que me viene a la cabeza. Una dato que
> > me parece importante es que JTS no da como válido un multipolígono cuyos
> > polígonos tengan varios puntos en común, igual esto responde a alguna
> > especificación y shapefile se basa en ésta. Basándose en esto los bordes
> > no podrían solapar y sí se podría averiguar qué agujero pertenece a qué
> > borde.
> > 
> > Y lo tercero es un detalle del FConverter, que devuelve Polygon de JTS
> > si es un multipolígono de un elemento y Multipolygon de JTS si es un
> > multipolígono de varios polígonos. Esto es debido en parte al código de
> > FConverter y en parte a que no se distingue polígonos de multipolígonos
> > 
> > Saludos a todos
> > Fernando
> > 
> > 
> >   
> > 
> > ____________________________________________________________________
> > _______________________________________________
> > gvSIG_desarrolladores mailing list
> > gvSIG_desarrolladores en runas.cap.gva.es
> > http://runas.cap.gva.es/mailman/listinfo/gvsig_desarrolladores
> >   
> 
> 
> -- 
> Francisco José Peñarrubia
> Equipo gvSIG
> 
> IVER T.I. S.A.
> c/Salamanca 50
> 46005 Valencia
> Spain
> 
> ______________________________________________________________________
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores en runas.cap.gva.es
> http://runas.cap.gva.es/mailman/listinfo/gvsig_desarrolladores