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

[Ander Pijoan]

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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.openstreetmap.org/pipermail/talk-es/attachments/20120615/d2d0f985/attachment-0001.html>