Uno de los fallos más problemáticos a la hora de realizar análisis con Sistemas de Información Geográfica (SIG) es no darle la importancia que se merece a la calidad de los datos espaciales. Simplemente cogemos datos que nos proporcionan, descargamos o adquirimos, y asumimos su óptima calidad sin ni siquiera pegarles un pequeño vistazo… El resultado en muchas ocasiones ya se lo pueden imaginar, sí, estamos hablando de lo que en el mundo de la programación se conoce como «Garbage In, Garbage Out» – GIGO, que traduciéndolo viene a decir que si trabajas con datos espaciales de dudosa calidad, tus resultados serán probablemente de igual o peor calidad independientemente del software que utilices para gestionar y analizar tus datos.
Desde Auckland, Nueva Zelanda, Nathan Heazlewood ha redactado una miniguía con el típico escenario que las personas y organizaciones se encuentran a la hora de tratar la calidad de los datos espaciales y que, aunque no es una lista exhaustiva, es recomendable tenerla a modo de lista de verificación para la calidad de los datos espaciales. Hay que señalar, que esta lista también es valiosa para aquellas personas que se dediquen a producir los datos, ya que les obliga a documentar su propio trabajo… y deseo remarcar este punto, ya que hoy en día todo el mundo nos hemos convertido en productores potenciales de datos…
Bien, como remarca Nathan, los datos espaciales requieren de muchos más controles que los datos alfanuméricos estándar, por ello esta lista se compone de 30 elementos agrupados en distintas áreas como pueden ser las consideraciones geométricas, las proyecciones y sistemas, los atributos, la estructura de coordenadas, precisión, etc. Nathan introduce muchas consideraciones que no son a menudo discutidas, pero que pueden dar lugar a enormes problemas, como por ejemplo los diferentes estándar en formatos de fechas y puntuación de los números. Hay que señalar que la lista se encuentra ligeramente enfocada hacia la gestión de los datos espaciales con el software ArcGIS, pero que es igualmente práctica para los usuarios de cualquier otra tecnología SIG. Aquí os dejo simplemente el listado, para más información, recurrir a la fuente:
Las pruebas de exactitud posicional
- Precisión de los datos: Compruebe si la precisión espacial de los datos es apto para el uso que quieres darles.
- Compruebe si las capas de información geográfica con las que los va a combinar tienen la misma precisión..
Sobre la lógica topológica
- Las entidades lineales no deben solaparse o auto-solapamiento: isolineas que se cruzan, etc.
- La mayoría de las entidades poligonales en general no deben superponerse: áreas administrativas, etc.
- Muchas entidades de tipo punto suelen coincidir con entidades de tipo línea: líneas de ferrocarril o carreteras y puntos kilométricos, etc
- Algunos polígonos no deben solaparse con otros tipos de polígonos. Por ejemplo un polígono lago no debe superponerse o ser coincidente con un polígono océano.
Consideraciones sobre los datos geométricos
- Cada elemento real está definido por un único tipo de entidad geométrica.
- En la tabla de datos asociada a la cartografía, sólo existirá una columna que especifique la geometría de la entidad.
Las proyecciones y sistemas de coordenadas
- Las proyecciones de los datos espaciales que va a utilizar son coincidentes a los de la base cartográfica sobre los que quiere trabajarlos y representarlos.
- Los valores negativos siguen siendo negativas: un error común al migrar datos en el cambio de proyecciones.
Atributo de datos y la estructura de los controles
- Los nombres de los campos de atributos son correctos y que no utilizan nombres «reservados» del sistema de destino.
- Los tipos de datos de campo de atributos son correctos. Como ejemplo, que los datos de fecha no este asociado a un tipo de dato de texto normal.
- Que los valores de los atributos sean acordes a los tipos de datos. Ejemplo: Que como valor en un campo de fecha se introduzca «próximo año».
- Que todos los valores estén dentro del rango permitido de valores.
- No hay entradas con valores nulos para datos de atributos que no son nulos, por ejemplo para una clave principal.
- Tampoco debe haber entradas duplicadas para atributos donde no debería ser duplicados.
- Que no existan registros «huérfanos» en las tablas relacionadas.
- Comprobar si los caracteres especiales (símbolos de puntuación) están presentes en los datos y si afectan al sistema base.
- Comprobar si los caracteres internacionales están presentes y como son gestionados en el sistema de destino.
- Ver qué aspectos de los datos se han exportado desde un sistema de origen. Revisar la importación de archivos CAD y de datos 3D como CityGML.
- Compruebe que la precisión de los datos de origen se ha mantenido Atención a los redondeos.
- Comprobar que los formatos de linea dentro de la celda de valores (retornos de carro – «intro») no causen problemas.
- Comprobar que los datos no se ha truncado por la cantidad de texto permitido de almacenaje entre distintos sistemas de bases de datos espaciales.
- Asimismo comprobar también que los nombres de atributos no están afectados por truncamiento.
- Compruebe que el formato de fecha americano no se está utilizando cuando esté migrando datos de otro país…
- Compruebe que las unidades de medida son consistentes del origen al destino. Medidas métricas e imperiales, etc.
- Compruebe que los valores de moneda han sido convertidos al suyo en caso necesario.
- Compruebe si los valores de moneda incluyen o excluyen los impuestos correspondientes
- Comprobar que los caracteres que suelen confundirse no causan problemas, muy típico para los casos de geocodificación.
- Compruebe la actualidad de los datos
- Compruebe los metadatos
Fuentes:
- https://www.linkedin.com/pulse/gis-gigo-garbage-out-30-checks-data-errors-nathan-heazlewood
- http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//006200000001000000.htm
- https://spatialreserves.wordpress.com/
- http://video.arcgis.com/watch/668/finding-and-fixing-errors-using-topology
Hola Luis, lo primero gracias por divulgar tu conocimiento.
Te quería preguntar algo que no entiendo, sobre el solapamiento o superposición de los limites administrativos en un GIS, (BBDDE), al que te refieres en tu valiosa aportación.
Como es posible que no se superpongan los limites adm. de dos, por ejemplo, términos municipales vecinos, colindantes. Deberán ser coincidentes, una entidad para cada municipio, no?.
Soy ingeniero tec. en Topografía y creo que soy presa de la deformación profesional… 🙂
Muchas gracias otra vez.
Un saludo cordial
Hola Leonardo,
El solapamiento o superposición implica que comparten una misma superficie. Esto suele ocurrir cuando han existido malas prácticas a la hora de producir la cartografía, cuando no se lleva un control de la topología de las entidades de la capa. Cuando la cartografía se elabora correctamente y con unos criterios básicos de calidad, este tipo de problemas no suelen ocurrir.
Para el caso de los límites administrativos, la lógica nos dice que dos entidades administrativas no pueden compartir una misma superficie. El ser colindantes implica que comparten fronteras (mugas) y esto traducido a la cartografía, quiere decir que los polígonos que representan las distintas administraciones comparten lados y/o vértices, pero nunca debiera de existir un solapamiento entre dos polígonos distintos.
Espero haber resuelto tu duda Leonardo.
Saludos.
Hola como puedo hacer consultas en base de datos espaciales, y como combinar base de datos espaciales??? Agradecería mucho su apoyo.