Estas notas describen los datos de origen, su tratamiento y el proceso de elaboración de una grid de población para toda España a partir de los datos del Censo de 1887 (o del Nomenclátor de 1988).
Se trata de una versión refinada del mismo documento hecho para la CVA con la intención de que sea reproducible para otras CCAA. En el documento inicial se decriben numerosas pruebas. En este se decribe la versión final utilizada a partir de la clasificación de los edificios de Catastro.
En el proceso de descripción de la elaboración de la grid se vuelve a estimar la grid para la CVA, de forma que alguien familiar con R pueda ejecutar el proceso para el resto de España. Esto es cierto para todas las CCAA, tanto las de régimen común como las forales, ya que Goerlich (2025) ha procesado los datos de Catastro para todas ellas.
Una parte de las entidades están georeferenciadas, pero otras no disponen de coordenadas y, además, hay edificios diseminados.
El trabajo forma parte de un project de R totalmente autocontenido.
Fichero de origen: NE1888.zip. Contiene dos ficheros:
N1888_data.dta con los datos y las notas en
N1888_info.xlsx. Ver mail de Alfonso Díez de
12/12/2023.
En este caso, al contrario que en los datos de la CVA, no se efectúa corrección manual de coordenada alguna, y se toman los datos tal cual. Si hay errores o discrepancias, en las coordenadas o las entidades, estas se tratan de solucionar de forma automática –siendo imposible preveer todos los casos posibles que puedan aparecer–, pero no se efectúa ninguna corrección sobre el fichero original.
Observación 1:
Coordenada incorrecta detectada: Fruto de la experimentación con la primera versión de la grid generada se detectaron algunas coordenadas de entidades de Madrid (28079) que caían fuera de su término municipal. Una de ellas, M503, corresponde a la Barriada de Cuatro Caminos, cuya coordenada se asoció a un barrio en Estremera (28055) del mismo nombre. Ver mail de Alfonso Díez de 26/04/2025.
Aviso: ¡Esta coordenada está sin corregir en esta versión, 🤦!
01data.R.01data.R: Este script realiza una primera
inspección de los datos del fichero original. Contiene numerosos
comentarios.
Tiene 127,492 registros, pero los totales municipales aparecen bajo
la clase == "*" –9,125 registros–, por lo que una vez
filtrados disponemos de 118,367 registros.
Tenemos 9,287 municipios en 1887 con su correspondencia a 8,074 municipios en 2023. Hay 57 municipios actuales –2023– que no tienen correspondencia en 1887.
Todos los municipios en 1887 (ine87) –9,287– tienen
identificada su capital –9,287 capitales–.
Hay 34 registros en los que la provincia en 1887 –pro87–
no coincide con la provincia en 2023 –pro, que son los 2
primeros dígitos de ine–. La mayoría de estos casos, 25, se
deben a que Ceuta en 1887 estaba adscrita a la provincia de Cadiz
–pro87 == 11–.
Hay 11,112 registros que no tienen población
–p_h = p_d = 0–. De estos, hay algunos que si tienen
coordenadas.
Eliminando los 11,112 registros sin población en ambos conceptos de población disponemos de 107,255 registros operativos.
De estos, hay 58,837 registros con coordenadas y el resto, 48,418, son registros sin coordenadas.
Hay 71 coordenadas que caen fuera de los lindes Spain, pero esto lindes excluyen los condominios, e inspección visual muestra que muchas de estas coordenadas hacen referencia a los condominios. Puesto que estas entidades tienen coordenadas lo normal es que encuentren edificios de catastro donde asignar la población. La Dirección General del Catastro tiene los condominios asignados al municipio en el que tributan –excepto 1 caso, el de la Mancomunidad de Campoo-Cabuérniga–, mientras que en los catastros forales la situación es bastante heterogénea, pero si suelen incluir ficheros o códigos específicos para los condominnios, que en ningún caso fueron incorporados a la información catastral para la realización de este trabajo (Goerlich 2025). Presumiblemente también existen casos de entidades en condominios sin coordenadas.
Hay 8 coordenadas que caen fuera de la grid de referencia. Se trata de problemas de lindes marinos o de frontera, o de precisión de las coordenadas. Habrá que establecer una regla para resolver estos casos de forma automática. Lo normal es asignarlos al centroide de la celda más cercana, que es lo que se hizo.
Se genera un fichero de información:
01data_grid.xlsx: Información sobre coordenadas (SI/NO)
y población por provincias, categorías y municipios (ine e
ine87). Así como para las entidades que disponen de
coordenadas. Este resumen no incluye los registros que no tienen
población en ninguno de los dos conceptos que aparecen y que,
por tanto, son irrelevantes a efectos de la grid.
Entidades originales con coordenadas 58,837, de un total de
107,255, es decir, el 54.9%.El primer paso, antes de distribuir la población, es clasificar los edificios de catastro y generar los contornos urbanos.
Como paso previo el catastro, que está disponible en Provincias, se
pasa a CCAA. Este paro se hace en 02Catastro10CVA.R para la
CVA y hay que modificarlo para todas las CCAA:
02Catastro#####.R. Esto simplemente elimina algunos campos
innecesario y permite trabajar por CCAA.
Teniendo en mente la distribución de la población que hay que hacer se procedió a la generación de cortornos urbanos, identificación de los edificios que serán el soporte de la población diseminada y la clasificación de los edificios posteriores al año base o de partida.
La identificación se hace por municipio, que es como tenemos la población, esto tiene, sin embargo, un side effect. Las ditancias y los clusters se miden para los edificios dentro del municipio, es decir, un edificio puede ser aislado si medimos las distancias respecto al resto de edificios de su municipio, pero no si tenemos en cuenta los edificios de municipios limítrofes. Lo mismo sucede en el caso de los contornos urbanos, puesto que hay contornos urbanos de dos municipios que son contiguos. Este es, sin embargo, un problema menor, puesto que la población la tenemos por entidades de municipios.
El algoritmo que identifica cada edificio, de cada año, de cada municipio, se describe a continuación.
El algoritmo depende de algunos parámetros, que son idénticos a los necesarios en la generación de la grid de población –¡y tienen el mismo nombre!–. De hecho, algunos de estos parámetros ya no serán necesarios en la generación de la grid, puesto que los contornos se construyen ahora, y la decisión sobre la forma de los contornos debe ser tomada en este paso. En concreto,
missing_year <- FALSE: Hay casos en los que las
fechas del edificio no existen o son incorrectas. Este boolean
indica si debemos eliminarlas, TRUE, o mantenerlas,
FALSE. Mantenerlas asigna, en la práctica una fecha igual
al año 1000.
umbral_year <- 1900: Año para el que debemos
filtrar los edificios al construir los clusters –contornos
urbanos–. Si es NULL no se realiza ningún
filtrado.
snap <- 200: Distancia (m) entre edificios para
integrar un cluster. A mayor valor menor número de
clusters y más grandes. Esta distancia tiene base en la
delimitación actual del diseminado en el Nomenclátor.
HULL <- TRUE: Si es TRUE el
algorithmo para la generación del contorno urbano a partir del
cluster de edificios es una convex
hull. Si es FALSE se utiliza una concave
hull, de forma que el contorno se ajusta a los edificios más
exteriores del cluster. En este caso los siguientes tres
parámetros son de aplicación.
concavity <- 2: Medida relativa de concavidad.
Valores de 1 implican un contorno muy detallado, \(+ \infty\) es equivalente a una convex
hull. Es posible, pero no recomendable, usar valores menores de
1, ya que pueden generar formas bastante locas.
length_threshold <- 0: Cuando la longitud de un
segmento está por debajo de este umbral, deja de ser considerado para
mayor detalle. Los valores más altos dan como resultado formas más
simples.
seg <- 0.5: Aumenta la resolución de los nodos
–segmentos de tamaño más pequeño– en los contornos de los edificios para
ajustar la concave
hull a los lindes de los edificios.
Aunque no es estrictamente necesario, es conveniente que se
mantengan los mismos valores de los parámetros en ambos
procesos, para no generar inconsistencias. En concreto,
umbral_year debe mantenerse constante entre
procesos, clasificación de los edificios y contornos urbanos y
proceso de gridding.
Debe observarse que la generación de contornos está pensada para la distribución de la población de 1887, y no para generar contornos urbanos para cada año, en este caso los contornos deberán actualizarse, lo que no se hace. Sin embargo, un procedimiento similar podría servir para generar contornos para diversos años y visualizar el crecimiento urbano.
Los dos parámetros básicos sobre los que hay que tomar una decisión a priori, y condicionan totalmente el proceso de clasificación posterior, son:
umbral_year: año base. Los contornos urbanos donde
atribuir población de las entidades y los edificios aislados donde
atribuir la población diseminada se hacen con los edificios de Catastro
hasta ese año base (inclusive). Estos contornos
y edificios diseminados se mantendrán constantes en años
posteriores. A los contornos solo se atribuirá población de
entidades y a los edificios aislados solo población de edificios
diseminados.
snap: distancia que define cuando un edificio es
aislado o forma parte de un diseminado. Dado un conjunto de edificios,
un edificio es aislado –y constituye el soporte de la población en
edificios diseminados– si está a más distancia de snap de
cualquier otro edificio en el mismo municipio, por el contrario un
edificio pertenece a un cluster –que habrá que construir– si
está a menos de una distancia snap de otro edificio –un
cluster tiene al menos 2 edificios–. Obviamente la distancia
que debemos utilizar para definir edificios aislados o clusters
debe ser la misma.
Para el año base el proceso es sencillo.
Dado umbral_year se cogen, para cada municipio por
separado, todos los edificios de Catastro
hasta ese año. Se miden las distancias entre todos ellos. Los edificios
que están a menos de una distancia snap se dice que son
vecinos. A partir de aquí:
Los edificios que no tienen vecinos son edificios aislados, destinados –aunque no necesariamente– a albergar población diseminada.
Los edificios que son vecinos constituyen un cluster, y
habrá que construir su contorno. Esto se hace por una convex/concave
hull, y no tiene mayor problema una vez sabemos los vecinos de cada
cluster. Se introduce un indentificador, ID, de
cluster.
A partir de aquí la información se almacena en dos capas:
Edificios, Buildings, con tanto
registros como edificios de Catastro,
en los que se añade un campo, diseminado, que indica si el
edificio es aislado, diseminado = "SI", o pertenece a un
cluster, diseminado = "NO", y se añade un
identificador correlativo de cluster, ID, este
identificador solo está definido si diseminado = "NO", en
otro caso ID es NA, missing.
ContornosUrbanos, ContornosUrbanos,
con la geometría de los contornos, el identificador de cluster,
ID, y el número de edificios que forman el
cluster. Esta geometría es fija, y no se
modificará, a efectos de localizar la población, aunque encontremos
edificios de años posteriores que pertenecen a un cluster.
Dadas estas dos capas, determinadas a partir de
umbral_year, si diera la casualidad que
las entidades del municipio –sin coordenadas, caso B, y
aquellas cuyas coordenadas caen dentro de un contorno, caso A1– fueran
igual al número de clusters,
y la población diseminada ocupara todos los
edificios diseminados, dado un tamaño medio del hogar, entonces
el problema estaría resuelto, y no
necesitaríamos ningún ajuste adicional.
Sin embargo, esto no ocurre nunca en la práctica. Pueden darse dos casos:
Si las entidades y/o el diseminado no ocupan todo el soporte poblacional, entonces tenemos un problema de como determinar aquellos contornos y/o edificios aislados que quedarán vacíos.
Si las entidades y/o el diseminado existentes en 1887 ocupan más
contornos y/o edificios aislados, entonces tenemos el problema contrario
–si no queremos repetir contornos y/o edificios donde situar la
población–, necesitamos más contornos y/o edificios aislados donde
situar la población. Para solucionar este punto se clasificó cualquier
edificio posterior a umbral_year a partir del siguiente
algoritmo.
Partiendo de las dos capas anteriores, generadas para
umbral_year, se van añadiendo secuencialmente por años los
edificios que van apareciendo en Catastro
con posterioridad a umbral_year. La clasificación se
realiza edificio por edificio. Con los edificios que se añaden cada año
se procede de la siguiente forma.
Si un edificio está a una distancia inferior a
snap de un contorno –generado a partir de un
cluster– se asigna al cluster de edificios de dicho
contorno. ¡Pero no modifica el tamaño del contorno original! En
consecuencia, este edificio en la capa Buildings se
almacenará con diseminado = "NO" e ID el que
le corresponda. La capa ContornosUrbanos no se ve alterada.
En cierta forma los edificios clasificados en este paso no juegan, en el
sentido de que no albergarán nueva población si fuera necesario.
Sin embargo, conforme vamos añadiendo edificios en años posteriores y los contornos urbanos van creciendo debemos ajustarlos para medir las distancias de los nuevos edificios, por esa razón, a efectos de medir distancias, los contornos urbanos se re-construyen on-the-fly para medir las distancias de los nuevos edificios que se van añadiendo y poder clasificarlos secuencialmente.
Observación 2:
Anomalía detectada: Si aparecen muchos edificios
juntos en un año de un determinado núcleo urbano, es posible que algunos
estén a más de una distancia snap de un contorno y no se
asignen a él, sino que acaben generando un contorno independiente
fechado en ese año. Esto no necesariamente es malo a efectos de
distribución de la población de 1887.
Ejemplo: Campo-Arcis de Requena (46213).
Una vez descontados los edificios que han sido asignados a un
cluster en el paso anterior, si un edificio está a una
distancia al menos igual a snap respecto a todos los
edificios existentes en ese momento –los añadidos en ese año y
en todos los anteriores– se identifica como edificio
aislado. En consecuencia, este edificio en la capa
Buildings se almacenará con diseminado = "SI"
e ID = NA. La capa ContornosUrbanos no se ve
alterada.
Estas dos opciones no clasifican, necesariamente, todos los edificios añadidos en un año.
(i) Pueden surgir nuevos clusters de edificios que
delimiten nuevos contornos. Estos se añaden a la capa
ContornosUrbanos con un ID correlativo
respecto al último creado anteriormente, naturalmente con fecha en el
momento de su aparición. El tamaño de dicho contorno se mantendrá fijo
en años sucesivos. Los edificios se añaden a la capa
Buildings con diseminado = "NO" e
ID el que le corresponda en la asignación.
(ii) Pueden quedar edificios que no cumplan ninguna de las
condiciones anteriores. En principio parece raro, pero se dan casos
porque la distancia snap se mide respecto a entidades
diferentes. Para que un edificio sea asignado a un cluster ha
de estar a menos de snap distancia del contorno de dicho
cluster, si está a más distancia no es
asignado a dicho cluster, pero al mismo tiempo puede estar a
menos distancia snap de un edificio aislado anterior, de
forma que tampoco se clasificaría como edificio aislado, y queda sin
clasificar a partir de las reglas anteriores.
En principio este edificio debería formar un cluster con los
edificios aislados que han sido etiquetados como tales en años
anteriores, pero esto implica modificar la clasificación inicial
generada a partir de umbral_year, lo que no se considera ni
aceptable, ni deseable. La solución es que estos edificios residuales se
clasifican como aislados, y solo son susceptibles de recibir población
diseminada. En consecuencia, este edificio en la capa
Buildings se almacenará con diseminado = "NC"
e ID = NA. Se utiliza diseminado = "NC" para
poder distinguir los casos de diseminado = "SI", aunque
mantiene ID = NA porque no está asignado a ningún
cluster. El total de edificios diseminados se
identifica, pues, en la capa de Buildings por
ID = NA. La capa ContornosUrbanos no se ve
alterada.
La clasificación está implementada en los scripts
03CatastroData.R y 04CatastroContornos10CVA.R,
y ambas capas se almacenan en
A.ES.SDGC.10.CVA_clasificado.gpkg. Para cada edificio y
contorno se calcula el área, Area, en m². Un resumen de la
información generada de Buildings y de
ContornosUrbanos se almacena en
04CatastroContornos10CVA.xlsx.
En un segundo paso, una vez hecha la clasificación, se
calcula Sup2D, Sup3D, un índice de rugosidad
–TRI = Sup3D/Sup2D– y los estadísticos que ya se
calcularon para los municipios (Goerlich 2022), para los
edificios y los contornos. Para ello se utiliza la base
de datos MDT05 procesada por Goerlich (2023).
Nota de computación: Este proceso se ejecuta en los scripts:
02Catastro10CVA.R: Que transforma los datos
provinciales en datos de CCAA –haciendo que sean menos pesados al
eliminar muchas variables–, permitiendo que se pueda trabajar a nivel de
CCAA. Debe observarse que todos los datos de Catastro
procesados por Goerlich
(2025) están en el Sistema de Referencia de Coordenadas
(CRS) ETRS89-LAEA.
04CatastroContornos10CVA.R: Algoritmo de generación
de los contornos.
05CatastroMDT0510CVA.R: Añade la información sobre
altitud y rugosidad. Esta información procede del MTD05 procesado por Goerlich (2023), y su
CRS no tiene porque coincidir con el de la información de
Catastro procesada por Goerlich (2025). El
script reproyecta on-the-fly los datos de Catastro
para hacer el cálculo, pero la información se almacena en el vectorial
de Catastro con el CRS original, ETRS89-LAEA. En consecuencia, ello no
afecta al CRS de los datos almacenados de Catastro.
Observación 3:
Se detectaron algunos casos en los que la asignación de los edificios al municipio en Catastro no se correspondía con su asignación mediante localización espacial –estos casos se descubrieron porque al asignar altitud no había overlapping entre el MDT05 del municipio en cuestión y sus vecinos y las coordenadas de los edificios procedentes de Catastro–.
La solución fue asignar NA a los datos de altitud en
estos edificios, y sus contornos, y luego, en el proceso de
gridding filtrar estos edificios y sus contornos, de forma que
no se utilizan en el proceso de gridding por entender que se
trata de errores.
Ejemplo 1: En Huesca hay 3 edificios que en Catastro están asignados al municipio de Ayerbe (22039) que están localizados geográficamente en el municipio de Robres (22197).
Ejemplo 2: En Las Palmas hay 3 edificios que en Catastro están asignados al municipio de Las Palmas de Gran Canaria (35016) que están localizados geográficamente en el municipio de Agüimes (35002).
Para cada CCAA –incluyendo Pais Vasco y Navarra– habrá que ejecutar estos ficheros para la CCAA correspondiente, cambiando, además, las etiquetas de acceso. Por ejemplo, hay que cambiar 10CVA, de la Comunidad Valenciana, por 01AND para Andalucia o 12GAL, para Galicia.
El script 03CatastroData.R controla los
parámetros de clasificación de los edificios de Catastro,
y no debe modificarse. En caso de hacerlo, habría que
correr los scripts 04CatastroContornos#####.R y
05CatastroMDT05#####.R para que la clasificación de los
edificios de Catastro
fuera uniforme para todas las CCAA.
El Catastro utilizado fue descargado en abril de 2025, tanto para las CCAA de régimen comñun como para las forales.
06data_clean.RLa inspección del fichero original arrojó 8 celdas cuyas coordenadas caían fuera de la grid. Algunas son errores de lindes, y otras son claramente errores. Para evitar problemas posteriores, a estas celdas se les asignó las coordenadas del centroide de la celda más cercana del término municipal al que pertenece la entidad.
Una vez hecha esta corrección, si dejamos caer las coordenadas sobre la grid aparecen 43,788 celdas con población.
El fichero final quita algunas variables innecesarias, e incluye algunas otras relacionadas con los casos y la existencia de coordenadas.
Se envían a un fichero limpio de trabajo, Hoja
data_clean, junto con los estadísticos de partida. Estos
son los datos a poner en la grid.
El fichero 06data_clean.xlsx contiene información en
términos de porcentajes de entidades y población para cada uno de los
casos.
GEOSTAT2021 tiene 115,410 celdas habitadas para toda España.
Observación 4:
El fichero de coordenadas indica que estas están en el CRS: ETRS89-UTM30N.
En principio es raro que todas estén en UTM30N, al
menos las del Canarias, pero una inspección visual utilizando la
variable ZONA del fichero de datos parece indicar que esto
es así, ya que si las asignamos a su ZONA aparecen
desplazadas, mientras que si las asignamos al huso 30N aparecen
correctamente situadas.
En consecuencia, el proceso de gridding descrito en el apartado siguiente asumen que todas las coordenadas están en ETRS89-UTM30N. Si esto no es así, alguno de los resultados del proceso serán incorrectos.
El proceso de construcción de la grid descansa sobre el Catastro (Goerlich 2025) clasificado, y procede de forma diferente para los 3 casos considerados.
Para los casos A y B se utiliza la capa de
ContornosUrbanos, mientras que para el caso C se utiliza la
capa de Buildings. Si los contornos y edificios de
umbral_year son suficientes para asignar toda la población
entonces no buscamos contornos o edificios en años posteriores, si no lo
son, entonces buscamos contornos o edificios en años posteriores, el
incremento es de año en año, y se guarda registro de hasta el año en el
que ha habido que buscar.
Si no hay suficientes contornos/edificios para la asignación se reciclan. Esto sucedió, en el caso de la Comunidad Valenciana, en algunos pocos casos, como Alfafara (03010) o Castell de Cabres (12037).
En el caso de los contornos, la asignación de los casos B es por año y área –la entidad con mayor población se asigna al contorno de mayor área, después de una ordenación por años–.
Para el caso C la asignación es por año y altitud del edificio –el tamaño medio del hogar se asigna al edificio de menor altitud, después de una ordenación por años–. La altitud está deteminada a nivel de edificio a partir del área de su planta –footprint build-up area–. La altitud es un criterio arbitrario, que puede sustituirse por la rugosidad o cualquier índice que incorpore variables como área, altitud, rugosidad o pendiente.
Observación 5:
El script que genera la grid,
08Grid#####.R, reproyecta las coordenadas de las entidades
a ETRS89-LAEA, que es el CRS
de los datos de Catastro
procesados por Goerlich
(2025), y que coincide con el CRS de la grid de
referencia. En consecuencia, el proceso de gridding se realiza
en este CRS.
Ponemos en la grid la población de hecho, p_h. Hay 82 entidades para las que la población de hecho es nula, de forma que tenemos un total de 107,173 entidades, de las cuales disponen de coordenadas 58,831.
El caso A utiliza la capa de
ContornosUrbanos.
El proceso de pasar la población a la grid se realizó municipio a municipio a partir de los contornos de Catastro clasificado restringidos a un determinado año.
Para las entidades con coordenadas se procedió básicamente de la siguiente forma.
A partir de los contornos del Catastro clasificado pueden darse 2 casos que tratamos por separado.
Que la coordenada de una entidad caiga dentro, o muy cerca, de uno de los polígonos de las agrupaciones de edificios. Caso A1.
Que la coordenada de una entidad caiga lejos de cualquier agrupación de edificios.
En el primer caso, asignamos la población de la entidad a ese polígono, y transferimos la población a la grid por areal weighting.
Observación 6:
Areal weighting tiene el inconveniente de que asume una densidad uniforme dentro del contorno urbano, de forma que, si el contorno es grande –y no tiene intersección con otros contornos– todas las celdas interiores a dicho contorno tienen la misma población.
Esto tiene solución, si la distribución dentro del contorno urbano se hace depender de características de los edificios dentro del mismo. La clasificación de los edificios de Catastro permite calcular la población por edificio dentro del contorno urbano, y luego asignar la población a la celda de la grid en función de la población asignada la los edificios.
En aras a la simplicidad del proceso, esta versión de la grid no contempla esta posibilidad, y se asigna la población por areal weighting.
En el segundo caso, distinguimos, a su vez, entre dos posibilidades:
Si la población de la entidad es pequeña –en la práctica menor de un determinado umbral– entonces simplemente asignamos la población a la celda de la grid donde cae la coordenada. Caso A2.
Si la población de la entidad es relativamente grande –en la práctica superior a un determinado umbral– generamos un polígono cuadrado donde localizar la población. El área de dicho polígono se determina de la siguiente forma: a partir de las entidades de ese municipio que tienen asignado un polígono se calcula la superficie per cápita de cada uno de esos polígonos, y se toma como umbral per cápita el promedio de las superficies anteriores. El polígono para la entidad en cuestión es un cuadrado de área igual a la que resulta del producto de dicho umbral por la población de la entidad. Caso A3.
En resumen, podemos distinguir 3 casos:
Caso A1: Si una coordenada cae dentro del contorno urbano, o cerca –dado un umbral–, se asigna la población al mismo. El umbral de cercanía puede ser 0. En este caso las coordenadas que no caen dentro pasan a los casos 2 y 3.
Caso A2: Si la coordenada cae lejos –dado un umbral– y la población es pequeña –dado otro umbral– se asigna a la celda donde cae la coordenada.
Caso A3: Si la coordenada cae lejos –dado un umbral– y la población es grande –dado otro umbral– se genera un poligono cuadrado con superficie igual a su población por el tamaño medio de los poligonos per cápita a los que se les ha asignado población dentro de ese municipio.
En los casos 1 y 3 la transferencia final de la población del polígono a la grid se hace por areal weighting.
El proceso está gobernado por los siguiente parámetros (se muestran los valores por defecto):
integer <- TRUE: El proceso de areal
weighting implica una población en reales para los casos A1 y A3.
Este boolean indica si debemos mantener los reales,
FALSE, o ajustar a enteros, TRUE. El ajuste a
enteros se efectúa a nivel de caso, A1 o A3, pero si para una celda el
proceso genera un entero, dicho valor se mantiene en el proceso de
ajuste.
umbral_year <- 1900: Año para el que debemos
filtrar los edificios al construir los clusters –contornos
urbanos–. Si es NULL no se realiza ningún
filtrado.
La asignación de la población a los contornos urbanos, y en consecuencia la distinción entre los casos 1, 2 o 3, depende de 3 parámetros:
umbral_dist <- 100: Umbral de distancia: la
población se asigna a un contorno urbano si está a menos de esta
distancia (m). Puede ser 0. Las entidades que pasan esta condición
constituyen el caso A1, las que no lo pasan se evalúan para los casos A2
o A3.
umbral_pob <- 50: Umbral de población: la
población de una entidad no asignada a un contorno urbano se asigna
directamente a una celda si es menor de ese umbral de población, caso
A2, en caso contrario se evalúa bajo el caso A3.
umbral_area <- 100: Umbral de area (m²): m² por
persona para la generación de la huella del edificio en el caso de que
ninguna coordenada se asigne a los polígonos de edificios. En algunos
casos, hay entidades evaluadas bajo el caso A3, que no tienen entidades
evaluadas bajo el caso A1, en cuyo caso no hay umbral para determinar el
tamaño del polígono cuadrado donde situar a la población. En estos
casos, que no hay información sobre el caso A1, se considera este umbral
en m² por persona.
El caso B utiliza la capa de
ContornosUrbanos.
Como ya se ha indicado, en el caso de los contornos, la asignación de los casos B es por año y área –la entidad con mayor población se asigna al contorno de mayor área, despues de una ordenación por años–.
Observación 7:
En algún caso no existen edificios sueltos para asignar el diseminado. Cuando esto sucede el caso C se trata como el caso B, y se aplican sus reglas.
Estos casos se identifican porque en el fichero de registro
08Grid#####.xlsx se consigna household_size
igual a 0.
Ejemplo 1: Monasterio (19191) (Guadalajara), cuyo diseminado es de 5 personas, y curiosamente no tiene caso B. También aparecen en esta provincia con este caso los municipios de Pinilla de Molina (19219), Puebla de Valles (19229) y Villaseca de Henares (19322).
Ejemplo 2: Arama (20012) e Ikaztegieta (20044) (Guipuzkoa), cuyo diseminado es de 112 y 141 personas respectivamente, y curiosamente no tienen caso B en ninguno de los dos casos.
Ejemplo 3:
Naturalmente esto solo aplica si hay población para el caso C. Si no hay población para el caso C es irrelevante si hay edificios o no.
Ejemplo 4: Alique (19019) (Guadalajara) no tiene edificios sueltos para asignar el diseminado, pero tampoco tiene población diseminada.
El caso C utiliza la capa de
Buildings.
El tamaño medio del hogar se fija en 8
personas para todos los municipios. Ello significa que si la
población en diseminado son 80 personas tenemos 10 unidades de población
a distribuir, es decir, deberemos buscar 10 edificios donde situar la
población. Este valor está parametrizado,
average_household_size, de forma que es posible cambiarlo
fácilmente y experimentar. Como en la práctica cada hogar –unidad de
población– se asignará a un edificio de Catastro,
ello significa que debemos buscar 10 edificios donde ubicar la población
en diseminado.
El proceso es secuencial después de asignar las poblaciones de los Casos A y B, y procede de la forma descrita anteriormente. Al igual que antes, la asignación se efectuó a nivel de municipio.
El proceso está está gobernado por los mismos parámetros que el caso anterior más el siguiente parámetro:
average_household_size <- 8: Tamaño medio del hogar
para la distribución de la población en diseminado.Este proceso, que probablemente es el más crucial desde el punto de vista de la dispersión de la población, es incierto en cualquier caso.
Observación 8: Implementación
Como consecuencia de las particularidades detectadas, los
scripts correspondientes se fueron modificando. Los
scripts más completos son, por ejemplo,
05CatastroMDT0502ARA.R, 05CatastroMDT0505CAN.R
o 05CatastroMDT0507CLE.R en relación a los errores de
asignación de edificios en Catastro y 08Grid08CLM.R en
relación a la falta de edificios aislados para las distribución del
diseminado del caso C.
Modificar los parámetros del proceso puede hacer que aparezcan particularidades en otras CCAA.
Los parámetros que regulan el gridding se leen en el
script 07GridData.R y si se cambian es necesario
volver a correr todos los scripts 08Grid#####.R
que es donde se calcula la grid.
La grid, de acuerdo con el algoritmo del apartado anterior,
se genera para la Comunidad Valenciana –10CVA– en el script
08Grid10CVA.R, que deberá ser modificado para cada
CCAA.
Como ya se ha indicado antes, el gridding se efectúa
municipio a municipio y caso por caso, A1, A2, A3, B y C, y se almacena
la grid final y todos los resultados
intermedios en el fichero 08Grid10CVA.xlsx.
Las hojas de dicho fichero, y la información almacenada, son las siguientes:
Parametros: Parámetros en el gridding, que
son los leídos en 07GridData.R.
Municipios: Municipios de la CCAA para la que se
efectúa el gridding con información asociada de cada caso y el
proceso de gridding.
Entidades: Entidades originales con información
asociada del caso al que pertenece cada entidad e información
asociada.
GridA: Celdas del caso A.
GridA1: Celdas del caso A1.
GridA2: Celdas del caso A2.
GridA3: Celdas del caso A3.
GridB: Celdas del caso B.
GridC: Celdas del caso C.
Grid: Grid final resultante.
GridM: Grid a nivel municipal, con
información del caso al que pertenece cada celda de cada municipio. Es
útil para rastrear casos particulares de municipios.
El proceso generó, para la Comunidad Valenciana, 7,340 celdas habitadas, para una población de 1,459,458 habitantes.
Por casos, las celdas habitadas son las siguientes:
Caso A: Celdas habitadas: 3,212. Población: 1,312,365
Caso B: Celdas habitadas: 2,004. Población: 55,799.
Caso C: Celdas habitadas: 4,545. Población: 91,294.
Observación 9: Sensibilidad al parámetro para la generación de contornos urbanos
La diferencia entre esta versión y la generada en una versión
inicial, en la que se utilizó un snap de 100m entre
edificios para construir los contornos urbanos, indica que aumentar el
snap incrementa la dispersión de la población en términos
de celdas habitadas. Ello resulta natural en los casos A y B, ya que
genera contornos más amplios sobre los que distribuir la población, pero
también se observa en el caso C sin una explicación aparente.
El proceso anterior, con un snap de 100m entre edificios
para construir los contornos urbanos, generó, para la Comunidad
Valenciana, 6,655 celdas habitadas.
Por casos, las celdas habitadas son las siguientes:
Caso A: Celdas habitadas: 2,974.
Caso B: Celdas habitadas: 1,754.
Caso C: Celdas habitadas: 4,255.
El proceso completo, implementado en el project, es el siguiente.
Lo primero que hay que hacer es
trasformar los ficheros de Catastro
de provinciales a CCAA. Ejemplo,
02Catastro10CVA.R.
Este es un proceso bastante manual, en el que hay que reunir las
provincias de cada CCAA y agruparlas en una única layer que
luego se graba en gpkg. La inspección de
02Catastro10CVA.R, que ejecuta este proceso para la
Comunidad Valenciana, debe dejar claro lo que hay que hacer. Hay que
introducir los códigos y nombres de la provincia al generar el fichero
para la CCAA. Dichos códigos y nombres están en el fichero
PROV2CCAA.xls, en el directorio data. La
layer de salida debe identificar la CCAA con código y 3 letras:
10.CVA para la Comunidad Valenciana. ¡Obsérvese el punto de
separación! Este proceso debe hacerse incluso para las CCAA
uniprovinciales, por codificación y porque reduce el tamaño de los
ficheros de Catastro.
Los catastros forales requieren ajustes específicos.
Los códigos e identificadores de 3 letras para las CCAA son los siguientes:
| Código | Identificador |
|---|---|
| 01 | AND |
| 02 | ARA |
| 03 | AST |
| 04 | BAL |
| 05 | CAN |
| 06 | CTB |
| 07 | CYL |
| 08 | CLM |
| 09 | CAT |
| 10 | CVA |
| 11 | EXT |
| 12 | GAL |
| 13 | MAD |
| 14 | MUR |
| 15 | NAV |
| 16 | PAV |
| 17 | RIO |
| 18 | CEU |
| 19 | MEL |
Lo segundo que hay que hacer es clasificar los edificios de Catastro. Este proceso es independiente del gridding.
Decidir las opciones de clasificación y guardarlas en el
script 03CatastroData.R. Si se usan las opciones
por defecto, descritas en el apartado 3, no hace falta tocar este
fichero.
A continuación ejecutar, para cada CCAA, los scripts
04CatastroContornos#####.R y
05CatastroMDT05#####.R para efectuar la clasificación y
añadir los estadísticos de altitud, rugosidad y asociados. Estos
procesos tardan bastante. Para la CVA tardaron unos 2 días
04CatastroContornos10CVA.R y 1 día
05CatastroMDT0510CVA.R.
Estos procesos solo requieren cambiar la lectura de datos, municipios de la CCAA y Catastro, y el código de grabación del fichero de datos de salida.
Finalmente se ejecuta el proceso de gridding a nivel de CCAA.
Una vez decididas las opciones para el gridding,
descritas en el apartado 5.1, se guardan en el script
07GridData.R. Si se usan las opciones por defecto no hace
falta tocar este fichero.
Si se desea cambiar alguna cuestión menor, como por ejemplo la asignación del diseminado a edificios por rugosidad en lugar de por altura, esto no está parametrizado, y hay que tocar los scripts. ¡Mejor consultar!
A continuación ejecutar 08Grid#####.R para cada
CCAA. La grid para la CCAA correspondiente está en la hoja
Grid de 08Grid#####.xlsx.
Una vez ejecutado el proceso para todas las CCAA es necesario
ensamblar la grid nacional. Para ello es necesario leer las
hojas Grid de todos los ficheros
08Grid#####.xlsx, agregar por identificador de celda,
GRD_ID, y sumar las poblaciones correspondientes. Este
proceso está implementado en el script
09Grid.R.
Al margen de las 8 coordenadas que caen fuera de la grid, y a las que se asignó la coordenada del centroide de la celda más cercana del municipio al que pertenecen, hay algunas cuestiones que podrían mejorarse.
Hay 57 municipios actuales, existentes a fecha 1 de enero de 2023,
que no aparecen en la base de datos N1888. En muchos casos,
si no en todos, si podría establecerse esta correspondencia, simplemente
buscando en que municipio actual hay alguna entidad que dió origen a
estos municipios que no aparecen. Esta identificación mejoraría en algo
la búsqueda de edificios de Catastro
en el proceso de gridding.
En el caso de la CVA hay 6 municipios afectados: La Romana (03114), San Isidro (03904), San Rafael del Río (12101), Benifairó de les Valls (46058), San Antonio de Benagéber (46903) y Benicull de Xúquer (46904).
Sin embargo, estos casos no aparecieron en las pruebas preliminares que se hicieron con los datos de la CVA, ¿por qué? Porque se hizo una identificación, manual o automática, de las entidades que pertenecían a dichos municipios, aunque en un par de casos, La Romana (03114) y San Rafael del Río (12101) todo indica que hay un error en algún sitio.
Por ejemplo, La Romana (03114), codmat = A1234, ya
aparece con código ine = 03114 en el fichero original de la
experimentación con la CVA, de forma que no entiendo porque aparece en
este fichero con ine = 03093, igual a ine87,
en lugar de ine = 03114. Se desconoce si el
error procede de este fichero o del de la
experimentación con la CVA.
San Isidro (03904) se corresponde con la entidad Estación de
Albatera-Catral (A37) asignada a Albatera (03005), de donde se segrega,
de forma que para esta entidad podría consignarse
ine = 03904 en lugar de ine = 03005.
San Rafael del Río (12101), codmat = CS1961, ya aparece
con código ine = 12101 en el fichero original de la
experimentación con la CVA, de forma que no entiendo porque aparece en
este fichero con ine = 12121, igual a ine87,
en lugar de ine = 12101. Se desconoce si el
error procede de este fichero o del de la
experimentación con la CVA.
Benifairó de les Valls (46058) está en Villa de la Unión (46522) en 1887, junto con Faura (46122), que es a quien se asigna en la base de datos. Desagregar esto, y atribuir una parte de Villa de la Unión (46522) a Benifairó de les Valls (46058) requiere trabajo manual, pero este se hizo en el caso del ejemplo de la CVA. Naturalmente ello añade un registro adicional al fichero de entidades.
San Antonio de Benageber (46903) se corresponde con la entidad Venta
y Casa de Pla del Pou (V1386) asignada a Paterna (46190), de donde se
segrega, de forma que para esta entidad podría consignarse
ine = 46903 en lugar de ine = 46190.
Benicull del Xúquer (46904) se corresponde con la entidad del Caserío
de La Muntañeta (V1420) asignada a Polinyà de Xúquer (46197), de donde
se segrega, de forma que para esta entidad podría consignarse
ine = 46904 en lugar de ine = 46197.
Esta información no se ha aprovechado al hacer la asignación de
ine87 a ine. Podría aprovecharse la que ya se
conoce e indagar la que no se conoce.
Goerlich, F. J. (2022) Un índice de rugosidad del terreno a escala municipal –updated–. –superficie 2D versus superficie 3D y rugosidad–. on-line. (01/12/2022).
Goerlich, F. J. (2023) Superficie planimétrica versus superficie del paisaje en España. –superficie 2D versus superficie 3D–. on-line. (16/05/2023).
Goerlich, F. J. (2025) Catastro INSPIRE. –Haciendo fácil lo que las instituciones hacen difícil–. on-line (14/04/2025).