El 07/05/2012 20:01, "Rafael Avila Coya" <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 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 http://lists.openstreetmap.org/listinfo/talk-es
