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 <sanc...@gmail.com> escribió: > > > El 8 de mayo de 2012 13:37, Rafael Avila Coya <ravilac...@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 <jy...@jynus.com >> > <mailto:jy...@jynus.com>> escribió: >> > >> > >> > El 07/05/2012 20:01, "Rafael Avila Coya" <ravilac...@gmail.com >> > <mailto:ravilac...@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@openstreetmap.org <mailto:Talk-es@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@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@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-es > > > > > -- > Jorge Sanz Sanfructuoso - Sanchi > Blog http://blog.jorgesanzs.com/ > > _______________________________________________ > Talk-es mailing list > Talk-es@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-es > _______________________________________________ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
