Yo estaba por generar relaciones porque a mi me dijeron en su día que *así es como debe hacerse*.
Por eso creo que tenemos que hablar con los que dijeron que *así es como debe hacerse* para contarles todas estas cosicas. Y tomar la decisión con ellos. Yo también sería de la opinión que los polígonos formados por líneas sin etiquetar, para evitar segmentos superpuestos, es hacer un pan con unas tortas: para evitar algo que podría ser un problema, genero problemas mucho mayores... Y dejaría sólo el uso de multipolígonos para el caso de edificios con agujeros, y cosas así. Vamos, que el tema sería que los mayores decidan y definan si en OSM el uso de ways con segmentos superpuestos es bueno, o no lo es. El 15 de junio de 2012 10:50, Ander Pijoan <[email protected]>escribió: > Hola a todos. > > Se que he estado una buena temporada un poco ausente liado con otros temas > pero precisamente esa desconexión es la que me ha hecho darle vueltas al > tema de cat2osm y la pelea de los imports. > > El conflicto está principalmente en la *forma de dividir las geometrías*que > sean adyacentes a otra y que en un principio podrían ser representadas > por un único way cerrado, en una relación conteniendo los distintos ways > que la componen con intención de reutilizar ways. Un solo resultado de > cat2osm para una población un poco grande tiene mas relations que toda la > base de datos de OSM. > > (Geometrías representadas por un único way cerrado y que por consiguiente > se "solaparán" los bordes) > > http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing4.png > > (Geometrías divididas en ways independientes lo más grande posibles para > ser reutilizados por otras geometrías) > > http://blogs.deusto.es/gsoc-deustotech/wp-content/uploads/2012/05/MarbleRelationParsing31.png > > En un principio pensé que esta segunda opción era mejor ya que, aunque > requiere más cálculos para crear la geometría, la reutilización de ways > *optimizaría > los archivos .osm*. El caso es que tras muchas pruebas no he visto > reducción del tamaño de los archivos sino que además *han aumentado*. > > Me dio por ver cómo funciona Mapnik en nuestro servidor de pruebas que > montamos y este genera varias tablas entre las que podríamos crear la > siguiente división: "*Tablas por si alguien me pide el archivo importado*" > y "*Tablas para usar*". > > En las tablas del archivo importado (que son 3, una de nodos, otra de ways > y otra de relations) guarda tal cual lo que ha leído del archivo .osm que > le hemos pasado y no vuelve a tocarlo para nada. Intuyo que al pedir > información .osm al API devolverá de esta tablas. > > En cambio en las tablas para usar, lee el archivo y construye las *geometrías > con bordes solapados que tanto esfuerzo hemos puesto en desmontar*. Y es > que si lo pensamos bien, para poder usar todas las ventajas de los SIG las > geometrías deben estar así en polígonos cerrados para poder consultar si un > punto está dentro, polígonos que intersequen... > > De hecho en el Google Summer of Code que estoy trabajando (para la > visualización de tiles vectoriales en Marble), finalmente vamos a tener que > crear nuestro propio servidor de tiles de la información de OSM que envíe > las geometrías ya construidas ya que el Google Summer of Code paralelo de > OSM para crear un servidor de tiles vectoriales, por el momento va a seguir > el formato OSM (nodes, ways y relations) y esto *requiere muchísimo mas > procesado*. (Hay un ejemplo de los dos formatos en > http://blogs.deusto.es/gsoc-deustotech/the-black-planet/) > > *Cómo pequeño ejemplo, imaginemos unas fichas personales, de las cuales > tengamos que conocer la edad de una serie de personas, en las que se > indican la fecha de nacimiento y la edad. Tan solo con la fecha de > nacimiento, conociendo la fecha actual podríamos hacer la resta y conocer > su edad por lo que indicar explícitamente la edad es innecesario. Pero si > hay que calcular las edades muchas veces, el incluir la edad aunque sea > redundante es más óptimo ya que evitas hacer restas una y otra vez. Esto > llevado a algo mucho mas voluminoso es lo que pasa teniendo que saltar de > relations a ways, de ways a nodes, etc para ir creando la geometría en > lugar de darla ya hecha con un way cerrado.* > > Mirando en la wiki qué representa exactamente una relación, se dice lo > siguiente: > > *"A relation is one of the core data elements that consists of one or > more tags and also an ordered list of one or more nodes and/or ways as > members which is used to define logical or geographic relationships between > other elements.*" > > Si que es cierto que indica que se pueden agrupar geometrías por > cuestiones geográficas, pero creo que la palabra clave para decidir si hace > falta una relation es *tags*. Cuando es necesario indicar que las dos > geometrías comparten cierta lógica, cierto significado, en definitiva tags > es cuando opino que si que hay que agruparlas. No se si la mención que hace > a cuestiones geográficas sería la de reutilización de ways pero aún siendo > eso, no veo optimización en ella. > > El problema ahora está en definir hasta qué punto relacionar porque si > seguimos al pie de la letra el tema de agrupar según *compartición de tags > *, podríamos acabar con unas super-relaciones.* > *Construcciones << Parcelas << Manzanas << Poblaciones << Provincias... > > 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*? > > A la hora de crear una estructura de almacenamiento de información muchas > veces en la carrera (Ingeniería informática) nos han dicho que hay > situaciones en las que hay que *sacrificar algo de optimización* en pro > de facilitar las operaciones que se vayan a hacer. Y por eso, aunque me ha > llevado darle muchas vueltas, creo que la mejor opción es solo utilizar > relations para cuando se compartan tags, no geometrías. > > Se que es un fastidio porque habría que replantear todo cat2osm porque si > que las parcelas y sus construcciones comparten tags y deberían seguir > reutilizando ways pero no debería hacerse entre distintas parcelas o > subparcelas. > > 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 > > 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. > > -- > 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 > > -- David Marín Carreño <[email protected]>
_______________________________________________ Talk-es mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-es
