> Pero lo que nunca he entendido es por qué se sigue diciendo que las > relaciones son lo "correcto". > Que yo sepa en esta lista de correo nunca ha explicado nadie por qué es lo > "correcto" (más allá de que sea una preferencia personal). > Los ficheros generados ocupan más o menos lo mismo (de hecho algo más con > relaciones), y la información sigue estando ahí de una forma u otra.
Vale, te explico el tema desde varios punto de vista [aviso de ladrillo inside] ********************************************************************** Punto de vista Informático/Ciencias de la computación/Bases de datos: Una de las leyes inviolables de bases de datos dice algo tal que así: La duplicación de información es mala y debe evitarse a toda costa. La pregunta es donde se está duplicando información al hacerlo de la manera que comentas. Si se hace correctamente no "debería" de haber información duplicada pues las vías superpuestas compartirían nodos. Como (creo que) no se puedan escribir todas las geometrías de esta forma, será necesario en algunos casos duplicar nodos/vías para poder trazar la geometría. Esto lleva al problema de que cuando edites esos nodos/vías no se te debe olvidar actualizar todo lo que apunte a esos nodos/vías o ya empiezas a meter inconsistencias. Ander me mostró algunos casos en París en los que pasaban estas cosas [1]. Esto no es malo per se pues tiene sus ventajas: es mucho más fácil de editar, es más rápido, si se tiene cuidado ocupa menos espacio, etc. Ahora bien, como se te despiporre el tema de nodos y vías duplicadas puedes hacer un cristo de datos desactualizados que puede parecer las relaciones hasta una buena solución. Nótese que este tipo de soluciones las están empezando a tomar las empresas que trabajan con lo que se llama Big Data, se prefiere poder tratar cantidades masivas de datos de forma eficiente antes que priorizar la consistencia interna de los datos. Si este es el objetivo de la fundación OSM, pues entonces es probable que esta sea la mejor idea, pero si lo que se quiere es hacer el mejor y más fiel mapa de la realidad, entonces esta NO ES LA MEJOR OPCIÓN (sobre todo por lo que voy a comentar en el siguiente punto de vista). ********************************************************************** Punto de vista Matemático/Topológico/Sistema de Información Geográfico: La topología es la rama de las matemáticas que estudia las relaciones de posición que mantienen los objetos entre sí. Estudia cosas como: está contenido, comparten frontera, tiene un agujero, están conectados, etc. Esta información es absolutamente imprescindible que esté contenida en una base de datos GIS a poco que quieras hacer algunos análisis potentes. Piensa que, por ejemplo, en el caso de las vías y los enrutadores: sin esta información no pueden hacer ABSOLUTAMENTE NADA. Se pueden dibujar las vías y quedar muy monas, pero no sabrías si desde una calle puedes ir a otra. Para el tema de parcelas y edificios pasa lo mismo, en las relaciones se guarda la información de fronteras compartidas e información topológica similar (como por ejemplo los "huecos" de los polígonos). Esta información puede que ahora no sea relevante ahora mismo pero a futuro se pueden hacer análisis interesantes si se tiene esta información. Por ejemplo, pensando rápido y a bote pronto se me ocurre (seguro que alguien tiene análisis más interesantes): que tipos de parcela son contiguos, que edificios comparte paredes para poder saber si es factible derribar alguno, etc. De hecho, ahora mismo este tipo de información NO se puede guardar en un shapefile y muchos GIS comerciales no están preparados para usarla [2]. Desde mi punto de vista, el hecho de poder codificarla y usarla en OSM es un punto muy importante a favor como sistema de codificación de datos en GIS frente a la competencia y si nos olvidamos de OSM como un visualizador y empezamos a pensar en él como una base de datos con múltiples aplicaciones, este tipo de información empieza a cobrar MUCHO sentido que esté incluida. Puede a a priori no le veamos utilidad, pero seguro que alguien se la verá rápidamente. ********************************************************************** Es por todo esto por lo que YO creo que es la forma correcta de hacer las cosas. Tampoco es que sea el mayor experto en GIS y seguro que hay millones de problemas técnicos que impiden que hagamos las cosas como "deberíamos" de hacerlas (que no estaría de más si alguien los conoce que los cuente), pero eso no impide que lo intentemos. Ahora bien, personalmente creo que las escusas que nos dieron para impedir la subida: - no hay herramientas para editar dichos datos - no hay infraestructura son válidas para RETRASAR la importación, no para impedirla porque: en el primer caso lo que hay que hacer son MEJORES HERRAMIENTAS [3] y en el segunda caso MEJORAR LA INFRAESTRUCTURA [4] (bien mediante mejores algoritmos o mediante más potencia de cálculo), pero nunca mutilar los datos. Y si se tiene que esperar a que se cumplan los puntos anteriores, pues se espera (y se trabaja en mejorar esas puntos y en trabajar en los datos en servidores más restringidos, para cuando se pueda hacer la importación), pero no decirte que esos datos no son bienvenidos como alguno mencionó... Y ya se que Jaime va a venir a decirme luego que esto se lo tengo que contar a los de imports, pero estoy esperando a que alguien prepare una masa para ver que nos dicen (y luego ya veremos :P). Y si alguien ha llegado hasta aquí leyendo se mereces un premio :P porque aguantar el sermón este que he soltado... En fin, espero que se haya entendido mi punto de vista sobre este tema y si alguien tiene algún comentario yo estoy dispuesto a discutirlo. Nos vemos. [1] Ojo, que Ander es fiel defensor de la idea de pasar de las relaciones y ya ha escrito algún mail en la lista sobre ello. [2] Según el libro de introducción al GIS libre y gratuito de Victor Olaya :P [3] Creo que la Knight Foundation le han dado a la fundación OSM tropecientos muchos $ para eso: http://www.h-online.com/open/news/item/Foundation-grants-575-000-for-new-OpenStreetMap-tools-1715448.html Nosotros también estamos planeando algo en este sentido. Cuando lo tengamos más definido os contamos. [4] ¿No habían dado un porrón de € también para eso los de GeoFabric? -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain _______________________________________________ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
