miércoles, 7 de mayo de 2008

Procesando el catastro

Habitualmente tengo que lidiar extrechamente con la información de catastro. Lo cierto es que resulta un tema bastante enrevesado, lo que me llevó incluso a pensar si el término "catastro" provenía de "trasto" o "catástrofe".

Sin embargo, la definición de la RAE es la siguiente:

catastro

1. m. Censo y padrón estadístico de las fincas rústicas y urbanas.

2. m. Contribución real (...)


Bromas a parte, el catastro ha experimentado un gran avance en los últimos años y prueba de ello son sus servicios y productos, sobre todo el servicio WMS. Un libro muy ilustrativo de esta evolución e incorporación de nuevas tecnologías es "El Catastro: del Archivo a Internet" distribuido gratuitamente desde la página oficial del catasto (http://www.catastro.meh.es/).

Sin embargo, dado la estructuración actual de los datos catastrales no resulta fácil operar con ellos ni extraer nuevos datos. Por esa razón, estamos elaborando una pequeña herramienta para traducir el campo "CONSTRU" de una capa de catastro de modo que sea posible realizar ciertos análisis con un SIG.



Actualmente, ya tenemos una versión alpha que está programada como un script de OpenJUMP, pero se prevee implementar una extensión en gvSIG+SEXTANTE e incorporarla al repositorio de contribuciones para uso público.

4 comentarios:

XuRxO dijo...

Hola Nacho,

¿Puedes comentar un poco cuál era el problema exactamente del campo y qué has hecho con él?

Si se trata de procesamiento supongo que habrás descartado hacer scripting con la calculadora de campos (en Python), ¿por alguna razón en particular?

Un saludo!

Nacho Uve dijo...

No he desarrollado mucho esta entrada del blog porque esperaba darle alguna vueltecilla más al tema, pero te cuento.

El campo CONSTRU de catastro tiene un formato del tipo:

-I+I+IV+TZA

Esto no es muy manejable computacionalmente.

El script lo que hace es:
1.- Modificar el schema de la capa creando campos nuevos para albergar la información extraída.
2.- Traducir esta información de alturas en valores enteros, y permitiendo por ejemplo, quedarnos con la máxima altura de esa construcción.
3.- Rellenar campos con los tipos de morfología encontrados (terraza, Solar, etc).

La elección de hacerlo en OpenJUMP es simplemente porque tengo mucha más soltura que con gvSIG y para prototipados iniales consumo menos tiempo.

Pero evidentemente con la calculadores de campos de gvSIG usando funciones python se podría hacer perfectamente.

Por cierto, has inaugurado los comentarios del blog!!! Qué ilusión!!

Un abrazo!!

Rafael dijo...

Esta esta "pequeña" herramiente definitivamente disponible para alguna aplicación de las que comentas??

Nacho Uve dijo...

Pues aún no la he puesto en SEXTANTE, porque he estado muy ocupado con otras cosas. A ver si en un rato, me pongo con eso.