-----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. 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. 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
