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. El 15 de junio de 2012 13:48, Jorge Sanz Sanfructuoso <[email protected]>escribió: > La logica que siempre se a seguido o por lo menos en general para > decir que no se usen relaciones es que es mas sencillo de editar, y > algo menos aunque tambien se a dicho que es menos carga para los > servidores. > > Lo de mas sencillo de editar como ya han comentado por aqui no es así. > Ponte a editar en un sitio que se junten varios trazados y me lo > cuentas. Proceso que sigo yo y creo que al final es el mas facil. > Coger a ver que poligono sale si no es el que quieres agregarle un > nodo y apartarlo. Ir al siguiente si pasa lo mismo otra vez hasta que > llegas al que quieres. Cuando llegas ya lo modificas y borrar los > nodos que has creado que sobran, si hay algún nodo mio suelto raro ya > sabeis porque puede ser. jejeje. > > Lo de la carga a los servidores creo que si que da mas carga eso no lo > discuto. > > Se da mucho por hecho por aqui que ningún tipo de relación maxima va a > ser aceptada por la lista de imports, entonces me pregunto ¿porque se > acepto la de Girona?. Si no me equivoco se paso por la lista de > imports. Creo que habría que reducir el numero de relaciones y después > ver que dicen. > > El día 15 de junio de 2012 13:13, Ander Pijoan > <[email protected]> escribió: > > Creo que no nos estamos entendiendo. > > > > Se puede resumir todo en una pregunta: ¿Qué problema habría si cat2osm > > sacase los datos tal y como están en Alemania o Francia? > > > > El 15 de junio de 2012 13:06, Jaime Crespo <[email protected]> escribió: > > > >> El día 15 de junio de 2012 12:48, Ander Pijoan > >> <[email protected]> escribió: > >> > No pero no me refiero a eso Jynus. > >> > >> > Me refiero a que utilizar relations para optimizar no me parece que > sea > >> > correcto > >> > (ni que optimice). Las relations son para agrupar elementos con un > mismo > >> > significado o relacionados, valga la redundancia, y eso lo estabamos > >> > haciendo bien. > >> > >> Pues tienes una idea equivocadísima de las relaciones. ¿Juntamos en > >> una relación todos los amenity=bar de una ciudad? ¿campus de Deusto? > >> Obviamente no, usamos tags. > >> > >> Y qué obsesionados estáis todos con optimizar. ¿Acaso alguien ha > >> hablado realmente con los sysadmins -y no con los de imports, que sus > >> criterios son otros, de mantenimiento de los datos- sobre cuánto > >> afecta eso a sus servidores? > >> > >> ---------------------- > >> > >> Respecto a la complejidad: > >> > >> No quiero usuarios vagos. Precisamente el hecho de que cosas complejas > >> de por sí son complejas evita todos los vandalismos en OSM (si no > >> sabes editar una frontera entre dos países, no lo hagas). > >> > >> Ahora bien, todo lo que sea sencillo, que sea lo más sencillo posible. > >> La forma de los edificios se puede cambiar sin problemas por cualquier > >> usuario (siguen siendo ways), y es probablemente más fácil con > >> relaciones, porque no tiene que "acertar" cuál es el polígono > >> correcto. > >> > >> OSM es un proyecto colaborativo, por lo que hay que anteponer la > >> edición fácil a la "optimización" de los servidores. (Si tu software > >> no es capaz de entender relaciones no es problema del modelo de datos > >> de osm, sino de que tendrás que hacer una conversión antes, como hace > >> mapnik). Y si los editores no lo hacen fácil, se modifican los > >> editores para hacerlo fácil, no la forma de editar de la gente. > >> > >> Dicho esto, yo aquí hace un tiempo propuse subir masas (como ways, sin > >> agujeros) a pelo y portales (como nodos) - mira qué fáciles de editar. > >> Y ya estaría satisfecho. Eso sí, los de imports te dirán que no de > >> nuevo (lo último de la lista es que deberían borrarse todos los > >> edificios de OSM porque no tienen valor). > >> > >> -- > >> Jaime Crespo > >> > >> _______________________________________________ > >> Talk-es mailing list > >> [email protected] > >> http://lists.openstreetmap.org/listinfo/talk-es > > > > > > > > > > -- > > Ander Pijoan Lamas > > Ingeniero Técnico en Informática de Gestión > > Universidad de Deusto > > > > Contacto: > > Email: [email protected] > > Móvil: +34 664471228 > > > > > > _______________________________________________ > > Talk-es mailing list > > [email protected] > > http://lists.openstreetmap.org/listinfo/talk-es > > > > > > -- > Jorge Sanz Sanfructuoso - Sanchi > Blog http://blog.jorgesanzs.com/ > > _______________________________________________ > Talk-es mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-es > -- Ander Pijoan Lamas Ingeniero Técnico en Informática de Gestión Universidad de Deusto Contacto: Email: [email protected] Móvil: +34 664471228
_______________________________________________ Talk-es mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-es
