[Talk-es] [CATASTRO] Simplificación de geometría de las constru.

[Rafael Avila Coya]

On 07/05/12 18:59, Cruz Enrique Borges Hernández wrote:
> Buenas
> 
> A la vista de lo que han comentado en la lista de import la última vez
> (y que nos han recordado amablemente este fin de semana) le hemos
> estado dando un par de vueltas ander y yo al tema. Hemos rellenado un
> par de issue en el tracker con las cosas que pensamos hacer cuando
> tengamos un rato. De todas formas, hay unas cuantas cuestiones que
> creo que es preferible discutirlas en la lista para que nos queden
> claras:

Yo no estoy al tanto de los detalles en lo que a la discusión con
imports se refiere, pero daré mi opinión.

> 
> 1º Relaciones en geometrías compartidas.
> 
> Jaime nos contó muy insistentemente que las geometrías compartidas por
> más de un edificio deben de construirse como una relación (tal y como
> estamos haciendo ahora mismo). Sin embargo, en París, se ha hecho
> superponiendo la vía y solo compartiendo los nodos. Esto lleva a que
> en algunos sitios hayan vías duplicadas, pero reduce el número de
> relaciones enormemente. Esto último ha sido una de las grandes pegas
> que nos han puesto en la lista de imports, con lo cual está mi duda.
> ¿Estamos haciéndolo bien? ¿no será mejor duplicar en algunos casos las
> vías con tal de que queden reduzcamos el número de relaciones?

Yo insisto en que no entiendo qué problemas hay con las relaciones.
Están ahí para algo, ¿no? Podría ponerse la pega de que es más fácil
"crear" una hilera de casas adosadas usando vías que se superponen en
las paredes de separación, pero son una solución "cutre" si se la
compara a hacerlo con relaciones. Entre otras ventajas, las relaciones
permiten reutilizar cada uno de los segmentos para futuras necesidades.
Es, por lo tanto (y en mi opinión), una solución más elegante.

Si la respuesta es que son "muchas relaciones", no la entiendo, y
creedme que lo intento.

> 
> 2º OSM-2.5D
> 
> Ahora mismo estamos aprovechando toda la información que podemos de
> las alturas de los edificios. Esto provoca que se tengan que hacer una
> barbaridad de relaciones para tener en cuenta aleros, tejados,
> balcones, etc. Cómo aún no está nada claro el tema del 2.5D en osm, se
> podría incluir la referencia catastral en las constru y simplificarlas
> poniendo solo la unión de todas las geometrías de ese edificio. Con
> esto reducimos el número de relaciones otra vez más y si en algún
> momento queda claro como va a funcionar el 2.5D sólo hay que eliminar
> las geometrías con una referencia catastral y sustituirla por las que
> tenga la info 2.5D.La pregunta es, ¿nos peleamos por el 2.5D o
> simplificamos y ya lo haremos más adelante?

La pega, que también sería válida para el punto 1º, es: ¿será
fácil/viable incorporar esos datos más adelante?

Anteayer envié un e-mail de respuesta en el hilo "Bloqueo
catastro_pontevedra" que quizá no llegó a la lista por llevar adjunto un
archivo de 2.2M (no sabía que el máximo eran 100k). En el proponía
alguna alternativa de simplificación, que vuelvo a escribir aquí:

----------
En el issue 23 [se refiere a mejoras en cat2osm] pones [Cruz Enrique]
que se podría renunciar a tags 3D. ¿Te refieres
con eso a tags como building:height, building:min_height y
building:levels? Si es así creo que sería mala idea, pues dejaría a
proyectos como osm3D sin posibilidad de usarlos.[Como alternativa menos
buena, aunque más simple] En caso de que cada parte del edificio tuviese
diferentes valores para esos tags, se podría elegir un valor único para
todo el edificio y para cada uno de
esos tags. Por ejemplo, para el building:min_height se podría elegir
el mínimo de ellos, para building:height se podría elegir el que
resultase ser máximo, o un valor medio, y para building:levels el que
resultase máximo. Habría que ver las distintas posibilidades complejas
que se pueden dar. En todo caso, hay que tener en cuenta que se
perdería info.

Otra posibilidad sería eliminar (unir) aquellas partes que tienen tags
3D idénticos, y mantener separados los que no. Esto no haría perder
info, y sí sería aceptable por todos, sin ninguna duda.
-----------

Pero repito la gran duda: si se optan por soluciones como vías
superpuestas como alternativa a usar relaciones, y si simplifican
edificaciones perdiendo info. 3D (ó 2.5D), ¿sería fácil hacer más
adelante una actualización/mejora, o habría que reacer todo de nuevo?
¡El trabajo ya es enorme en sí mismo, para aún pensar en una segunda fase!

> 
> 3º Simplificación de cultivos.
> 
> La otra pata es la simplificación de cultivos que tengan los mismos
> tags, aquí habría que hacer lo mismo que con las constru, solo que en
> vez de agrupar por parcelas, hay que hacerlo por tipo de cultivo. En
> esta poca discusión puede haber.
> 
> Pues nada, ya nos direis.
>

Unir parcelas consecutivas que comparten mismo cultivo no es mala idea
de todo. A bote pronto, la única información que se podría perder es la
línea de separación entre parcelas, que se puede etiquetar como
barrier=wall,hedge,fence, etc., según proceda y con datos sobre el
terreno, en este caso. No sería una pérdida enorme, en todo caso.

Lo que sí, debería mejorarse, como ya se dijo aquí, lo de nodos
redundantes en vías rectas, por lo menos para edificios. Ésa sí puede
ser una razón de peso para que no admitan el import.

Un saludo.

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

Por favor, non me envíe documentos con extensións .doc, .docx, .xls,
.xlsx, .ppt, .pptx, aínda podendoo facer,  non os abro.

Atendendo á lexislación vixente, empregue formatos estándares e abertos.

http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros