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

[Rafael Avila Coya]

Yo entiendo bien lo que dices y estoy de acuerdo en todo ello.

Me parece excelente idea lo de unir landuses a ambos lados de vía
cuando coinciden, para reducir aún más las relaciones. Aunque, como
dices, no sé si será factible... Ya dirán los desarrolladores de cat2osm.

Lo de unir parcelas adyacentes con landuse igual debería, por
coherencia, incluir las residenciales, también está claro.

Un saludo.

On 08/05/12 22:35, Javier Sánchez wrote:
> Hola
> 
> Estamos centrándonos en los edificios, pero me parece que también 
> habría que mirar los multipolígonos (relaciones) de 
> landuse=residential que siempre acompañan a los edificios. Puestos
> a reducir información, una opción podría ser fusionar todas las
> parcelas adyacentes que tengan el mismo uso (residential,
> greenfield, etc). La información que perderíamos sería la
> referencia catastral de cada parcela, pero disminuiría enormemente
> el número de relaciones. Al fin y al cabo, la referencia catastral
> es un dato ajeno a las etiquetas OSM y siempre se puede consultar
> en Catastro. Prefiero perder información por ese lado que por los
> edificios.
> 
> Por otro lado, lo mismo se aplica a los usos del suelo en la parte 
> rústica. Hay una miriada de miniparcelas en sitios como Canarias o 
> Galicia que reflejan los distintos propietarios del terreno, pero
> sólo se diferencian en la referencia catastral. Los bordes de
> estas parcelas no reflejan necesariamente muros u otros límites
> físicos, por lo menos aquí en Canarias, o sea que no tienen mucho
> interés. Yo fusionaría polígonos con un mismo landuse aunque se
> pierda la referencia catastral, como ya han dicho varios. Con esos
> dos pasos, el número de relaciones, nodos y vías tendría que bajar
> bastante.
> 
> Finalmente, un paso más para reducir información redundante sería 
> fusionar parcelas con un mismo landuse que serían adyacentes si no 
> fuera por que alguna vía las atraviesa. Es decir, en lugar de
> muchos polígonos residenciales por cada manzana con espacios en
> blanco a lo largo de las calles, fusionarlos todos en uno. Lo digo
> sobre todo por los bosques, en lugar de ser un polígono sencillo,
> si está atravesado por una pista (por poner un ejemplo) se divide
> en dos polígonos a cada lado de la pista. Como la precisión del eje
> de las vías deja bastante que desear, si la pista ya existe en OSM
> y está dibujada con mejor precisión, habrá que corregir los bordes
> del bosque para que se adapten (un curro) o fusionar los polígonos
> en uno solo. Lo segundo es más sencillo y queda mucho más fácil de
> editar. En caso de modificar la pista sólo hay que corregir sus
> nodos, no los suyos y los de los bordes de la parcela. Esto es
> fácil de hacer a mano, aunque supongo que será un rollo
> implementarlo. En cualquier caso, de esta forma se eliminarían
> nodos innecesarios y relaciones.
> 
> No se si me he explicado. Si no lo he conseguido me dicen y mando 
> alguna imagen para aclararlo.
> 
> Saludos.
> 
> El día 8 de mayo de 2012 12:57, Jorge Sanz Sanfructuoso 
> <sanchi2 en gmail.com> escribió:
>> 
>> 
>> El 8 de mayo de 2012 13:37, Rafael Avila Coya
>> <ravilacoya en gmail.com> escribió:
>> 
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>> 
>>> Leyendo todas las opiniones, propongo esta solución de
>>> compromiso, que pienso podría ser aceptada por todos:
>>> 
>>> 1) Construcciones: Crearlas usando vías, tal y como hace el
>>> catastro francés (si allí fue aceptado, debe serlo aquí, ¿no?).
>>> Pero ojo, no usando masas, sinó haciendo uno para cada
>>> efificación separada. Es decir, si hay una hilera de edificios
>>> consecutivos, se ve cada uno de ellos, no una masa única.
>>> 
>>> Las razones aquí son de peso. No sólo es que en la mayor parte
>>> del mundo ya se hace esto ( http://osm.org/go/0BOd8haLl-- , 
>>> http://osm.org/go/0D0YngwD3- , http://osm.org/go/euu4j_A3L-- ,
>>> etc.), sinó que tener los edificios separados facilita
>>> enormemente la colocación de POI's por usuarios con pocos
>>> conocimientos, que son los más numerosos. Un walking-paper sin
>>> tener las casas separadas es mucho más complicado de cubrir que
>>> si tenemos sus límites. Naturalmente, tener los números de
>>> policía es un plus.
>>> 
>>> Aparte de hacer las edificaciones con vías (es decir, a la
>>> francesa), se pueden simplificar eliminando aleros y otros (no
>>> deberían, en cambio, eliminarse los patios de luces (en ese
>>> caso, habría que hacer relación para ese edificio concreto),
>>> pues así constan también en import de catastro francés (ver
>>> http://osm.org/go/0BOd8haLl-- )).
>>> 
>>> Es decir, hacer contrucciones sólo el contorno exterior usando
>>> vías, no relaciones. En caso de haber patios interiores,
>>> incluírlos y hacer contrucción como relación.
>> 
>> 
>> La idea de esto es para quitar relaciones y al final no las
>> quitas. En los pueblos no tanto pero en ciudades si dibujas los
>> patios interiores al final la mayor parte de los edificios siguen
>> teniendo una relación así que lo veo absurdo. En Salamanca lo
>> podeis ver 
>> http://www.openstreetmap.org/?lat=40.972785&lon=-5.658122&zoom=18&layers=M
>>
>> 
que lo estado haciendo a mano todo con relaciones pero si mirais una gran
>> cantidad de edificios tienen patios interiores. Si tienes que
>> hacer las relaciones igualmente ya se hacen bien hechas no a
>> medias.
>> 
>>> 
>>> 
>>> En cuanto al 3D, no presentaría (creo) problema. Son sólo 3
>>> etiquetas más que acompañan cada edificio: building:height,
>>> building:min_height y building:levels, que se pueden poner en
>>> valores medios ó extremos de conjunto de edificio, como ya
>>> propuse en correo anterior.
>> 
>> 
>> No he visto lo de imports porque el ingles no es para mi pero
>> creo que van mas los tiros por las relaciones del 3D y no de los
>> edificios en si. En Girona se hizo con relaciones y no tubieron
>> pegas y ahi estan los datos sin problemas. Yo iria mas por mirar
>> la posibilidad de quitar alerones y disminuir el numero de datos
>> del 3D con esas 3 etiquetas en la misma relación que el edificio.
>> Con eso creo que deberían quitar las pegas de las relaciones.
>>> 
>>> 
>>> 2) Parcelas: Aquí se pueden eliminar números de policía, pues
>>> no son muy útiles, y en zonas de norte (Galicia en concreto),
>>> aparecen a miles, dado el carácter minifundista de la zona.
>>> Todas las parcelas consecutivas que tengan mismo tipo de
>>> cultivo se unen en una masa, pero sería una pena no usar las
>>> posibilidades de osm de distinguir diferentes tipos de uso de
>>> la tierra (landuse) (me pregunto entonces para qué están).
>>> 
>>> Además de esto, se puliría el código para eliminar nodos
>>> intermedios en vías rectas.
>>> 
>>> No sé qué opinais de esto. A mí, sinceramente, lo que me parece
>>> más preocupante es lo de no distinguir entre edificios
>>> consecutivos.
>>> 
>>> En todo caso, mi propuesta sería consensuar una solución
>>> mínima, modificar el cat2osm, con todo el tiempo y tranquilidad
>>> que haga falta, sin prisas, para luego testear sobre diferentes
>>> escenarios: ayuntamientos pequeños y grandes, urbanos y
>>> rurales, del norte (minifundista) y del centro/sur
>>> (latifundista), etc. Así podríamos presentar un resultado
>>> depurado y espero que aceptable a imports.
>>> 
>>> Un saludo.
>>> 
>>> On 07/05/12 22:37, David wrote:
>>>> El 7 de mayo de 2012 21:33, Jaime Crespo <jynus en jynus.com 
>>>> <mailto:jynus en jynus.com>> escribió:
>>>> 
>>>> 
>>>> El 07/05/2012 20:01, "Rafael Avila Coya"
>>>> <ravilacoya en gmail.com <mailto:ravilacoya en gmail.com>>
>>>> escribió:
>>>> 
>>>> 
>>>>> 
>>>>> 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
>>>> 
>>>> Os recuerdo que en Girona se importaron como relaciones.
>>>> 
>>>>>> 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.
>>>> 
>>>> Si yo estoy de acuerdo. Aquí el problema está en que "el
>>>> cómo deberían de hacerse las cosas bien" choca con "lo que el
>>>> servidor pueda soportar" y "lo que los editores permiten
>>>> editar fácilmente" (aunque yo lo llamaría "lo que el limitado
>>>> editor potlatch2 no puede hacer"). Lo discutís con
>>>> imports...
>>>> 
>>>>>> 
>>>>>> 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 <http://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.
>>>> 
>>>> Llegados a este punto, me estoy planteando el hacer las
>>>> cosas "mal" pero pragmáticas: importar sólo masas y número de
>>>> policía (puede que ejes) y pasar de las parcelas... al menos
>>>> de momento. Guardar el código bien hecho para cuando mejore
>>>> la capacidad de los servidores, los editores o el modelo de
>>>> datos (áreas y/capas) y la visión de futuro de algunos
>>>> contribuidores... Aunque sería una pena.
>>>> 
>>>> -- Jaime Crespo
>>>> 
>>>> 
>>>> _______________________________________________ Talk-es
>>>> mailing list Talk-es en openstreetmap.org
>>>> <mailto:Talk-es en openstreetmap.org> 
>>>> http://lists.openstreetmap.org/listinfo/talk-es
>>>> 
>>>> 
>>>> 
>>>> Preguntas de novato ignorante: ¿qué convierte una manera de
>>>> hacer las cosas en la "correcta" y la otra no? A mi entender
>>>> las 2 hacen exactamente lo mismo, solo que una está muchísimo
>>>> más clara, tanto desde las herramientas como inspeccionando
>>>> el archivo osm. Usar relaciones parece más un "hack" que otra
>>>> cosa, que puede tener sentido si la geometría es compleja,
>>>> pero no para la mayoría de los casos. Además me parece que
>>>> aumenta bastante el tamaño del archivo.
>>>> 
>>>> Lo del 2.5D me parece innecesario. Eso se puede conseguir con
>>>> datos de elevación de terreno. ¿No se supone que en España
>>>> tenemos (o tendremos) datos LiDAR de libre uso? (por cierto,
>>>> ¿alguna info al respecto? la verdad es que me interesa
>>>> bastante)
>>>> 
>>>> Como ya he dicho soy un novato, pero me parece que las
>>>> objeciones de la lista de imports son acertadas.
>>>> 
>>>> -- Saludos
>>>> 
>>>> 
>>>> _______________________________________________ Talk-es
>>>> mailing list Talk-es en openstreetmap.org 
>>>> http://lists.openstreetmap.org/listinfo/talk-es
>>> 
>>> 
>>> - -- - --------------------------------
>>> 
>>> 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 
>>> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10
>>> (GNU/Linux) Comment: Using GnuPG with Mozilla -
>>> http://enigmail.mozdev.org/
>>> 
>>> iQIcBAEBAgAGBQJPqQVmAAoJEB3niTly2pPQgvQP/2hBrp5UyJIcl2IUI0NkWyfa
>>>
>>> 
1ivqKcaMmNIm5BUCo1WplPtM0/LxVWbdJ1JgAMY3sfN777eva3be9dGzcJvLZyMt
>>> qs1QPwAZDByPVmMLORDS0z1M9BTXvwSi3/RxH8jq0V5R9SL0vGPaXaRjk85qvbfj
>>>
>>> 
wn/mPZtOAt2bUQMOfLZuY3OqBLaUFW/beJ1T+cOFiNA2wRHwajKR/auJ+FZm1f0n
>>> IJyf2pvJpfqX1WTL3S0VjlqNYZhGF/f22Y5v7pnbhNR+tio3MG9vUoVqZVKcWgmA
>>>
>>> 
4SM/frgofOLBLMYBo39ypvVLPYWrQOclwkRLcekUr1Lk/bBqdRDPa6Jruxqu8hDO
>>> 52j4tUkICdE2mo8708PhhyIDl3hrk/kzkvcqaEW/DqOL0VwzCbv7et8huX94iaga
>>>
>>> 
iTePkFicPFq9o+K/aeXbpplcAY+hoSv7nCkORW7yX3qf+i9mwWrt7USiAhlTNpW7
>>> mzElK9Jawan30hR+gJ4WjuoJGl/qfagcRHFoKYz7vvInUlxYzcN4vOmCC4YbAZbC
>>>
>>> 
/TKkZ/GUYcGTJXlO0O0VVNe87jjIaERFhY75Ll6Uhv23HIcrk/iM0oulORKS+pOp
>>> CsJV3xlyEpcWBCLhB5KVMW6/HSCKKH0qpM5DEi82WUyeTGm12S4OGcX3FHn+wRhD
>>>
>>> 
5qROwmrSVHrC7CywHDrn
>>> =2uaf -----END PGP SIGNATURE-----
>>> 
>>> _______________________________________________ Talk-es mailing
>>> list Talk-es en openstreetmap.org 
>>> http://lists.openstreetmap.org/listinfo/talk-es
>> 
>> 
>> 
>> 
>> -- Jorge Sanz Sanfructuoso - Sanchi Blog
>> http://blog.jorgesanzs.com/
>> 
>> _______________________________________________ Talk-es mailing
>> list Talk-es en openstreetmap.org 
>> http://lists.openstreetmap.org/listinfo/talk-es
>> 
> 
> _______________________________________________ Talk-es mailing
> list Talk-es en openstreetmap.org 
> http://lists.openstreetmap.org/listinfo/talk-es


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

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