Claro que las relaciones son esenciales y sin ellas no hay forma de
representar cosas como los agujeros de edificios. Pero creo que se crearon
para eso, para dar solución a agrupaciones lógicas que no había otra forma
de agrupar y no para simplificar geometrías.

Los ways son los que (en mi opinión) deben recrear los polígonos, áreas,
lineas, etc. (de hecho en la wiki indica que para eso son) y luego en caso
de necesitar especificar un rol que es totalmente necesario especificar que
cumple ese way, indicarlo mediante relations.

Podría plantear la pregunta al revés, ¿qué mejora la reutilización de ways?

Saludos.

El 15 de junio de 2012 12:15, Javier Sánchez <javiers...@gmail.com>escribió:

> El día 15 de junio de 2012 09:50, Ander Pijoan
> <ander.pij...@deusto.es> escribió:
> > En definitiva, ¿de qué nos sirve separar, complicar el programa,
> complicar
> > el trabajo a la comunidad que tenga que editar el resultado en JOSM,
> > complicar el procesado de los datos a la gente que luego quiera trabajar
> con
> > ellos o importarlos a algún programa suyo, dificultar la lectura de un
> .osm
> > a pelo si fuese necesario, etc si de verdad no hay una optimización clara
> > con ello?
>
> Pues macho, si en [imports] nos dicen que creen que estamos usando
> demasiadas relaciones y después de pensarlo tanto tampoco está claro
> que nos traiga ventajas o de que sea lo más correcto, yo no le daría
> más vueltas. Dejar las relaciones sólo para etiquetas comunes,
> geometrías con agujeros, geometrías muy grandes y complejas (tipo
> fronteras)... Pero para los edificios y parcelas adyacentes polígonos
> superpuestos. Así es como lo han hecho en muchos sitios (Francia, por
> ejemplo).
>
> > De hecho el dejar subparcelas como polígonos independientes puede
> facilitar
> > el proceso de agrupar por ejemplo subparcelas con el mismo cultivo y
> dejar
> > únicamente la geometría de su contorno para simplificar aún mas el
> resultado
> > (si alguien desease consultar las divisiones administrativas entre
> > subparcelas debería ir a Catastro, creo que no es la función de OSM ser
> > Catastro 2).
> >
> http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/06/Subparcels.png
>
> Agrupar subparcelas si están formadas por dos relaciones me parece muy
> fácil. Eliminar de una relación las vías que pertenezcan a ambas y
> eliminar la otra relación. Con polígonos superpuesto sería hacer lo
> mismo a nivel de nodos, siempre que no estén duplicados. Vamos, que en
> ambos casos me parece comparable la dificultar. Respecto a lo de
> Catastro 2 +++++1. Si la división en distintas parcelas se refiere
> solo a una cuestión administrativa fusionarlas.
>
> > Se que retrasaría la importación y habría que volver a definir cómo hacer
> > muchas cosas pero bueno, esta es mi opinión y por supuesto está abierta a
> > debate.
>
> Yo voto que si, que hay que hacerlo.
>
> Saludos.
>
> _______________________________________________
> Talk-es mailing list
> Talk-es@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-es
>



-- 
Ander Pijoan Lamas
Ingeniero Técnico en Informática de Gestión
Universidad de Deusto

Contacto:
Email: ander.pij...@deusto.es
Móvil: +34 664471228
_______________________________________________
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es

Responder a