<p><br>
El 07/05/2012 20:01, "Rafael Avila Coya" <<a href="mailto:ravilacoya@gmail.com">ravilacoya@gmail.com</a>> escribió:<br>
><br>
> On 07/05/12 18:59, Cruz Enrique Borges Hernández wrote:<br>
> > Buenas<br>
> ><br>
> > A la vista de lo que han comentado en la lista de import la última vez<br>
> > (y que nos han recordado amablemente este fin de semana) le hemos<br>
> > estado dando un par de vueltas ander y yo al tema. Hemos rellenado un<br>
> > par de issue en el tracker con las cosas que pensamos hacer cuando<br>
> > tengamos un rato. De todas formas, hay unas cuantas cuestiones que<br>
> > creo que es preferible discutirlas en la lista para que nos queden<br>
> > claras:<br>
><br>
> Yo no estoy al tanto de los detalles en lo que a la discusión con<br>
> imports se refiere, pero daré mi opinión.<br>
><br>
> ><br>
> > 1º Relaciones en geometrías compartidas.<br>
> ><br>
> > Jaime nos contó muy insistentemente que las geometrías compartidas por<br>
> > más de un edificio deben de construirse como una relación (tal y como<br>
> > estamos haciendo ahora mismo). Sin embargo, en París, se ha hecho</p>
<p>Os recuerdo que en Girona se importaron como relaciones.</p>
<p>> > superponiendo la vía y solo compartiendo los nodos. Esto lleva a que<br>
> > en algunos sitios hayan vías duplicadas, pero reduce el número de<br>
> > relaciones enormemente. Esto último ha sido una de las grandes pegas<br>
> > que nos han puesto en la lista de imports, con lo cual está mi duda.<br>
> > ¿Estamos haciéndolo bien? ¿no será mejor duplicar en algunos casos las<br>
> > vías con tal de que queden reduzcamos el número de relaciones?<br>
><br>
> Yo insisto en que no entiendo qué problemas hay con las relaciones.<br>
> Están ahí para algo, ¿no? Podría ponerse la pega de que es más fácil<br>
> "crear" una hilera de casas adosadas usando vías que se superponen en<br>
> las paredes de separación, pero son una solución "cutre" si se la<br>
> compara a hacerlo con relaciones. Entre otras ventajas, las relaciones<br>
> permiten reutilizar cada uno de los segmentos para futuras necesidades.<br>
> Es, por lo tanto (y en mi opinión), una solución más elegante.<br>
><br>
> Si la respuesta es que son "muchas relaciones", no la entiendo, y<br>
> creedme que lo intento.</p>
<p>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...</p>

<p>> ><br>
> > 2º OSM-2.5D<br>
> ><br>
> > Ahora mismo estamos aprovechando toda la información que podemos de<br>
> > las alturas de los edificios. Esto provoca que se tengan que hacer una<br>
> > barbaridad de relaciones para tener en cuenta aleros, tejados,<br>
> > balcones, etc. Cómo aún no está nada claro el tema del 2.5D en osm, se<br>
> > podría incluir la referencia catastral en las constru y simplificarlas<br>
> > poniendo solo la unión de todas las geometrías de ese edificio. Con<br>
> > esto reducimos el número de relaciones otra vez más y si en algún<br>
> > momento queda claro como va a funcionar el 2.5D sólo hay que eliminar<br>
> > las geometrías con una referencia catastral y sustituirla por las que<br>
> > tenga la info <a href="http://2.5D.La">2.5D.La</a> pregunta es, ¿nos peleamos por el 2.5D o<br>
> > simplificamos y ya lo haremos más adelante?<br>
><br>
> La pega, que también sería válida para el punto 1º, es: ¿será<br>
> fácil/viable incorporar esos datos más adelante?<br>
><br>
> Anteayer envié un e-mail de respuesta en el hilo "Bloqueo<br>
> catastro_pontevedra" que quizá no llegó a la lista por llevar adjunto un<br>
> archivo de 2.2M (no sabía que el máximo eran 100k). En el proponía<br>
> alguna alternativa de simplificación, que vuelvo a escribir aquí:<br>
><br>
> ----------<br>
> En el issue 23 [se refiere a mejoras en cat2osm] pones [Cruz Enrique]<br>
> que se podría renunciar a tags 3D. ¿Te refieres<br>
> con eso a tags como building:height, building:min_height y<br>
> building:levels? Si es así creo que sería mala idea, pues dejaría a<br>
> proyectos como osm3D sin posibilidad de usarlos.[Como alternativa menos<br>
> buena, aunque más simple] En caso de que cada parte del edificio tuviese<br>
> diferentes valores para esos tags, se podría elegir un valor único para<br>
> todo el edificio y para cada uno de<br>
> esos tags. Por ejemplo, para el building:min_height se podría elegir<br>
> el mínimo de ellos, para building:height se podría elegir el que<br>
> resultase ser máximo, o un valor medio, y para building:levels el que<br>
> resultase máximo. Habría que ver las distintas posibilidades complejas<br>
> que se pueden dar. En todo caso, hay que tener en cuenta que se<br>
> perdería info.<br>
><br>
> Otra posibilidad sería eliminar (unir) aquellas partes que tienen tags<br>
> 3D idénticos, y mantener separados los que no. Esto no haría perder<br>
> info, y sí sería aceptable por todos, sin ninguna duda.<br>
> -----------<br>
><br>
> Pero repito la gran duda: si se optan por soluciones como vías<br>
> superpuestas como alternativa a usar relaciones, y si simplifican<br>
> edificaciones perdiendo info. 3D (ó 2.5D), ¿sería fácil hacer más<br>
> adelante una actualización/mejora, o habría que reacer todo de nuevo?<br>
> ¡El trabajo ya es enorme en sí mismo, para aún pensar en una segunda fase!<br>
><br>
> ><br>
> > 3º Simplificación de cultivos.<br>
> ><br>
> > La otra pata es la simplificación de cultivos que tengan los mismos<br>
> > tags, aquí habría que hacer lo mismo que con las constru, solo que en<br>
> > vez de agrupar por parcelas, hay que hacerlo por tipo de cultivo. En<br>
> > esta poca discusión puede haber.<br>
> ><br>
> > Pues nada, ya nos direis.<br>
> ><br>
><br>
> Unir parcelas consecutivas que comparten mismo cultivo no es mala idea<br>
> de todo. A bote pronto, la única información que se podría perder es la<br>
> línea de separación entre parcelas, que se puede etiquetar como<br>
> barrier=wall,hedge,fence, etc., según proceda y con datos sobre el<br>
> terreno, en este caso. No sería una pérdida enorme, en todo caso.<br>
><br>
> Lo que sí, debería mejorarse, como ya se dijo aquí, lo de nodos<br>
> redundantes en vías rectas, por lo menos para edificios. Ésa sí puede<br>
> ser una razón de peso para que no admitan el import.<br>
><br>
> Un saludo.</p>
<p>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.</p>

<p>--<br>
Jaime Crespo</p>