Muchas gracias por la respuesta tan detallada. La verdad es que se agradece.
Te contesto parte por parte. El 15 de octubre de 2012 19:54, Cruz Enrique Borges <cruz.bor...@deusto.es>escribió: > 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. > > Estoy totalmente de acuerdo. > 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. En el caso de agujeros y otras formas "raras" por supuesto que se deben usar relaciones (porque no queda más remedio). 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 lo entiendo. Si mueves un nodo compartido las vías que lo comparten siguen apuntando a ese nodo de la misma manera que antes. Es una referencia. Si borras un nodo compartido la herramienta / base de datos debería actualizar las vías que hacen referencia a él. Debería ser todo automático (y si no lo es hay que mejorar las herramientas tal como dices abajo). Me gustaría ver esos casos que comentas. > 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. > Al ser más fácil de editar ¿no estaríamos reduciendo el error humano? Me gustaría ver un ejemplo del jaleo que se puede montar en un caso, que no se pueda formar en el otro. 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. > Pero no creo que se pierda información por almacenarlo de la otra forma. Simplemente el algoritmo que use un enrutador será un poco diferente. Al fin y al cabo ya tenemos enrutadores funcionando con los datos tal como están ahora (con vías compartidas). Vuelvo a insistir que unas pocas relaciones siguen haciendo falta, pero son casos raros. > 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. > Pero eso también creo que se puede calcular ahora. ¿Lo que dices es que tendría que almacenarse "precalculado" mediante relaciones? Yo puedo coger perfectamente mi primer ejemplo (el de las vías compartidas) y hacerte un programa que devuelva la lista de vías compartidas. Repito que en el caso de agujeros y cosas así está claro que hacen falta relaciones. 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. > No tengo muy claro lo que es un "shapefile", así que discúlpame. Si es verdad lo que dices, que perdemos información al usar vías compartidas, entonces estoy de acuerdo. OSM no es solo para el renderer. Debe contener información útil (que represente la realidad). > 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). > Mejorar las herramientas/infraestuctura está claro que siempre se debe hacer. Las pegas que os han puesto los de la lista de imports sí que son un poco tontas, la verdad. > 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. > Qué va, gracias a ti por una contestación tan detallada. Me gustaría leer más cosas como ésta por la lista de vez en cuando. Así los profanos aprenderíamos un poco. :) -- Saludos
_______________________________________________ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
