La idea, que haga una cosa u otra, creo que era no perder lo que ya esta hecho del programa y aunque no se use no llegar y borrarlo. No van a tirar todo el trabajo que llevan hasta ahora mas cuando mas adelante a lo mejor hace falta. Lo de que cada uno elija como hacerlo en principio no seria factible. Esto nos tiene que dar un cierto permiso el resto de la comunidad y que cada uno lo haga de su manera va a ser que nos van a decir que no.
Las relaciones a primera vista parecen muy difíciles y como están planteados los programas de edición aun mas. Pero cuando te metes con las relaciones, las manejas un poco y ves las 4 cosas básicas no es para tanto. Pensandolo ahora, que se usen para todo o solo para lo esencial vamos a tener igualmente relaciones y estaría bien hacer una pequeña guia de las 4 cosas básicas. El día 15 de junio de 2012 20:33, Antonio Navarro <anto...@hunos.net> escribió: > Hola, > > Aunque soy un novato total y muchas de las implicaciones quizá no las > entienda, creo que una solución podría ser dejarlo como está, para que > genere las relaciones (que parece que 'formalmente' es más correcto en > muchos casos) y añadir una opción (vía parámetro o vía fichero de > configuración) para que lo haga todo con vías superpuestas. De esta forma no > perderíamos funcionalidad y quedaría a criterio de cada uno generar la > información como prefiera. Claro que no tengo ni idea de cómo sería de > costoso técnicamente hacer esto :-) > > En mi opinión después de estar viendo los ficheros generados para Talavera y > para Cazalegas, sinceramente no veo claro tanta relación. Lo de las vías > superpuestas no es que sea la panacea, pero me parece más simple. > > Un saludo, > > -- > Antonio Navarro > ---------------------------- > mailto:anto...@hunos.net > mailto:antonio.navarro...@gmail.com > mailto:antonio.nava...@hispalinux.es > ---------------------------- > > > El 15 de junio de 2012 18:23, Javier Sánchez <javiers...@gmail.com> > escribió: > >> El día 15 de junio de 2012 13:04, Ander Pijoan >> <ander.pij...@deusto.es> escribió: >> > Yo no digo eliminar las relaciones de cuajo del resultado allí donde >> > hagan >> > falta (edificios con agujeros, lineas de autobus con sus paradas, >> > carreteras >> > muy largas, trazados de ferrocarril...). Para eso son las relaciones. >> > >> > Lo que digo que creo que no hay que hacer y que no aporta ninguna >> > ventaja es >> > utilizar relaciones para reutilizar ways. ¿En qué parte de la wiki de >> > OSM se >> > indica que tenga que hacerse eso así? >> > >> > Lo de Girona no se lo que dirían en su día y, también hay que decirlo, >> > tal y >> > como están esas, construcciones están correctas, pero ¿qué beneficia el >> > hacerlo así? ¿Puestos a pedir por qué yo no podría hacer que una >> > población >> > sea una relation grande, cuyos members son otras relations que son sus >> > manzanas con role inner, esas manzanas a su vez compuestas de otras >> > relations que son las parcelas... >> > >> > El esquema lo permite, pero llega un momento en el que no tiene sentido >> > y no >> > mejora nada. >> > >> > Lo normal en OSM >> > >> > http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing4.png >> > >> > Lo que se propuso para cat2osm en un principio pero que ya no lo veo >> > lógico. >> > >> > http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing31.png >> > >> > Esta reutilización de geometrías para evitar bordes superpuestos vuelvo >> > a >> > repetir que no mejora nada. Para todo lo demás, las relaciones siguen >> > siendo >> > totalmente necesarias. >> >> >> Hay que buscar un término medio. Emplear vías superpuestas en unos >> casos y relaciones en otros según nos interese, y fusionar vías >> adyacentes con los mismos usos en los casos en que está claro como >> rústico. >> >> Ahora bien, veo dos formas de hacerlo. >> >> A) Reescribir todo el código para que genere vías superpuestas excepto >> relaciones en algunos casos. >> >> B) Dejar el código más o menos como está, generando relaciones para >> todo y pasar un proceso posterior que simplifique relaciones y >> sustituya por vías superpuestas en algunos casos. >> >> Supongo que B da menos trabajo pero tendrá más coste en tiempo de proceso. >> >> Javier. >> >> _______________________________________________ >> 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 > -- Jorge Sanz Sanfructuoso - Sanchi Blog http://blog.jorgesanzs.com/ _______________________________________________ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
