[Talk-es] Reflexión acerca de Cat2Osm, geometrías, importaciones y pegas de los alemanes...

Vie Jun 15 10:33:21 BST 2012

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 <ander.pijoan en deusto.es>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: ander.pijoan en deusto.es
> Móvil: +34 664471228
>
>
> _______________________________________________
> Talk-es mailing list
> Talk-es en openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-es
>
>

-- 
David Marín Carreño <davefx en gmail.com>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.openstreetmap.org/pipermail/talk-es/attachments/20120615/b7404640/attachment.html>