iso 19152 información geográfica – modelo para el Ámbito de la … normas internacionales iso....

1

ISO 19152

Información Geográfica – Modelo para el Ámbito de la Administración del Territorio (LADM)

INTRODUCCIÓN

Esta norma internacional define el Modelo para el Ámbito de la Administración del Territorio (Land Administration Domain Model – LADM). El LADM es un modelo conceptual y no una especificación de producto de datos (en el sentido de la Norma ISO 19131).

El propósito del LADM no es reemplazar a los sistemas existentes, sino proporcionar un lenguaje formal para describirlos, de manera que sus similitudes o diferencias se puedan entender mejor. Se trata de una norma descriptiva, no preceptiva.

La administración del territorio comprende un gran campo de trabajo; esta norma internacional se centra en la parte de administración del territorio que corresponde a los derechos, responsabilidades y restricciones que afectan a la tierra (o al agua), y a sus componentes geométricas (geoespaciales). El LADM proporciona un modelo de referencia que servirá para dos objetivos:

- proporcionar una base extensible para el desarrollo y refinamiento de sistemas eficientes y efectivos de administración del territorio, basados en una Arquitectura Guiada por el Modelo (Model Driven Arquitecture – MDA), y

- permitir la comunicación entre los interesados involucrados, tanto dentro de un mismo país como entre diferentes países, basándose en un vocabulario común (esto es, una ontología) que implica el modelo.

El segundo objetivo es relevante para la creación de servicios de información normalizados en un contexto nacional o internacional, donde la semántica de la administración del territorio se tiene que compartir entre regiones o países, para permitir las traducciones necesarias. Durante el diseño del modelo se tuvieron en cuenta cuatro consideraciones que:

- cubrirá los aspectos comunes de la administración del territorio en todo el mundo; - estará basado en el marco de trabajo conceptual de “Catastro 2014” de la Federación

Internacional de Geómetras (International Federation of Surveyors - FIG); - será lo más simple posible con el objetivo de que en la práctica sea útil; - los aspectos geoespaciales seguirán el modelo conceptual de ISO/TC211.

Hasta ahora, la mayoría de los países (o estados, o provincias) han desarrollado sus propios sistemas de administración del territorio. Un país opera con un sistema de registro de titularidades subjetivas y otro con un sistema de registro de títulos de propiedad real. Unos sistemas están centralizados y otros descentralizados. Unos sistemas están basados en linderos aproximados y otros en linderos fijados. Unos sistemas tienen un trasfondo fiscal y otros, jurídico. Las diferentes implementaciones (fundamentos) de los diversos sistemas de administración del territorio conllevan que la comunicación transfronteriza eficiente no sea fácil. Sin embargo, mirando desde la distancia, se observaría que los diferentes sistemas son en principio esencialmente lo mismo: todos están basados en las relaciones entre las personas y la tierra, unidos por derechos (propiedad o uso) y están en la mayoría de los países influidos por los desarrollos de las Tecnologías de la Información y de la Comunicación (TIC). Además, las

2

dos funciones principales de todo sistema de administración del territorio (incluyendo el catastro o el registro) son:

- mantener el contenido de esas relaciones actualizado (basado en la regulación y las transacciones relacionadas) y

- proporcionar información a partir de los registros (nacionales).

La administración del territorio se describe como el proceso de determinar, registrar y difundir información sobre la relación entre las personas y la tierra. Si se entiende la propiedad como un mecanismo a través del cual se tienen derechos sobre la tierra, también podemos hablar de titularidad de la tierra. Una característica principal de la tenencia de la tierra es que refleja una relación social relativa a los derechos sobre la tierra, lo que significa que en cierta jurisdicción, la relación entre las personas y la tierra se reconoce como una relación jurídica válida. Estos derechos reconocidos son en principio susceptibles de inscripción, con el propósito de asignar cierto significado jurídico al derecho registrado (por ejemplo, un título de propiedad). Por lo tanto, los sistemas de administración del territorio no son solo “gestores de información geográfica”, ya que representan relaciones jurídicas entre las personas, y entre éstas y la tierra.

Como la actividad de administración del territorio implica grandes volúmenes de datos, los cuáles son en su mayoría de naturaleza dinámica, y como además requiere un continuo proceso de mantenimiento, el rol de las TIC alcanza una importancia estratégica. Sin la disponibilidad de los sistemas de información será difícil garantizar un buen cumplimiento con respecto a las demandas cambiantes de los clientes. Ahora las organizaciones se están enfrentando cada vez más al rápido desarrollo tecnológico, al empuje tecnológico (Internet, las bases de datos geoespaciales, las normas de modelado, los sistemas abiertos y los SIG), así como a la demanda creciente de nuevos servicios, la demanda del mercado (administración electrónica, desarrollo sostenible, transmisión electrónica y la integración de sistemas y datos públicos). Modelar es una herramienta básica, que facilita el adecuado desarrollo y reestructuración de sistemas y que, además, constituye la base para la comunicación eficaz entre diferentes sistemas.

La normalización se ha convertido en un proceso bien conocido en el trabajo de las administraciones del territorio y de los registros de la propiedad. Tanto en sistemas analógicos como digitales, se requiere de normas para identificar los objetos, las transacciones, las relaciones entre objetos (por ejemplo, las parcelas, en general referidas como unidades espaciales) y las personas (por ejemplo, ciudadanos, jurídicamente referidos como sujetos y generalmente referidos como interesados), la clasificación de usos del suelo, el valor de la tierra, la representación cartográfica de objetos, etc. Los sistemas digitales requieren de una mayor normalización cuando se introduce topología y la identificación de límites únicos. En los sistemas de administración del territorio y en los registros existentes, la normalización generalmente está limitada a la región, o jurisdicción, donde opera la administración del territorio (incluyendo el catastro o el registro). La apertura de los mercados, la globalización, y el desarrollo y mantenimiento efectivo y eficaz de sistemas (genéricos) flexibles, requieren de una mayor normalización.

El objeto y campo de aplicación de esta norma internacional está descrito en el capítulo 1. La conformidad con esta norma internacional se proporciona en el capítulo 2 y las pruebas de conformidad se especifican en el anexo A. Las normas para consulta se presentan en el capítulo 3 y los términos usados, las definiciones y las abreviaturas en el capítulo 4. El capítulo 5 proporciona una visión global de los paquetes. El capítulo 6 introduce las clases, los atributos y las asociaciones en detalle. El anexo B

3

explica las representaciones 2D y 3D de las unidades espaciales. En el anexo C está disponible un conjunto completo de ejemplos informativos (utilizando instancias a nivel de clases).

Se debe resaltar que se trata de un modelo de dominio genérico. Es extensible y es probable que se necesiten atributos, operadores, asociaciones y quizá incluso clases adicionales para una región o país específico; véanse algunos perfiles nacionales en el anexo D. Las partes específicas del LADM se detallan más a fondo: los perfiles espaciales en el anexo E y los perfiles jurídicos en el anexo F. Algunos ejemplos de utilización del LADM en un contexto específico son: las parcelas catastrales de INSPIRE que se proporcionan en el anexo G, la integración del LADM con el Sistema agrícola de Identificación de Parcelas Terrestres (Land Parcel Identification Systems – LPIS) de la Unión Europea en el anexo H, y el Modelo para el Ámbito de la Tenencia Social (Social Tenure Domain Model – STDM) en el anexo I. Es posible usar solo un subconjunto, o perfil, del LADM para una implementación específica.

El anexo J proporciona una visión de las tablas de códigos como base para describir una enumeración flexible.

La construcción de bases de datos externas con datos de los interesados, las direcciones, los impuestos, los usos del suelo, la cobertura terrestre, la valoración, la red física de servicios y los datos de los archivos, quedan fuera del campo de aplicación del LADM. Sin embargo, el LADM proporciona clases estereotipadas de esos conjuntos de datos (si están disponibles), véase el anexo K. Las clases interfaz están en el anexo L. El anexo M hace algunas observaciones en relación a los modelos de procesos. La historia y los aspectos dinámicos se incluyen en el anexo N. El anexo O explica el vínculo con otras normas internacionales ISO.

1. Objeto y campo de aplicación

Esta norma internacional:

- define un Modelo de referencia para el Ámbito de la Administración del Territorio (Land Administration Domain Model – LADM) que cubre los componentes básicos de la información relacionada con la administración del territorio (incluyendo aquellos del agua y del terreno, y los elementos sobre y bajo la superficie terrestre);

- proporciona un modelo conceptual abstracto con cuatro paquetes relacionados con 1) los interesados (personas y organizaciones); 2) las unidades básicas administrativas, los derechos, las responsabilidades y las restricciones

(derechos de propiedad); 3) las unidades espaciales (parcelas, el espacio jurídico de los edificios y las redes de

servicios); 4) las fuentes espaciales (levantamientos) y representaciones espaciales (geometría y

topología);

- proporciona una terminología para la administración del territorio, basada en varios sistemas nacionales e internacionales, siendo lo más simple posible para que en la práctica sea útil. La terminología permite tener una descripción común de diferentes prácticas formales o no formalizadas y de los procedimientos de varias jurisdicciones;

- proporciona una base para los perfiles nacionales y regionales; y

4

- permite la combinación de información de administración del territorio procedente de diferentes fuentes, de manera coherente.

Lo siguiente está fuera del campo de aplicación de esta norma internacional:

- la interferencia con leyes de administración del territorio (nacional) que pueden tener implicaciones jurídicas;

- la construcción de bases de datos externas con datos de los interesados, direcciones, valoración, usos del suelo, coberturas, red física de servicios, archivos y datos de impuestos. Sin embargo, el LADM proporciona clases estereotipadas para estos conjuntos de datos para indicar qué elementos del conjunto de datos espera el LADM para esas fuentes externas, si están disponibles; y

- el modelado de los procesos de administración del territorio.

2. Conformidad

El LADM consta de tres paquetes y un subpaquete, y para cada uno de ellos se especifica una prueba de conformidad en el anexo A. Se especifican tres niveles de conformidad para cada (sub)paquete: nivel 1 (nivel bajo), nivel 2 (nivel medio) y nivel 3 (nivel alto). El nivel 1 analiza las clases básicas de cada paquete y el nivel 2 incluye también las clases más comunes. El nivel 3 incluye todas las clases. Cualquier LADM que afirme que es conforme con esta norma internacional debe satisfacer los requisitos del anexo A.

3. Normas para consulta

The following referenced documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO 4217:2008, Códigos para la representación de las divisas y los fondos

ISO 8601:2004, Elementos de datos y formatos de intercambio – Intercambio de información – Representación de fechas y horas

ISO/IEC 13240:2001, Tecnología de la información – Descripción de documentos y lenguajes de procesamiento – Intercambio Normalizado de Documentos Multimedia Interactivos (Interchange Standard for Multimedia Interactive Documents - ISMID)

ISO 14825:2011, Sistemas de transporte inteligente – Ficheros de Datos Geográficos (Geographic Data Files – GDF) – GDF5.0

ISO/TS 19103:2005, Información Geográfica – Lenguaje de esquemas conceptuales

ISO 19105:2000, Información Geográfica – Conformidad y pruebas

ISO 19107:2003, Información Geográfica – Esquema espacial

ISO 19108:2002, Información Geográfica – Esquema temporal

5

ISO 19111:2007, Información Geográfica – Sistemas de referencia espaciales de coordenadas

ISO 19115:2003, Información Geográfica – Metadatos

ISO 19125-2:2004, Información Geográfica – Acceso a fenómenos simples – Parte 2: Opción SQL

ISO 19156:2011, Información Geográfica – Observaciones y medidas

4. Términos, definiciones y abreviaturas

4.1 Términos y definiciones

Para los propósitos de este documento se aplican los siguientes términos y definiciones.

4.1.1 fuente administrativa: Fuente (4.1.21) con la descripción administrativa (cuando sea aplicable) de los interesados (4.1.13) afectados, los derechos (4.1.20), las restricciones (4.1.19) y las responsabilidades (4.1.18) creadas y las unidades básicas administrativas (4.1.2) afectadas. EJEMPLO 1 Es la evidencia del derecho de un interesado con una unidad básica administrativa. EJEMPLO 2 Un documento que describe una transacción (una escritura) o una declaración del titular del registro. 4.1.2 unidad básica administrativa: baunit Entidad administrativa, sujeta a registro (por ley), o inscripción (por derecho no formalizado (4.1.20), o derecho consuetudinario u otra relación social de tenencia), consistente en cero o más unidades espaciales (4.1.23) a la que se asocia como entidad completa, (uno o más) derechos (por ejemplo, derecho de propiedad o derecho de uso del terreno (4.1.9)), responsabilidades (4.1.18) o restricciones (4.1.19) únicos y homogéneos, tal y como se incluye en el sistema de administración del territorio (4.1.10). NOTA 1 “Único” significa que un derecho, restricción o responsabilidad se ostenta por uno o más interesados (4.1.13) (por ejemplo, propietarios o usuarios) para toda la unidad básica administrativa. “Homogéneo” significa que un derecho, restricción o responsabilidad (por ejemplo, propiedad, uso, tenencia social, alquiler, o servidumbre) afecta a la unidad básica administrativa completa. Para las restricciones es posible que haya cero interesados. NOTA 2 Una unidad básica administrativa puede jugar el papel de interesado, por ejemplo, cuando el titular del derecho es una unidad básica administrativa (y no una persona u organización). NOTA 3 Una baunit debería tener un identificador único cuando se registra o almacena. NOTA 4 Una baunit puede consistir en cero unidades espaciales, cuando existe un registro y no se ha catastrado el objeto. NOTA 5 Las restricciones y las responsabilidades se pueden asociar a sus propias baunits, cada una con su propio tipo de unidad espacial. EJEMPLO Una unidad de condominio que comprende dos unidades espaciales (por ejemplo, un apartamento y un garaje), una granja que comprende una unidad espacial (por ejemplo, una parcela de terreno), una servidumbre que comprenda una unidad espacial (por ejemplo, una carretera que representa el derecho de paso), un área de consolidación del terreno, o una unidad de derecho de uso con varios titulares del derecho y con objetos delimitados.

6

4.1.3 frontera: lindero Conjunto que representa el límite de una entidad. [ISO 19107:2003, 4.4] NOTA El término frontera se usa normalmente en el contexto de geometría, siendo conjunto, una colección de puntos o de objetos que representan a esos puntos. En otros ámbitos, el término se usa metafóricamente para describir la transición entre una entidad y el resto del universo de discurso. 4.1.4 cara lindero: Cara (4.1.7) que se usa en la representación tridimensional de un lindero (4.1.3) de una unidad espacial (4.1.23). NOTA Las caras lindero se utilizan cuando las caras verticales y no limitadas implicadas de una cadena de caras lindero (4.1.5) no son suficiente para describir las unidades espaciales 3D. Las caras lindero cierran volúmenes en altura (por ejemplo, la planta de cada apartamento), o en profundidad (por ejemplo, un garaje subterráneo) o en todas las otras direcciones para formar un volumen limitado. Los volúmenes representan espacio jurídico (en contraste con el espacio físico). 4.1.5 cadena de caras lindero: Lindero (4.1.3) que forma parte del exterior de una unidad espacial (4.1.23) NOTA Las cadenas de caras lindero se utilizan para representar los linderos de las unidades espaciales por medio de cadenas de líneas en 2D. Esta representación 2D es un lindero 2D en un sistema 2D de administración del territorio (4.1.10). En un sistema de administración del territorio 3D, representa una serie de caras lindero (4.1.4) verticales donde se supone un volumen no limitado, rodeado por caras lindero, que se interseca con la superficie de la Tierra (tal y como se representa tradicionalmente en los mapas catastrales). 4.1.6 unidad de edificación: Componente de una edificación (el espacio jurídico, inscrito o no formalizado de la entidad física). NOTA Una edificación se puede usar para diferentes propósitos (por ejemplo, como vivienda o comercio) o puede estar en construcción. EJEMPLO Un apartamento, un tramo de escaleras, un portal, un garaje, una plaza de aparcamiento o la lavandería. 4.1.7 cara: Primitiva topológica bidimensional [ISO 19107:2003, 4.38] NOTA La representación geométrica de una cara es una superficie. La frontera de una cara es el conjunto de arcos orientados del mismo complejo topológico que están asociados con la cara a través de las relaciones de frontera. Los arcos pueden organizarse en anillos. 4.1.8 grupo de interesados:

7

Cualquier número de interesados (4.1.13), que juntos forman una entidad distinta, con cada interesado registrado. NOTA Un grupo de interesados puede ser miembro interesado (4.1.14) de otro grupo de interesados. EJEMPLO Una asociación (con cada socio registrado como interesado), o dos tribus (con cada tribu registrada como un interesado). 4.1.9 terreno: La superficie de la Tierra, los materiales de debajo, el aire de arriba y todas las cosas fijas al suelo. [UN/ECE, 2004] 4.1.10 administración del territorio: Proceso de determinación, registro y difusión de información sobre la relación entre las personas y el terreno (4.1.9). NOTA En muchos países la información de administración del territorio se determina, registra y difunde bajo el paraguas del catastro o del registro de la propiedad. Ambas instituciones se pueden unificar en una única organización (oficial). 4.1.11 nivel: Conjunto de unidades espaciales (4.1.23), con una coherencia geométrica, topológica o temática. EJEMPLO 1 Un nivel de unidades espaciales para el catastro de urbana y otro para unidades espaciales del catastro rústico. EJEMPLO 2 Un nivel de unidades espaciales para definir unidades básicas administrativas (4.1.2) asociadas con derechos (4.1.20) y otro nivel de unidades espaciales para definir unidades básicas administrativas asociadas con restricciones (4.1.19). EJEMPLO 3 Un nivel de unidades espaciales para definir las unidades básicas administrativas asociadas con derechos formales, un segundo nivel de unidades espaciales para definir unidades básicas administrativas asociadas con derechos no formalizados y un tercer nivel de unidades espaciales para definir unidades básicas administrativas asociadas con derechos consuetudinarios. EJEMPLO 4 Un nivel con unidades espaciales basadas en puntos (4.1.15), un segundo nivel con unidades espaciales basadas en líneas y un tercer nivel con unidades espaciales basadas en polígonos. 4.1.12 unidad espacial liminar: Unidad espacial (4.1.23) en el umbral entre las representaciones 2D y 3D. 4.1.13 interesado: Persona u organización que juega un papel en una transacción de derechos (4.1.20). NOTA 1 Para ser registrado como interesado, no es necesario que todos los miembros sean identificados y registrados individualmente. NOTA 2 Una unidad básica administrativa (4.1.2) puede ser un interesado porque puede poseer un derecho, por ejemplo, de servidumbre.

8

EJEMPLO Una organización que puede ser: una compañía, un municipio, un estado, una tribu, una cooperativa agrícola o una comunidad religiosa (con cada organización representada por un delegado: un director, jefe, empresario, etc.). 4.1.14 miembro interesado: Interesado (4.1.13) registrado e identificado como constituyente de un grupo de interesados (4.1.8). 4.1.15 punto: Primitiva geométrica de dimensión 0 que representa una posición. [ISO 19107:2003, 4.61] NOTA 1 Un punto se puede usar para definir una o más caras lindero (4.1.4) o cadenas de caras lindero (4.1.5). NOTA 2 Los puntos se pueden observar, por ejemplo, por medio de levantamientos terrestres, pero también por fotointerpretación, interpretación de imágenes o identificación en mapas existentes. 4.1.16 perfil: Conjunto de una o más normas base, o subconjunto de normas base y, cuando sea aplicable, identificación de apartados, clases, opciones y parámetros seleccionados de esas normas base que son necesarios para cumplir una determinada función. [ISO 19106:2004, 4.5] NOTA 1 Un perfil válido para todo un país se denomina perfil nacional (véase el anexo D). NOTA 2 Un perfil procede de normas base, de modo que, por definición, la conformidad con un perfil implica la conformidad con las normas base de las que deriva (véase el anexo A). 4.1.17 relación necesaria: Asociación explícita entre unidades espaciales (4.1.23), o bien entre unidades básicas administrativas (4.1.2). NOTA 1 Debido a aspectos jurídicos, a la historia de los datos, a geometrías inexactas o inexistentes, las técnicas de superposición geoespacial pueden generar relaciones inválidas, o falta de relaciones, que pueden ser introducidas mediante las relaciones necesarias. NOTA 2 Las relaciones de las unidades espaciales se pueden definir con los tipos de la Norma ISO 19125-2. 4.1.18 responsabilidad: Obligación formal o no formalizada de hacer algo. EJEMPLO La responsabilidad de limpiar una acequia, de mantener la acera sin nieve o de eliminar los carámbanos de los tejados durante el invierno, o de mantener un monumento. 4.1.19 restricción: Obligación formal o no formalizada de abstenerse de hacer algo. EJEMPLO 1 No está permitido construir a menos de 200 metros de una gasolinera; o, una servidumbre o hipoteca es una restricción sobre el derecho (4.1.20) de propiedad.

9

EJEMPLO 2 Se puede registrar el embargo de una BAUNIT como una restricción. 4.1.20 derecho: Acción, actividad o clase de acciones que un participante en el sistema puede realizar directamente o usando un recurso asociado. [ISO 19132:2007, 4.38] NOTA 1 Un derecho puede proporcionar un título formal o no formalizado de posesión o de hacer algo. NOTA 2 Esta norma internacional se ocupa de derechos reales y personales. Los derechos reales son derechos sobre o con respecto a unidades espaciales (4.1.23) (por ejemplo, propiedad o usufructo). Los derechos personales son derechos que tienen los interesados(4.1.13) (por ejemplo, derecho de pesca, derecho de pastoreo o derecho de uso). NOTA 3 Los derechos se pueden solapar o pueden estar en desacuerdo. EJEMPLO Derecho de propiedad, derecho sobre una multipropiedad, derecho de alquiler, posesiones, derecho consuetudinario, derecho islámico (por ejemplo, miri o milk), derecho de los indígenas o derecho no formalizado. 4.1.21 fuente: Documento que proporciona hechos jurídicos o administrativos en los que se basa el objeto de administración del territorio (Land Administration – LA) (derecho (4.1.20), restricción (4.1.19), responsabilidad (4.1.18), unidad básica administrativa (4.1.2), interesado (4.1.13) o unidad espacial (4.1.23)). NOTA Se puede añadir cualquier tipo de documento como fuente, de acuerdo con la Norma ISO 19115:2003, apartado B.3.2. 4.1.22 fuente espacial: Fuente (4.1.21) con la representación espacial de una (o una parte) o de más unidades espaciales (4.1.23). EJEMPLO Un croquis de un levantamiento topográfico, una ortofotografía o una imagen de satélite con evidencia de la localización de los límites (capturado en campo). 4.1.23 unidad espacial: Un área (o múltiples áreas) de terreno (4.1.9) o agua, o un volumen (o múltiples volúmenes) de espacio. NOTA 1 Un área es la norma y múltiples áreas son la excepción. NOTA 2 Las unidades espaciales se estructuran de manera que permiten la creación y gestión de unidades básicas administrativas (4.1.2). NOTA 3 Esta norma internacional permite la representación bidimensional (2D), tridimensional (3D) o mixta (2D y 3D) de unidades espaciales, que se pueden describir textualmente (“desde este árbol hasta el río”), a partir de un único punto (4.1.15), o a partir de un conjunto de líneas sin estructura, o como una superficie, o como un volumen 3D.

10

NOTA 4 Además de representar las unidades espaciales como un único punto, textualmente, o mediante un conjunto de líneas sin estructura, la unidad espacial puede tener un área igual a cero por razones administrativas. 4.1.24 agrupación de unidades espaciales: Cualquier número de unidades espaciales (4.1.23), consideradas como una entidad. NOTA Las unidades espaciales de una agrupación de unidades espaciales no tienen por qué ser continuas necesariamente. EJEMPLO Unidades espaciales que juntas forman un área administrativa como una sección, un cantón, un municipio, un departamento, una provincia o un país. Unidades espaciales dentro de un área de planeamiento. 4.1.25 red de servicios: Red que describe el espacio jurídico de la topología de un servicio. NOTA 1 Una red de servicios puede contener atributos con información sobre su espacio jurídico, registrado o no formalizado. NOTA 2 Una red de servicios también se puede modelar como una unidad básica administrativa (4.1.2). EJEMPLO El espacio jurídico necesario para acceder y reparar un cable o una red de tuberías. 4.2 Abreviaturas baunit unidad básica administrativa (basic administrative unit) FIG Federación Internacional de Geómetras (International Federation of Surveyors) SIG Sistemas de Información Geográfica (Geographical Information System – GIS) GNSS Sistema de Navegación Global por Satélite (Global Navigation Satellite System) INSPIRE Infraestructura de Información Geográfica en Europa (Insfrastructure for Spatial

Information in Europe) LA Administración del Territorio (Land Administration) LADM Modelo para el Ámbito de la Administración del Territorio (Land Administration

Domain Model) RRR Derecho, Restricción, Responsabilidad (Right, Restriction, Responsability) STDM Modelo para el Ámbito de la Tenencia Social (Social Tenure Domain Model) UML Lenguaje de Modelado Unificado (Unified Modelling Language)

5. Visión General del LADM

5.1 Paquetes y subpaquetes del LADM

El LADM, como producto, es un esquema conceptual. El LADM se organiza en tres paquetes y un subpaquete. Un (sub)paquete es una agrupación de clases con cierto grado de cohesión. Cada (sub)paquete tiene su propio espacio de nombres. Los (sub)paquetes facilitan el mantenimiento de los diferentes conjuntos de datos por diferentes organizaciones. Por lo tanto, el modelo completo puede implementarse a través de un conjunto distribuido de sistemas de (geo-) información, cada uno de los

11

cuales asume las actividades de mantenimiento de los datos y la provisión de los elementos del modelo. El modelo puede también implementarse por una o más organizaciones de mantenimiento, operando a nivel nacional, regional o local. Aquí reside la importancia del modelo: diferentes organizaciones tienen sus propias responsabilidades en el mantenimiento y suministro de los datos, pero se pueden comunicar sobre la base de procesos administrativos normalizados y técnicos de actualización.

En la figura 1 se presenta una visión general de los (sub)paquetes (con sus respectivas clases). Los tres paquetes son: (1) Party Package (Paquete de Interesados, véase el apartado 5.3), (2) Administrative Package (Paquete Administrativo, véase el apartado 5.4) y (3) Spatial Unit Package (Paquete de las Unidades Espaciales, véase el apartado 5.5). El subpaquete de Topografía y Representación (Surveying and Representation Subpackage, véase el apartado 5.6) es un subpaquete del Paquete de las Unidades Espaciales.

Todas las figuras son diagramas UML 2.1. Las clases del LADM llevan el prefijo LA_ para diferenciarlas de otras clases de la serie de normas ISO de información geográfica.

<< Copiar la figura 1 de la norma original, al ser un diagrama UML no se traduce>>

Figura 1 – Visión general de (sub)paquetes del LADM (con sus respectivas clases)

5.2 Clases básicas del LADM

El núcleo del LADM se basa en 4 clases básicas:

1) Clase LA_Party. Las instancias de esta clase son interesados. 2) Clase LA_RRR. Las instancias de las subclases de LA_RRR son derechos, restricciones o

responsabilidades. 3) Clase LA_BAUnit. Las instancias de esta clase son unidades básicas administrativas. 4) Clase LA_SpatialUnit. Las instancias de esta clase son unidades espaciales.

La figura 2 muestra las clases básicas del LADM. Los detalles de estas 4 clases básicas y todas las otras clases del LADM se presentan en el capítulo 6.

<< Copiar la figura 2 de la norma original >>

Figura 2 – Clases básicas del LADM

5.3 Paquete de Interesados (Party Package)

La clase principal del Paquete de Interesados es la clase básica LA_Party (con interesados como instancias). LA_Party tiene una especialización: LA_GroupParty (con agrupaciones de interesados como instancias). Hay una clase asociación opcional entre LA_Party y LA_GroupParty: LA_PartyMember (con miembros interesados como instancias). Véase la figura 3.


Figura 3 – Clases del Paquete de Interesados

Un grupo de interesados, al ser una especialización de los interesados, es también un interesado. Esto significa que la relación de agregación de la figura 3 entre LA_Party y LA_Grouparty crea agrupaciones de interesados con interesados (registrados) como componentes. Cada interesado, siendo un

12

componente de un grupo de interesados, puede entonces ser registrado como un miembro interesado de la clase LA_PartyMember.

5.4 Paquete Administrativo (Administrative Package)

Las clases principales del Paquete Administrativo son las clases básicas LA_RRR y LA_BAUnit. Véase la figura 4.

LA_RRR es una clase abstracta que tiene tres clases de especialización:

1) LA_Right, con derechos como instancias. Los derechos están principalmente en el ámbito del derecho privado o el derecho consuetudinario. Los derechos de propiedad generalmente se basan en legislación (nacional) y las listas de códigos del LADM lo respaldan, véase el anexo J.

2) LA_Restriction, con restricciones como instancias. Las restricciones normalmente “van con la tierra”, lo que significa que siguen vigentes, incluso cuando el derecho de la tierra se transfiere después de creado (y registrado) el derecho. Una hipoteca, una instancia de la clase LA_Mortgage, es una restricción especial del derecho de propiedad. Esto concierne al traspaso de la propiedad de un deudor a un prestamista, como seguridad para el préstamo financiero, con la condición de que la propiedad se devuelva cuando el préstamo se pague.

3) LA_Responsability, con responsabilidades como instancias.

Las instancias de la clase LA_BAUnit son unidades básicas administrativas (abreviadas como baunits). Las baunits se necesitan, entre otras cosas, para registrar “unidades de propiedad básicas” que se componen de varias unidades espaciales, pertenecientes a un interesado, con el mismo derecho (un derecho debe ser “homogéneo” en toda la baunit). Los RRR deben ser únicos para cada baunit con el objetivo de establecer una combinación única entre una instancia de la clase LA_Party, una instancia de la subclase LA_RRR y una instancia de la clase LA_BAUnit.


Figura 4 – Clases del Paquete Administrativo

En principio, todos los derechos, restricciones y responsabilidades se basan en una fuente administrativa, como instancias de la clase LA_AdministrativeSource.

La clase LA_RequiredRelationshipBAUnit permite crear instancias de relaciones entre baunits. Las relaciones pueden ser de naturaleza jurídica, temporal o espacial.

5.5 Paquete de Unidades Espaciales (Spatial Unit Package)

5.5.1 La clase principal del Paquete de Unidades Espaciales es la clase básica LA_SpatialUnit, con unidades espaciales como instacias. LA_Parcel es un alias para LA_SpatialUnit, véase la figura 5.


Figura 5 – Clases del Paquete de Unidades Espaciales

5.5.2 Las unidades espaciales se pueden agrupar de dos formas:

13

1) como agrupaciones de unidades espaciales, instancias de la clase LA_SpatialUnitGroup. Las agrupaciones de unidades espaciales se pueden además agrupar en agrupaciones de unidades espaciales mayores. Esto se hace efectivo mediante una relación de agregación de la clase LA_SpatialUnitGroup consigo misma, véase la figura 5. Un ejemplo de una agrupación de unidades espaciales son los municipios. Una agrupación de unidades espaciales puede ser una agrupación de otras agrupaciones de unidades espaciales. En las implementaciones del LADM, esto se hace para permitir la inclusión de identificadores de unidades espaciales en zonas jerárquicas.

2) como sub unidades espaciales o subparcelas, esto es una agrupación de unidades espaciales en sus partes. Esto se hace efectivo mediante una relación de agregación de la clase LA_SpatialUnit consigo misma, véase la figura 5. Las partes, a su vez, se pueden agrupar en subpartes (sub subparcelas) y así consecutivamente.

5.5.3 Las unidades espaciales están refinadas en dos especializaciones:

1) Unidades de edificación, como instancias de la clase LA_LegalSpaceBuildingUnit. Una unidad espacial concierne al espacio jurídico, que no tiene que coincidir necesariamente con el espacio físico de un edificio.

2) Redes de servicios, como instancias de la clase LA_LegalSpaceUtilityNetwork. Una red de servicios concierne al espacio jurídico, que no tiene que coincidir necesariamente con el espacio físico de una red de servicios.

5.5.4 Una instancia de LA_Level es un nivel.

5.5.5 Las relaciones necesarias son relaciones espaciales explícitas entre unidades espaciales, que son instancias de la clase LA_RequieredRelationSpatialUnit. A veces se necesitan estas relaciones espaciales explícitas, cuando la geometría de las unidades espaciales no es suficientemente exacta para dar resultados fiables o cuando se aplican técnicas de solape (por ejemplo, un edificio, que está en realidad dentro de una parcela, se notifica que cae fuera; lo mismo aplica a la geometría de un derecho, por ejemplo, a una servidumbre). Las relaciones necesarias se anteponen a las relaciones implícitas, establecidas a través de técnicas de solape.

5.6 Subpaquete de Topografía y Representación (Surveying and Representation Subpackage)

Las cuatro clases del Subpaquete de Topografía y Representación son (1) LA_Point, (2) LA_SpatialSource, (3) LA_BoundaryFaceString y (4) LA_BoundaryFace, véase la figura 6.


Figura 6 – Clases del Subpaquete de Topografía y Representación

Los puntos, instancias de LA_Point, las líneas y las superficies se pueden obtener en campo (mediante levantamientos clásicos o mediante GPS), en una oficina, o compilarse a partir de varias fuentes, por ejemplo, mediante formularios, croquis de campo, ortoimágenes u ortofotos. La adquisición de puntos, líneas o superficies (un levantamiento) puede conllevar la identificación de las unidades espaciales en una fotografía, en una imagen o en un mapa topográfico; los cicloramas y los métodos pictométricos (múltiples imágenes tomadas desde diferentes ángulos) también se pueden usar para este propósito.

14

Un levantamiento se documenta con fuentes espaciales, instancias de la clase LA_SpatialSource. Éstos pueden ser los documentos finales (a veces formales) o todos los documentos del levantamiento. A veces, varios documentos son el resultado de un único levantamiento. Una fuente espacial puede ser oficial o no (es decir, un plan de un levantamiento registrado o una fotografía aérea). Los documentos en papel (que pueden ser escaneados) pueden considerarse como una parte integral del sistema de administración del territorio.

Los puntos individuales son instancias de la clase LA_Point, que está asociada a la clase LA_SpatialSource. Como no es necesario que se represente la unidad espacial completa, una fuente espacial puede asociarse con varios puntos. Los puntos de control geodésicos, incluyendo múltiples conjuntos de coordenadas de puntos y con múltiples sistemas de referencia, están todos soportados en el LADM.

Las representaciones 2D y 3D de unidades espaciales utilizan cadenas de caras lindero como instancias de la clase LA_BoundaryFaceString, y caras lindero como instancias de la clase LA_BoundaryFace.

Las coordenadas en sí mismas vienen de los puntos o se capturan como geometrías lineales.

El LADM soporta el uso creciente de representaciones 3D de las unidades espaciales, sin suponer una carga adicional en las representaciones 2D existentes. Otra característica de la representación espacial dentro del LADM es que no hay discordancia entre las unidades espaciales que se representan en 2D y las unidades espaciales que se representan en 3D. Véase el anexo B para más detalles. El LADM está basado en esquemas espaciales aceptados y disponibles, tal como el publicado en la Norma ISO 19107:2003.

6 Contenidos de las clases del LADM y sus asociaciones

6.1 Introducción

Todas las clases del LADM siguen la clase estereotipo featureType de la Especificación Técnica ISO/TS 19103 (un tipo de fenómeno (featureType) es una clase de fenómeno, es decir, abstracciones de entes del mundo real que tienen propiedades comunes). Muchas clases del LADM son subclases de la clase VersionedObject (véase el apartado 6.2.1).

El LADM presupone clases estereotipadas, con un número mínimo de atributos, para dirigir la situación donde las clases del LADM se refieren a fuentes externas para interesados, direcciones, impuestos, usos del suelo, coberturas de suelo, valoraciones, unidades de edificación, redes de servicios o archivos. Véase el anexo K.

El LADM permite añadir elementos definidos por el usuario. Es probable que atributos, operadores, asociaciones, o quizás nuevas clases adicionales, sean necesarias para una región o país específico. Es posible que no se usen partes del LADM. Además, los perfiles nacionales se pueden usar para personalizar el LADM para cumplir unas necesidades específicas. Véase el anexo D.

6.2 Clases especiales

6.2.1 VersionedObject (Objeto versionado)

La clase VersionedObject se introduce en el LADM para gestionar y mantener datos históricos en la base de datos. El historial requiere que los datos insertados o sustituidos tengan una fecha estampada. De

15

esta manera la base de datos se puede restaurar tal y como estaba en cualquier momento previo. Para más detalles del historial y los aspectos dinámicos de los sistemas de administración del territorio, véase el anexo N.

Las clases LA_Party, LA_PartyMember, LA_RRR, LA_BAUnit, LA_SpatialUnit, LA_SpatialUnitGroup, LA_RequiredRelationshipSpatialUnit, LA_RequiredRelationshipBAUnit, LA_Level, LA_BoundaryFaceString, LA_BoundaryFace y LA_Point, son todas subclases de la clase VersionedObject, véase la figura 7.

Las clases LA_GroupParty, LA_Right, LA_Restriction, LA_Responsability, LA_Mortgage (por medio de LA_Restriction), LA_LegalSpaceUtilityNetwork y LA_LegalSpaceBuildingUnit heredan de VersionedObject a través de las clases de arriba.


Figura 7 – Clases VersionedObject (con subclases), Fraction y Oid

Los atributos de VersionedObject son:

- beginLifespanVersion: Tiempo de inicio de una versión específica de la instancia;

Tipo de valor: DateTime, basado en la Norma ISO 19108

Multiplicidad: 1

- endLifespanVersion: Tiempo de finalización de una versión específica de la instancia;


Multiplicidad: 0..1

- quality: Calidad de una versión específica de la instancia;

Tipo de valor: DQ_Element (tipo de la Norma ISO 19115)

Multiplicidad: 0..*

- source: Organización responsable de una versión específica de la instancia;

Tipo de valor: CI_ResponsibleParty (tipo de la Norma ISO 19115)

Multiplicidad: 0..*

6.2.2 Fraction (Fracción)

El tipo de dato genérico Fraction se introduce en el LADM para permitir el uso de fracciones, por ejemplo, ½ o ¾. Una fracción se escribe como una pareja de números, el número de la parte superior se llama numerador y el número de la parte inferior denominador. Una línea suele separar el numerador del denominador, véase la figura 7.

Los atributos de Fraction son:

- denominator: El número de la parte inferior de la fracción;

16

Tipo de valor: int

Multiplicidad: 1

- numerator: El número de la parte superior de la fracción;

Tipo de valor: int

Multiplicidad: 1

El tipo de valor del denominador debe ser un entero positivo > 0.

El tipo de valor del numerador debe ser un entero positivo > 0 y debe ser menor que el valor del denominador.

6.2.3 Oid (Identificadores)

El tipo de dato genérico Oid se introduce en el LADM para permitir el uso de los identificadores de objetos, véase la figura 7.

Los atributos de Oid son:

- localId: Identificador local, asignado por el proveedor de los datos;

Tipo de valor: CharacterString

Multiplicidad: 1

- namespace: Identificador de la fuente de datos del objeto espacial;


Multiplicidad: 1

El identificador local debería ser único dentro del espacio de nombres, es decir, ningún otro objeto espacial debería llevar el mismo identificador.

NOTA Los perfiles nacionales pueden limitar el conjunto de caracteres para asegurar el cumplimiento de las normas locales (por ejemplo, {“A”...”Z”, ”a”...”z”, ”0”...”9”, ”_”, ”.”, ”,”, ”-“}, es decir, solo se permiten letras del alfabeto latino, números, guiones bajos, puntos, comas y guiones).

6.2.4 LA_Source (Fuentes)

En el LADM se modelan las fuentes administrativas y espaciales a partir de la clase abstracta LA_Source. La clase LA_Source tiene dos subclases: (1) LA_AdministrativeSource (fuente administrativa, véase el apartado 6.4.7) y (2) LA-SpatialSource (fuente espacial, véase el apartado 6.6.2), véase la figura 8.


Figura 8 – Clases LA_Source (con subclases)

Los atributos de la clase LA_Source son:

17

- acceptance: La fecha de vigencia de la ley de la fuente por una autoridad;


Multiplicidad: 0..1

- availabilityStatus: El Estado de disponibilidad de la fuente;

Tipo de valor: LA_AvailabilityStatusType

Multiplicidad: 1

- extArchiveID: El identificador de la fuente en un registro externo;

Tipo de valor: ExtArchive

Multiplicidad: 0..1

- lifeSpanStamp: El momento en que el evento, representado por la instancia de la clase LA_Source, es procesado por última vez por el sistema LA (es el momento endLifespanVersion para las instancias antiguas, y el momento beginLifespanVersion para las instancias nuevas);


Multiplicidad: 0..1

- maintype: El tipo de documento;

Tipo de valor: CI_PresentationFormCode

Multiplicidad: 0..1

- quality: La calidad de la fuente;

Tipo de valor: DQ_Element de la Norma ISO 19115

Multiplicidad: 0..*

- recordation: La fecha de registro (grabación) de la fuente por la autoridad registradora;


Multiplicidad: 0..1

- sID: El identificador de la fuente;

Tipo de valor: Oid

Multiplicidad: 1

- source: El responsable de la fuente;

18

Tipo de valor: CI_ResponsableParty

Multiplicidad: 0..*

- submission: La fecha de presentación de la fuente por un interesado;


Multiplicidad: 0..1

NOTA 1 El hecho de que todos los diferentes derechos (jurídicos públicos y privados) se basen en algún tipo de documento de transacción se representa mediante la asociación entre LA_RRR y LA_AdministrativeSource. El responsable de redactar el documento está conectado con lo mencionado anteriormente como “registrador1”, “notario” o “redactor” (véase la figura 10).

NOTA 2 En algunos sistemas de administración del territorio se requieren las fuentes para llevar a cabo las transacciones, pero estas luego no se archivan. Por lo tanto, el registro en sí mismo sirve como tal evidencia.

6.3 Clases del Paquete de Interesados (Party Package)

6.3.1. LA_Party (Interesados)

Las instancias de la clase LA_Party son los interesados. Un interesado está asociado con cero o más [0..*] instancias de una subclase de LA_RRR. La clase LA_Party también está asociada con la clase LA_BAUnit, para satisfacer el hecho de que una unidad básica administrativa pueda ser un interesado (por ejemplo una unidad básica administrativa que tiene una servidumbre en otra unidad básica administrativa). Un interesado puede estar asociado con cero o más [0..*] fuentes administrativas (es decir, el autor del documento de transferencia se define como un interesado que juega el papel de registrador de una fuente). Un interesado puede estar asociado con cero o más [0..*] fuentes espaciales (es decir, el autor de un levantamiento topográfico se define como un interesado que juega el papel de topógrafo de una fuente); véase la figura 9.


Figura 9 – Contenido del Paquete de Interesados y asociaciones con otras clases básicas

Los atributos de la clase LA_Party son:

- extPID: El identificador de la fuente en un registro externo;

Tipo de valor: Oid

Multiplicidad: 0..1

- name: El nombre del interesado;


1 Nota nacional El “Conveyancer” es una figura equivalente al notario o registrador que sólo existe en la Commonwealth.

19

Multiplicidad: 0..1

- pID: El identificador del interesado;

Tipo de valor: Oid

Multiplicidad: 1

- role: El rol del interesado en el proceso de actualización y mantenimiento de los datos;

Tipo de valor: LA_PartyRoleType

Multiplicidad: 0..*

- type: El tipo de interesado;

Tipo de valor: LA_PartyType

Multiplicidad: 1

NOTA Si el “rol” tiene un valor específico (por ejemplo, registrador), entonces es posible que no se asocien al interesado subclases de LA_RRR, por lo tanto la multiplicidad [0..*] será 0, por ejemplo, lo que indica que ese registrador no está involucrado en ninguna subclase de LA_RRR.

EJEMPLO Los interesados se muestran en diagramas de instancias, véanse en el anexo C, las figuras C.3, C.4, C.13 y C.31.

6.3.2 LA_GroupParty (Agrupaciones de interesados)

Las instancias de la clase LA_GroupParty son las agrupaciones de interesados. La clase LA_GroupParty es una subclase de la clase LA_Party, esto permite a las instancias de la clase LA_GroupParty tener una asociación con instancias de la clase LA_RRR (y de este modo, también con la clase LA_BAUnit). Un grupo de interesados se compone de dos o más [2..*] interesados, pero también de otras agrupaciones de interesados (es decir, un grupo de interesados de agrupaciones de interesados). En cambio, un interesado es un miembro de cero o más [0..*] agrupaciones de interesados, véase la figura 9.

Los atributos de la clase LA_GroupParty son:

- groupID: El identificador de la agrupación de interesados;

Tipo de valor: Oid

Multiplicidad: 1

- type: El rol tipo de agrupación de interesados;

Tipo de valor: LA_GroupPartyType

Multiplicidad: 1

20

La clase LA_GroupParty tiene la constricción de que la suma de las participaciones de los miembros de la agrupación de interesados debe ser igual a 1. Esta constricción solo es forzosa si existe la clase LA_PartyMember (véase el apartado 6.3.3).

EJEMPLO Las agrupaciones de interesados se muestran en diagramas de instancias, véanse en el anexo C, las figuras C.3, C.4, C.5 y C.26.

6.3.3 LA_PartyMember (Miembros interesados)

Las instancias de la clase LA_PartyMember son los miembros interesados. La Clase LA_PartyMember es una clase asociación opcional entre LA_Party y LA_GroupParty, véase la figura 9.

El atributo de la clase LA_PartyMember es:

- share: La fracción del conjunto;

Tipo de valor: Franction

Multiplicidad: 0..1

6.3.4 Listas de códigos del Paquete de Interesados

El Paquete de Interesados tiene tres listas de códigos (véase la figura 9). Véase el anexo J con ejemplos de los valores de estos códigos.

- LA_PartyRoleType: La lista de códigos LA_PartyRoleType incluye todos los roles diferentes, como topógrafo o notario, que los interesados pueden jugar al actualizar o mantener la administración del territorio en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_PartyRoleType es necesaria solo si se implementa el atributo role de la clase LA_Party. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_GroupPartyType: La lista de códigos LA_GroupPartyType incluye todos los tipos de agrupaciones de interesados diferentes, tales como una asociación o una familia, reconocidos/permitidos en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_GroupPartyType es necesaria para implementar la clase LA_GroupParty. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_PartyType: La lista de códigos LA_PartyType incluyen todos los tipos de interesados diferentes, tales como persona física y jurídica, reconocidos/permitidos en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_PartyType es necesaria para implementar la clase LA_Party. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

6.4 Clases del Paquete Administrativo (Administrative Package)

6.4.1 LA_BAUnit (Unidades básicas administrativas)

Las instancias de la clase LA_BAUnit son las unidades básicas administrativas. La clase LA_BAUnit se asocia con la clase LA_Party (un interesado puede ser una unidad básica administrativa). Una unidad básica administrativa está asociada con cero o más [0..*] unidades espaciales. Una unidad básica administrativa debe estar asociada a una o más [1..*] instancias de derecho, restricción o

21

responsabilidad (es decir, una unidad básica administrativa no puede existir si no tiene asociado al menos un derecho, restricción o responsabilidad). Una unidad básica administrativa se puede relacionar espacialmente, a través de una relación necesaria, con cero o más [0..*] unidades básicas administrativas diferentes (es decir, se pueden crear relaciones espaciales explícitas entre dos unidades básicas administrativas cuando no hay geometría o ésta es inexacta para proporcionar resultados fiables implícitos). Las unidades básicas administrativas no necesitan estar relacionadas explícitamente. Sin embargo, si se especifica una relación necesaria de manera explícita, una unidad básica administrativa debe estar asociada a una o más [1..*] unidades básicas administrativas diferentes. Una unidad básica administrativa puede estar asociada a cero o más [0..*] fuentes administrativas (es decir, normalmente se describe a la unidad básica administrativa como el objeto afectado por el derecho, restricción o responsabilidad en la fuente administrativa). Una unidad básica administrativa puede estar asociada a cero o más [0..*] fuentes espaciales (es decir, la extensión – o parte- de una unidad básica administrativa se puede describir en una fuente espacial). Véase la figura 10.

Los atributos de la clase LA_BAUnit son:

- name: El nombre de la unidad básica administrativa;


Multiplicidad: 0..1

- type: El tipo de unidad básica administrativa;

Tipo de valor: LA_BAUnitType

Multiplicidad: 1

- uID: El identificador de la unidad básica administrativa;

Tipo de valor: Oid

Multiplicidad: 1

La clase LA_BAUnit tiene la constricción de que la suma de las participaciones de una unidad básica administrativa, debe ser igual a 1 para la misma subclase de la clase LA_RRR, a menos que la “participación” no tenga sentido en lo que respecta al tipo de derecho, restricción o responsabilidad. La constricción se debería aplicar sólo a instancias válidas en el mismo momento de tiempo (life span).

La clase LA_BAUnit tiene una constricción que requiere que no se permita el solape entre timeSpecs para el mismo tipo de RRR y la misma unidad básica administrativa.

NOTA 1 La clase LA_BAUnit permite la asociación de un derecho a una combinación de unidades espaciales (por ejemplo, un apartamento y una plaza de aparcamiento).

NOTA 2 Es posible que no exista una unidad espacial para una unidad básica administrativa, esto permite situaciones administrativa especiales (por ejemplo, escrituras sin representación cartográfica).

NOTA 3 Con la clase LA_BAUnit es posible registrar unidades espaciales de diferentes niveles como una unidad. Si se incluyen o eliminan (partes de) unidades espaciales de la baunit, el uID sigue siendo el

22

mismo, con una versión diferente. Con este planteamiento, una hipoteca solo se puede establecer para la baunit completa, no para una o más de las unidades espaciales registradas.

NOTA 4 Una (una agrupación de) baunit puede ser un interesado.

EJEMPLO Las unidades básicas administrativas se muestran en diagramas de instancias, véanse en el anexo C, las figuras C.1, C.17, C.24, C.25, C.26, C.28, C.30, C31, C33, C34 y C.35.


Figura 8 – Contenido del Paquete Administrativo con las asociaciones con otras clases básicas

6.4.2. LA_RRR (Derechos, restricciones y responsabilidades)

La clase LA_RRR es una clase abstracta. Las instancias de una subclase de LA_RRR son un derecho (o relación de tenencia social), una restricción o una responsabilidad. Si es un derecho o una responsabilidad, entonces está asociado directamente con exactamente un [1] interesado y exactamente una [1] unidad básica administrativa. Si es una restricción, entonces está asociada con cero o un [0..1] interesado, y exactamente con una [1] unidad básica administrativa. Lo último permite el registro de las restricciones (por ejemplo, el derecho de paso, el derecho de cosechar frutos) con o sin una asociación con LA_Party. Una instancia de una subclase de LA_RRR debe estar asociada a una o más [1..*] fuentes administrativas (es decir, el derecho, la restricción o la responsabilidad que afectan a una unidad básica administrativa deben estar respaldadas por al menos una fuente administrativa). Véase la figura 10.

Los atributos de la clase LA_RRR son:

- description: Descripción relativa al derecho, restricción o responsabilidad;


Multiplicidad: 0..1

- rID: El identificador del RRR;

Tipo de valor: Oid

Multiplicidad: 1

- share: Participación en la instancia de la subclase de LA_RRR;

Tipo de valor: Fraction

Multiplicidad: 0..1

- shareCheck: Indica cuándo es aplicable la constricción a la clase LA_BAUnit;

Tipo de valor: Boolean

Multiplicidad: 0..1

- timeSpec: Uso operativo de un derecho en tiempo compartido;

23

Tipo de valor: Tipo de la Norma ISO 8601 o ISO 14825

Multiplicidad: 0..1

NOTA El atributo timeSpec es capaz de manejar otras descripciones temporales, tales como patrones recurrentes (cada fin de semana, cada verano, etc.). Esto significa, por ejemplo, que un interesado puede albergar un derecho de uso de un apartamento cada año en marzo, o que un grupo de pastores tiene el derecho de cruzar un terreno cada verano (para especificaciones difusas de rangos de tiempo, véase la Norma ISO 14825:2011, anexo D; se puede usar la Norma ISO 14825:2011 anexo D, en lugar de la Norma ISO 8601:2004).

6.4.3 LA_Right (Derechos)

Las instancias de la clase LA_Right son los derechos. La clase LA_Right es una subclase de la clase LA_RRR. Un derecho se puede asociar con cero o más [0..*] hipotecas (es decir, una hipoteca está asociada con la unidad básica administrativa afectada pero también puede estar asociada específicamente con el derecho el cuál es objeto de la hipoteca); véase la figura 10.

El atributo de la clase LA_Right es:

- type: El tipo de derecho;

Tipo de valor: LA_RightType

Multiplicidad: 1

EJEMPLO Los derechos se muestran en diagramas de instancias, véase el anexo C, las figuras C.1, C.8, C.11, C.30 y C.31.

6.4.4 LA_Restriction (Restricciones)

Las instancias de la clase LA_Restriction son restricciones. La clase LA_Restriction es una subclase de la clase LA_RRR. La clase LA_Mortgage (hipoteca) es una especialización de la clase LA_Restriction (véase el apartado 6.4.6); véase la figura 10.

Los atributos de la clase LA_Restriction son:

- partyRequired: Indica si es necesario un interesado para el registro de una restricción en la asociación con la clase LA_Party;

Tipo de valor: Boolean

Multiplicidad: 0..1

- type: El tipo de restricción;

Tipo de valor: LA_RestrictionType

Multiplicidad: 1

24

NOTA El atributo partyRequired es TRUE (por defecto) si se requiere un interesado para el registro de la restricción, y es FALSE si la restricción se considera como una restricción de la unidad espacial. La restricción de una unidad espacial se hace siempre por medio de una baunit.

EJEMPLO Las restricciones se muestran en diagramas de instancias. Véase el anexo C, las figuras C.9, C16, C.19, C.21, C.22 y C.23.

6.4.5 LA_Responsability (Responsabilidades)

Las instancias de la clase LA_Responsability son las responsabilidades. La clase LA_Responsability es una subclase de la clase LA_RRR. Véase la figura 10.

El atributo de la clase LA_Responsability es:

- type: El tipo de responsabilidad;

Tipo de valor: LA_ResponsabilityType

Multiplicidad: 1

EJEMPLO Las responsabilidades se muestran en diagramas de instancias. Véase el anexo C, figura C.20.

6.4.6 LA_Mortgage (Hipoteca)

Las instancias de la clase LA_Mortage son hipotecas. La clase LA_Mortage es una subclase de la clase LA_Restriction. La clase LA_Mortage está asociada con la clase LA_Right (el derecho es la base de la hipoteca). Una hipoteca puede estar asociada a cero o más [0..*] derechos (es decir, una hipoteca puede estar específicamente asociada al derecho el cual es el objeto de la hipoteca). En todos los casos, la hipoteca está asociada, a través de la clase LA_Restriction y LA_RRR, a la unidad básica administrativa que está afectada por la hipoteca; véase la figura 10.

Los atributos de la clase LA_ Mortage son:

- amount: La cantidad de dinero de la hipoteca;

Tipo de valor: Currency, basado en la Norma ISO 4217

Multiplicidad: 0..1

- interestRate: El tipo de interés de la hipoteca (porcentaje);

Tipo de valor: Float

Multiplicidad: 0..1

- ranking: El orden en la clasificación, si se aplica más de una hipoteca a un derecho (o derechos);

Tipo de valor: Integer

Multiplicidad: 0..1

25

- type: El tipo de hipoteca;

Tipo de valor: LA_MortgageType

Multiplicidad: 0..1

NOTA La norma ISO 4217 debería usarse para la lista de divisas de la Especificación Técnica ISO/TS 19103 sobre medidas.

EJEMPLO Las hipotecas se muestran en diagramas de instancias. Véase el anexo C, figuras C.10, C.11 y C.15.

6.4.7 LA_AdministrativeSource (Fuentes Administrativas)

Las instancias de la clase LA_AdministrativeSource son las fuentes administrativas. La clase LA_AdministrativeSource es una subclase de la clase LA_Source. Una fuente administrativa debe estar asociada a uno o más [1..*] interesados (es decir, como mínimo se debe especificar el interesado que participa como registrador). Una fuente administrativa puede estar asociada con cero o más [0..*] unidades básicas administrativas (es decir, la fuente administrativa puede describir los objetos del derecho, restricción o responsabilidad). Una fuente administrativa puede estar asociada a cero o más [0..*] instancias de las especializaciones de la clase LA_RRR (derechos, restricciones/hipotecas y responsabilidades) (es decir, la fuente administrativa puede describir derechos, restricciones o responsabilidades ostentados por un interesado y que afectan a un unidad básica administrativa), véanse las figuras 8 y 10.

Los atributos de la clase LA_ AdministrativeSource son:

- text: El contenido del documento;

Tipo de valor: MultiMediaType basado en la Norma ISO/IEC 13240

Multiplicidad: 0..1

- type: El tipo de documento;

Tipo de valor: LA_ AdministrativeSourceType

Multiplicidad: 1

NOTA 1 Es necesario disponer del estado de disponibilidad de una fuente administrativa, porque puede perderse, por ejemplo, por un desastre.

NOTA 2 Se puede usar la Norma ISO/IEC 13240 para el contenido del documento.

NOTA 3 Los archivos pueden ser internos o externos a la organización de LA (administración del territorio). Si son internos entonces se puede usar un atributo textual; si son externos entonces se puede usar el atributo extArchiveID de la fuente administrativa.

6.4.8 LA_RequiredRelationshipBAUnit (Relaciones necesarias entre unidades básicas administrativas)

Las instancias de la clase asociación LA_ RequiredRelationshipBAUnit son relaciones necesarias entre unidades básicas administrativas, véase la figura 10. Una relación necesaria entre unidades espaciales

26

puede estar asociada con cero o más [0..*] fuentes espaciales para proporcionar la documentación de apoyo de la relación explícita.

El atributo de la clase LA_ RequiredRelationshipBAUnit es:

- relationship: Descripción de la relación necesaria;


Multiplicidad: 1

NOTA 1 Las instancias de LA_ RequiredRelationshipBAUnit se anteponen a las relaciones implícitas, establecidas a través de técnicas geoespaciales de solape.

NOTA 2 Incluso cuando la geometría de las unidades espaciales es exacta, puede haber razones jurídicas para establecer una relación necesaria entre baunits.

NOTA 3 LA_ RequiredRelationshipBAUnit es una clase de objetos versionados. Usando el atributo “relationship” se pueden añadir diferentes atributos del ciclo de vida además de los propios del objeto versionado.

EJEMPLO Dos versiones históricas de baunits deberían conectarse en el tiempo cuando estén relacionadas con el mismo cambio, por ejemplo, cuando se vende una parte de una unidad espacial.

6.4.9 Listas de códigos del Paquete Administrativo

El Paquete Administrativo tiene siete listas de códigos para las clases. Véase el anexo J con ejemplos de los valores.

- LA_AdministrativeSourceType: La lista de códigos LA_AdministrativeSourceType incluye todos los tipos de fuentes administrativas diferentes, tales como escritura o título, utilizados como documentación de apoyo en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_AdministrativeSourceType es necesaria para implementar la clase LA_AdministrativeSource. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_MortgageType: La lista de códigos LA_MortgageType incluye todos los tipos de hipotecas diferentes, como lineal o microcrédito, utilizados en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_MortgageType es necesaria solo si se implementa el atributo type de la clase LA_Mortgage. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_RightType: La lista de códigos LA_RightType incluye todos los tipos de derechos diferentes, como propiedad, consuetudinario o alquiler, utilizados en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_RightType es necesaria para implementar la clase LA_Right. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_RestrictionType: La lista de códigos LA_RestrictionType incluye todos los tipos de restricciones diferentes, tales como servidumbre, utilizados en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_RestrictionType es necesaria para implementar la clase LA_Restriction. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

27

- LA_ResponsabilityType: La lista de códigos LA_ResponsabilityType incluye todos los tipos de responsabilidades diferentes, tales como el mantenimiento de un canal, utilizados en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_ResponsabilityType es necesaria para implementar la clase LA_Responsability. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_AvailabilityStatusType: La lista de códigos LA_AvailabilityStatusType incluye todos los tipos de estado de disponibilidad diferentes, tales como original, destruido o incompleto, utilizados en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_AvailabilityStatusType es necesaria para implementar la clase LA_AdministrationSource. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_BAUnitType: La lista de códigos LA_BAUnitType incluye todos los tipos de unidades básicas administrativas diferentes, tales como unidad básica de propiedad o unidad de derecho, utilizadas en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_BAUnitType es necesaria para implementar la clase LA_ BAUnit. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

6.5 Clases del Paquete de Unidades Espaciales (Spatial Unit Package)

6.5.1 LA_SpatialUnit (Unidades Espaciales)

Las instancias de la clase LA_SpatialUnit son las unidades espaciales. Una unidad espacial puede estar asociada con cero o más [0..*] unidades básicas administrativas (es decir, la unidad espacial se puede usar para describir la extensión de – parte de – una unidad básica administrativa). Una unidad espacial puede estar asociada con cero o un [0..1] nivel (es decir, una unidad espacial puede estar asociada a un nivel de propiedad). Una unidad espacial no puede estar asociada a más de un nivel. Una unidad espacial puede estar asociada a cero o más [0..*] agrupaciones de unidades espaciales (es decir, una unidad espacial puede estar asociada a una subdivisión y también a un distrito escolar). Una unidad espacial puede estar relacionada espacialmente, a través de una relación necesaria, con una o más [0..*] unidades espaciales diversas (es decir, se crea una relación espacial explícita entre dos unidades espaciales cuando falta la geometría o es inexacta para proporcionar resultados implícitos fiables). Las unidades espaciales no necesitan estar relacionadas explícitamente. Una unidad espacial se puede asociar con cero o más [0..*] fuentes espaciales. Una unidad espacial puede formar parte de 0..1 unidades espaciales diferentes. Una unidad espacial puede incluir 0..* unidades espaciales diferentes. Las unidades espaciales pueden especializarse posteriormente en unidades de edificación (apartado 6.5.3) o en redes de servicios (apartado 6.5.4); véase la figura 11.

Los atributos de la clase LA_SpatialUnit son:

- area: El área de la unidad espacial en 2D;

Tipo de valor: LA_AreaValue

Multiplicidad: 0..*

- dimension: La dimensión de la unidad espacial;

28

Tipo de valor: LA_ DimensionType

Multiplicidad: 0..1

- extAddressID: El enlace a la dirección(es) postal externa de la unidad espacial;

Tipo de valor: Oid

Multiplicidad: 0..*

- label: Descripción textual corta de la unidad espacial;


Multiplicidad: 0..1

- referencePoint: Las coordenadas de un punto dentro de la unidad espacial;

Tipo de valor: GM_Point (tipo de la Norma ISO 19107)

Multiplicidad: 0..1

- suID: El identificador de la unidad espacial;

Tipo de valor: Oid

Multiplicidad: 1

- surfaceRelation: Indica cuándo la unidad espacial está por encima o por debajo de la superficie;

Tipo de valor: LA_SurfaceRelationType

Multiplicidad: 0..1

- volume: El volumen de la unidad espacial en 3D;

Tipo de valor: LA_ VolumeValue

Multiplicidad: 0..*

NOTA El método “createArea( )” construye una primitiva geométrica de tipo GM_MultiSurface basada en la representación espacial asociada (2D). El método “areaClosed( )” comprueba si la representación espacial asociada (2D) está cerrada. El método “computeArea( )” calcula el área de la representación espacial asociada (2D). El método “computeVolume( )” calcula el volumen de la representación espacial asociada (3D). El método “createVolume( )” construye una primitiva geométrica de tipo GM_MultiSolid basada en la representación espacial asociada (3D). El método “volumeClosed( )” comprueba si la representación espacial asociada (3D) está cerrada. Estos métodos definen el significado de la clase a nivel conceptual, y no se heredan de otras clases, ni se definen en otras normas ISO. No todos los métodos tienen sentido en todas las situaciones, por ejemplo, computeVolume( ) en el caso de 2D.

EJEMPLO Las unidades espaciales se muestran en diagramas de instancias, véase el anexo C, figuras C.6, C.7, C.16, C.17, C.22, C.29 y C.33.

29

6.5.2. LA_SpatialUnitGroup (Agrupación de unidades espaciales)

Las instancias de la clase LA_SpatialUnitGroup son agrupaciones de unidades espaciales. Una agrupación de unidades espaciales se forma con una o más [1..*] partes/elementos (que pueden ser unidades espaciales, agrupaciones de unidades espaciales o una combinación de unidades espaciales y agrupaciones de unidades espaciales). Una agrupación de unidades espaciales es parte de cero o una [0..1] agrupación de unidades espaciales mayor, que a su vez puede ser parte de cero o una [0..1] agrupación de unidades espaciales mayor, y así sucesivamente. Véase la figura 11.

Los atributos de la clase LA_SpatialUnitGroup son:

- hierarchyLevel: El nivel de jerarquía de una subdivisión o zonificación administrativa;

Tipo de valor: Integer

Multiplicidad: 1

- label: Descripción textual corta de la agrupación de unidades espaciales;


Multiplicidad: 0..1

- name: El nombre de la agrupación de unidades espaciales;


Multiplicidad: 0..1

- referencePoint: Las coordenadas de un punto dentro de la agrupación de unidades espaciales;


Multiplicidad: 0..1

- sugID: El identificador de la agrupación de unidades espaciales;

Tipo de valor: Oid

Multiplicidad: 1

NOTA El mayor nivel jerárquico en una subdivisión jerárquica (país) es 1; los niveles inferiores se incrementan de 1 en 1.

6.5.3 LA_LegalSpaceBuildingUnit (Espacio jurídico de la unidad de edificación)

Las instancias de la clase LA_LegalSpaceBuildingUnit son las unidades de edificación. La clase LA_LegalSpaceBuildingUnit es una subclase de la clase LA_BuildingUnit, véase la figura 11.

Los atributos de la clase LA_LegalSpaceBuildingUnit son:

- extPhysicalBuildingUnitID: El identificador de la unidad de edificación;

30

Tipo de valor: extPhysicalBuildingUnit

Multiplicidad: 0..1

- type: El tipo de unidad de edificación;

Tipo de valor: LA_BuildingUnitType

Multiplicidad: 0..1

NOTA El atributo extPhysicalBuildingUnitID es opcional, ya que en la mayoría de los casos, el atributo suID heredado de la clase LA_SpatialUnit es suficiente para identificar las instancias de la clase LA_LegalSpaceBuildingUnit de manera única.

EJEMPLO Las unidades de especificación se muestran en diagramas de instancias, véase el anexo C, figuras C.6, C.23, C.25, C.28, C.29, C.34 y C.35.


Figura 11 – Contenido del Paquete de Unidades Espaciales con las asociaciones con otras clases básicas

6.5.4. LA_LegalSpaceUnitilityNetwork (Espacio jurídico de las redes de servicios)

Las instancias de la clase LA_LegalSpaceUnitilityNetwork son las redes de servicios. La clase LA_LegalSpaceUnitilityNetwork es una subclase de la clase LA_SpatialUnit, véase la figura 11.

Los atributos de la clase LA_LegalSpaceUnitilityNetwork son:

- extPhysicalUtilityNetworkID: Una referencia a la descripción física (técnica) de la red de servicios;

Tipo de valor: Oid

Multiplicidad: 0..1

- status: El estado de la red de servicios;

Tipo de valor: LA_UtilityNetworkStatusType

Multiplicidad: 0..1

- type: El tipo de red de servicios;

Tipo de valor: LA_UtilityNetworkType

Multiplicidad: 0..1

EJEMPLO: Las redes de servicios se muestran en diagramas de instancias, véase el anexo C, figura C.15.

6.5.5 LA_Level (Niveles)

Las instancias de la clase LA_Level son los niveles. La clase LA_Level está asociada a la clase LA_SpatialUnit, véase la figura 11.

31

Los atributos de la clase LA_Level son:

- IID: El identificador del nivel;

Tipo de valor: Oid

Multiplicidad: 1

- name: El nombre del nivel;


Multiplicidad: 0..1

- registerType: El tipo de registro del contenido del nivel;

Tipo de valor: LA_RegisterType

Multiplicidad: 0..1

- structure: La estructura de la geometría del nivel;

Tipo de valor: LA_StructureType

Multiplicidad: 0..1

- type: El tipo de contenido del nivel;

Tipo de valor: LA_LevelContentType

Multiplicidad: 0..1

EJEMPLO Los niveles se muestran en diagramas de instancias, véase el anexo C, figuras C.2, C.14, C.16, C.21, C.23, C.24, C.25 y C.32.

6.5.6 LA_RequiredRelationshipSpatialUnit (Relación necesaria entre unidades espaciales)

Las instancias de la clase asociación LA_RequiredRelationshipSpatialUnit son relaciones necesarias entre unidades espaciales, véanse las figuras 11 y 12. Una relación necesaria entre unidades espaciales puede estar asociada con cero o más [0..*] fuentes espaciales para proporcionar documentación de apoyo de la relación explícita.

El atributo de la clase LA_RequiredRelationshipSpatialUnit es:

- relationship: La descripción de la relación necesaria;

Tipo de valor: Tipo de dato espacial de la Norma ISO 19125-2

Multiplicidad: 1

6.5.7 Tipos de datos para el Paquete de Unidades Espaciales

El Paquete de Unidades Espaciales tiene dos tipos de datos: LA_AreaValue y LA_VolumeValue. El tipo de datos genérico LA_AreaValue se introduce en el LADM para permitir el registro de los diversos tipos de

32

valores de área (véase el anexo J). El tipo de datos genérico LA_VolumeValue se introduce en el LADM para permitir el registro de los diversos tipos de valores de volumen (véase el anexo J).

Los atributos de LA_AreaValue son:

- areaSize: Área de la unidad espacial 2D;

Tipo de valor: Area

Multiplicidad: 1

- type: Indica el tipo de área proporcionada;

Tipo de valor: LA_AreaType

Multiplicidad: 1

Los atributos de LA_VolumeValue son:

- volumeSize: Volumen de la unidad espacial 3D;

Tipo de valor: Volume

Multiplicidad: 1

- type: Indica el tipo de volumen proporcionado;

Tipo de valor: LA_VolumeType

Multiplicidad: 1

6.5.8 Listas de códigos del Paquete de Unidades Espaciales

El Paquete de Unidades Espaciales tiene diez listas de códigos (véase la figura 11). Véase el anexo J para disponer de ejemplos de los valores.

- LA_BuildingUnitType: La lista de códigos LA_BuildingUnitType incluye todos los tipos de unidades de edificación diferentes, tales como privada o comercial, utilizados en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_BuildingUnitType solo es necesaria si se implementa el atributo type de la clase LA_LegalSpaceBuildingUnit. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_AreaType: La lista de códigos LA_AreaType incluye todos los tipos de área diferentes, tales como oficial o calculada, utilizados en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_AreaType es necesaria para implementar el tipo de dato de LA_AreaValue. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_VolumeType: La lista de códigos LA_VolumeType incluye todos los tipos de volumen diferentes, tales como oficial o calculado, utilizados en una implementación específica del perfil de administración del territorio. La lista de códigos LA_VolumeType es necesaria para implementar el tipo de dato de LA_VolumeValue. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

Comentario [CSS1]: Como es un tipo de dato no lleva acento

Comentario [CSS2]: Es un tipo de dato y por eso se pone en inglés

33

- LA_SurfaceRelationType: La lista de códigos LA_SurfaceRelationType incluye todos los tipos de relaciones con las superficies diferentes, tales como arriba o debajo de la superficie, utilizados en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_VolumeType solo es necesaria si se implementa el atributo surfaceRelation de la clase LA_SpatialUnit. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_DimensionType: La lista de códigos LA_DimensionType incluye todos los tipos de dimensiones diferentes, tales como 2D o 3D, utilizados en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_DimensionType solo es necesaria si se implementa el atributo dimension de la clase LA_SpatialUnit. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_UtilityNetworkStatusType: La lista de códigos LA_UtilityNetworkStatusType incluye todos los tipos diferentes de estados de la red servicios, tales como en proyecto o en uso, utilizados en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_UtilityNetworkStatusType solo es necesaria si se implementa el atributo status de la clase LA_LegalSpaceUtilityNetwork. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_RegisterType: La lista de códigos LA_RegisterType incluye todos los tipos de registros diferentes, tales como rural o urbano, utilizados en una implementación específica del perfil de administración del territorio. La lista de códigos LA_RegisterType solo es necesaria si se implementa el atributo registerType de la clase LA_Level. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_UtilityNetworkType: La lista de códigos LA_UtilityNetworkType incluye todos los tipos diferentes de redes de servicios, tales como de electricidad o gas, utilizados en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_UtilityNetworkType solo es necesaria si se implementa el atributo type de la clase LA_LegalSpaceUtilityNetwork. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_LevelContentType: La lista de códigos LA_LevelContentType incluye todos los tipos diferentes de contenido del nivel, tales como derecho primario o consuetudinario, utilizados en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_LevelContentType solo es necesaria si se implementa el atributo type de la clase LA_Level. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_StructureType: La lista de códigos LA_StructureType incluye todos los tipos diferentes de estructuras espaciales, tales como punto o polígono, utilizados en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_StructureType solo es necesaria si se implementa el atributo structure de la clase LA_Level. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

6.6 Clases del Subpaquete de Topografía y Representación

6.6.1 LA_Point (Puntos)

Las instancias de la clase LA_Point son puntos. Un punto puede estar asociado a cero o a una [0..1] unidad espacial (es decir, el punto se puede usar como punto de referencia para describir la posición de una unidad espacial). Un punto puede estar asociado con cero o más [0..*] caras lindero (es decir, un punto se puede usar para definir un vértice de un lado de una parcela 3D). Un punto puede estar

Comentario [CSS3]: Sin acento pq es un atributo en inglés

34

asociado a cero o más [0..*] cadenas de caras lindero (es decir, se puede usar un punto para definir el inicio, fin o un vértice de un lindero). Un punto debería estar asociado a cero o más [0..*] fuentes espaciales. Véase la figura 12.

Los atributos de la clase LA_Point son:

- estimatedAccuracy: La exactitud estimada del punto;

Tipo de valor: DQ_AbsoluteExternalPositionalAccuracy

Multiplicidad: 0..1

- interpolationRole: El rol del punto en la estructura de una línea recta o una curva;

Tipo de valor: LA_InterpolationType

Multiplicidad: 1

- monumentation: El tipo de monumento;

Tipo de valor: LA_MonumentationType

Multiplicidad: 0..1

- originalLocation: Las coordenadas calculadas, basadas en medidas u observaciones;


Multiplicidad: 1

- pID: El identificador del punto;

Tipo de valor: Oid

Multiplicidad: 1

- pointType: El tipo de punto;

Tipo de valor: LA_PointType

Multiplicidad: 1

- productionMethod: El linaje;

Tipo de valor: LI_Lineage

Multiplicidad: 0..1

- transAndResult: La transformación y la localización transformada;

Tipo de valor: LA_Transformation

Multiplicidad: 0..*

35

NOTA: El método “getTransResult( )” devuelve el punto transformado (GM_Point), y no se hereda de otras clases, ni está definido en otras normas internacionales ISO.

6.6.2 LA_SpatialSource (Fuentes espaciales)

Las instancias de la clase LA_SpatialSource son las fuentes espaciales. Un conjunto de mediciones con observaciones (distancias, ángulos, coordenadas GPS, etc.) de puntos, es un atributo de la clase LA_SpatialSource. La clase LA_SpatialSource es una subclase de la clase LA_Source. Una fuente espacial debe estar asociada a uno o más [1..*] puntos (es decir, la fuente espacial describe en todos los casos a uno o más puntos). Si la fuente espacial no describe al menos un punto, no debería ser una fuente espacial. Una fuente espacial puede estar asociada a cero o más [0..*] cadenas de caras lindero (es decir, la fuente espacial describe el lindero de una unidad espacial 2D). Una fuente espacial puede estar asociada a cero o más [0..*] caras lindero (es decir, la fuente espacial describe el lado de una unidad espacial 3D). Una fuente espacial puede estar asociada a cero o más [0..*] unidades espaciales (es decir, la fuente espacial describe la extensión de una unidad espacial). Una fuente espacial puede estar asociada a cero o más [0..*] unidades básicas administrativas (es decir, la fuente espacial describe la extensión de una propiedad). Una fuente espacial debe estar asociada a uno o más [1..*] interesados (es decir, debería especificarse, como mínimo, el interesado que juega el papel de autor de la fuente espacial, el topógrafo). Véanse las figuras 8 y 12.

Los atributos de la clase LA_SpatialSource son:

- measurements: Las observaciones y mediciones;

Tipo de valor: OM_Observation, basado en la Norma ISO 19156

Multiplicidad: 0..*

- procedure: El método topográfico utilizado;

Tipo de valor: OM_Process, basado en la Norma ISO 19156

Multiplicidad: 0..1

- type: El tipo de fuente espacial;

Tipo de valor: LA_SpatialSourceType

Multiplicidad: 1

NOTA 1: Las mediciones son la base para la representación y para la reconstrucción histórica de la localización de (partes de) la unidad espacial en campo.

NOTA 2: La relación con la clase LA_BAUnit se puede obtener a través de la clase LA_SpatialUnit.

6.6.3 LA_BoundaryFaceString (Cadenas de caras lindero)

Las instancias de la clase LA_BoundaryFaceString son las cadenas de caras lindero. La clase LA_BoundaryFaceString está asociada con la clase LA_Point y la clase LA_SpatialSource para documentar el origen de la geometría. En el caso de una localización textual, una cadena de caras lindero no se definiría por puntos. Sin embargo, en todos los casos restantes, una cadena de caras lindero se debe

36

definir por dos o más [2..*] puntos (es decir, como mínimo un lindero empieza y termina en un punto, es decir, es una línea recta).

NOTA: En el caso de que la cadena de caras lindero se defina textualmente, entonces, no hay puntos asociados; en el caso de que la cadena de caras lindero no se defina textualmente, entonces, al menos hay dos puntos asociados (definiendo la cadena de caras lindero).

En la asociación entre la clase LA_BoundaryFaceString y la clase LA_SpatialUnit, el + (símbolo más) significa que la cadena de caras lindero tiene la misma orientación dentro de la unidad espacial, y el – (símbolo menos) significa que la cadena de caras lindero asociada tiene una orientación opuesta dentro de la unidad espacial. Una cadena de caras lindero puede estar asociada a cero o más [0..*] fuentes espaciales (es decir, el lindero de una unidad espacial puede estar descrito por una o más fuentes espaciales, por la fuente espacial que crea la unidad espacial y por la fuente espacial que crea la unidad espacial colindante), véase la figura 12.

Los atributos de la clase LA_BoundaryFaceString son:

- bfsID: El identificador de la cadena de caras lindero;

Tipo de valor: Oid

Multiplicidad: 1

- geometry: El lindero representada por medio de una curva al nivel del terreno;

Tipo de valor: GM_MultiCurve (tipo de la Norma ISO 19107)

Multiplicidad: 0..1

- locationByText: El lindero representada en formato textual;


Multiplicidad: 0..1

NOTA: La geometría está derivada de la clase asociada LA_Point o bien está basada en la captura de una geometría lineal.

EJEMPLO: Las cadenas de caras lindero se muestran en diagramas de instancias, véase el anexo C, la figura C.33.

6.6.4 LA_BoundaryFace (Caras lindero)

Las instancias de la clase LA_BoundaryFace son las caras lindero. La clase LA_BoundaryFace está asociada con la clase LA_Point y la clase LA_SpatialSource para documentar el origen de la geometría. En el caso de una localización textual, la cara lindero no estará definida por puntos. Sin embargo, en todos los casos restantes, una cara lindero debe estar definida por tres o más [3..*] puntos (es decir, como mínimo, una cara triangular está definida por tres puntos). Una cara lindero puede estar asociada a cero o más [0..*] fuentes espaciales (es decir, la cara de una unidad espacial 3D puede estar descrita por una o más fuentes espaciales, por la fuente espacial que crea la unidad espacial y por la fuente espacial que

37

crea la unidad espacial colindante). La orientación del lindero que es igual a la orientación de la unidad espacial tiene la asociación “+”, en caso contrario “-“. Véase la figura 12.

Los atributos de la clase LA_BoundaryFace son:

- bfID: El identificador de la cara lindero;

Tipo de valor: Oid

Multiplicidad: 1

- geometry: El lindero representada por medio de una superficie en 3D;

Tipo de valor: GM_Surface (tipo de la Norma ISO 19107)

Multiplicidad: 0..1

- locationByText: El lindero representada en formato textual;


Multiplicidad: 0..1

NOTA: La geometría está derivada de la clase asociada LA_Point o bien está basada en la geometría superficial capturada.

EJEMPLO: Las caras lindero se muestran en diagramas de instancias, véase el anexo C, figura C.7.

6.6.5 Tipos de datos del Subpaquete de Topografía y Representación

El Subpaquete de Topografía y Representación tiene un tipo de datos: LA_Transformation. El tipo de dato genérico LA_Transformation se introduce en el LADM para proporcionar apoyo en la transformación de coordenadas entre dos sistemas de referencia.

Los atributos de la clase LA_ Transformation son:

- transformation: Descripción del método de transformación utilizado para obtener el valor de localización asociado;

Tipo de valor: CC_OperationMethod (de la Norma ISO 19111)

Multiplicidad: 1

- transformedLocation: Localización obtenida a partir del método operativo de transformación;

Tipo de valor: GM_Point (tipo de datos de la Norma ISO 19107)

Multiplicidad: 1

6.6.6 Listas de códigos del Subpaquete de Topografía y Representación

38

El Subpaquete de Topografía y Representación tiene cuatro listas de códigos (véase la figura 12). Véase el anexo J con ejemplos de los valores.

- LA_MonumentationType: La lista de códigos LA_MonumentationType incluye todos los tipos de monumentos diferentes, tales como baliza o poste, utilizados en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_MonumentationType es necesaria solo si se implementa el atributo monumentation de la clase LA_Point. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_SpatialSourceType: La lista de códigos LA_SpatialSourceType incluye todos los tipos de fuentes espaciales diferentes, tales como plano topográfico o fotografía aérea, utilizados en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_SpatialSourceType es necesaria para implementar la clase LA_SpatialSource. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_InterpolationType: La lista de códigos LA_InterpolationType incluye todos los tipos diferentes de interpolaciones de puntos, tales como inicio, final o arco medio, aplicables en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_InterpolationType es necesaria para implementar la clase LA_Point. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.

- LA_PointType: La lista de códigos LA_PointType incluye todos los tipos diferentes de puntos, tales como puntos de control o catastrales, aplicables en una implementación específica de un perfil de administración del territorio. La lista de códigos LA_PointType es necesaria para implementar la clase LA_Point. La lista de códigos debe proporcionar una lista completa de todos los códigos con un nombre y una descripción.


Figura 12 – Contenido del Subpaquete de Topografía y Representación con las asociaciones con otras clases (básicas)

6.7 Asociaciones entre clases

En este apartado se presentan tres tablas que resumen todas las relaciones entre las clases del LADM: para las asociaciones entre clases, véase la tabla 1; para las generalizaciones entre clases, véase la tabla 2; y para las agregaciones entre clases, véase la tabla 3.

Tabla 1 – Asociaciones entre las clases del LADM

Clase 1a Clase 2a Nombre de la

asociación

Nombre del rol en el

extremo 1

Multiplicidad Nombre del rol en el

extremo 2

Multiplicidad

<<Copiar la tabla igual que la original>>

a Se ha omitido el prefijo LA de los nombres de las clases por razones de espacio.

39

Tabla 2 – Generalizaciones entre las clases del LADM

Superclasea Subclasea



Tabla 3 – Agregaciones entre las clases del LADM

Clase 1a Clase 2a Nombre del rol en el

extremo 1

Multiplicidad Nombre del rol en el

extremo 2

Multiplicidad



Anexo A (normativo)

Conjunto de pruebas genéricas

A.1 Introducción

A.1.1 El conjunto de pruebas genéricas está en conformidad con la Norma ISO 19105. El LADM especifica un esquema conceptual. La utilización real del LADM requiere el desarrollo de un esquema de aplicación, como puede ser un perfil nacional. Este anexo especifica cómo probar si un esquema de aplicación específico es conforme con el LADM respecto al paquete y al nivel. Probar si un conjunto de datos específico es conforme, significa comprobar que el contenido del conjunto de datos es conforme con el correspondiente esquema de aplicación del LADM (paquete y nivel).

A.1.2 Este conjunto de pruebas genéricas especifica los requisitos que la implementación que está bajo prueba tiene que cumplir con el objetivo de ser conforme con esta norma internacional. Para cada prueba, el elemento de metadatos de conformidad toma uno de los siguientes valores:

1) Conforme (conformant). El recurso es totalmente conforme con la especificación citada.

2) No Conforme (notConformant). El recurso no es conforme con la especificación citada.

3) No evaluada (notEvaluated). No se ha evaluado la conformidad.

El LADM consta de 3 paquetes y un subpaquete, especificándose una prueba de conformidad para cada uno de ellos. Se especifican tres niveles de conformidad para cada (sub)paquete: nivel 1 (nivel bajo), nivel 2 (nivel medio) y nivel 3 (nivel alto). Un paquete es conforme a nivel 1 si las clases con indicador de nivel 1 pasan la prueba de conformidad. Un paquete es conforme a nivel 2 si las clases con indicadores de nivel 1 y 2 pasan la prueba de conformidad. Un paquete es conforme a nivel 3 si las clases con indicadores de nivel 1, 2 y 3 pasan la prueba de conformidad.

40

La tabla A.1 proporciona una visión global por paquete para comprobar la conformidad con el LADM. Las pruebas de conformidad del LADM pueden hacerse por paquete. Cuando se prueban dos o más paquetes, las pruebas de conformidad se deben hacer con interdependencias entre los paquetes aplicables. Los atributos obligatorios y opcionales se proporcionan en los diagramas de clases. Lo mismo es de aplicación a las asociaciones (también en el caso de interdependencias).

A.1.3 El método de prueba de este anexo se utiliza en todos los casos de prueba “para examinar el esquema de aplicación de la implementación bajo prueba, incluyendo las definiciones de las clases, de los atributos y de las asociaciones.” Hay diferentes maneras de documentar los resultados positivos del método de prueba:

1) Mostrar la estructura de herencia entre el LADM y el modelo a comprobar (elementos), o

2) Mostrar una correspondencia entre los elementos del LADM y el modelo a comprobar.

Las pruebas se documentan por clase en los capítulos del A.2 al A.4.

NOTA 1: Para realizar la prueba de conformidad de manera explícita y completa, es necesario tener conocimiento y entendimiento del LADM y del perfil específico utilizado. El perfil no debería incluir estructuras o soluciones diferentes donde el LADM tiene disposiciones normalizadas.

NOTA 2: Es posible realizar pruebas de conformidad por tipo de derecho, tipo de responsabilidad o tipo de restricción. En las listas de códigos de derechos, responsabilidades o restricciones, se pueden añadir valores específicos (definidos por el usuario), indicando una responsabilidad o restricción o derecho parcial, el cual no es homogéneo en el tiempo. Esto afecta a la unidad espacial completa con respecto al registro (por lo tanto es homogéneo en cierto sentido), pero en realidad afecta solo a una parte de la unidad espacial. Además, se puede definir una unidad espacial textual, describiendo la localización de la parte.

Tabla A.1 – Tabla de requisitos de conformidad del LADM

Paquete del LADM

Clase del LADM NCa Dependencias

- VersionedObject 1 LA_Source 1 Oid, (como mínimo se debe

implementar una de las especializaciones

(LA_AdministrativeSource o LA_SpatialSource)),

LA_AvailabilityStatusType Paquete de Interesados

Solo existe si se implementa el Paquete Administrativo

LA_Party 1 VersionedObject, Oid, LA_PartyType LA_GroupParty 2 Oid, LA_Party, LA_GroupPartyType LA_PartyMember 2 VersionedObject, LA_Party,

LA_GroupParty Paquete

Administrativo Solo existe si se implementa el

Paquete de interesados LA_RRR 1 VersionedObject, Oid, LA_Party,

LA_BAUnit, LA_Right (como mínimo, se debe implementar esta

41

especialización), LA_AdministrativeSource

LA_Right 1 LA_RRR, LA_RightType LA_Restriction 2 LA_RRR, LA_RestrictionType LA_Responsability 3 LA_RRR, LA_ResponsabilityType LA_BAUnit 1 VersionedObject, Oid, LA_RRR,

LA_BAUnit LA_Mortgage 2 LA_Restriction LA_AdministrativeSource 1 LA_Source, LA_Party,

LA_AdministrativeSourceType, LA_AvailabilityStatusType

LA_RequieredRelationshipBAUnit 3 VersionedObject, LA_BAUnit Paquete de Unidades Espaciales

LA_SpatialUnit 1 VersionedObject, Oid LA_SpatialUnitGroup 2 VersionedObject, Oid, LA_SpatialUnit LA_LegalSpaceBuildingUnit 3 LA_SpatialUnit LA_LegalSpaceUtilityNetwork 3 LA_SpatialUnit LA_Level 2 VersionedObject, Oid LA_RequieredRelationshipSpatialUnit 3 VersionedObject, LA_SpatialUnit

Subpaquete de Topografía y

Representación

LA_Point 2 VersionedObject, Oid, LA_SpatialSource, LA_PointType,

LA_InterpolationType LA_SpatialSource 2 LA_Source, LA_Point, LA_Party,

LA_SpatialSourceType LA_BoundaryFaceString 2 VersionedObject, Oid, LA_Point (si

utiliza geometría) LA_BoundaryFace 3 VersionedObject, Oid, LA_Point (si

utiliza geometría) a NC= Nivel de conformidad.

A.2 Conjunto de pruebas genéricas para el nivel 1 de conformidad (nivel bajo)

A.2.1 General

Este conjunto de pruebas comprueba el siguiente requisito: la implementación del paquete bajo comprobación debe contener al menos una de las clases básicas del LADM. La implementación de la clase debe ser conforme con la clase básica. Esto significa que un paquete LADM es conforme a nivel 1 si:

- Paquete de Interesados: pasa satisfactoriamente la prueba A.2.4; - Paquete Administrativo: pasa satisfactoriamente las pruebas A.2.3 y A.2.5 (destacar que, en

modelos donde hay una asociación 1 a 1 entre LA_Right y LA_BAUnit, ambos pueden estar representados por la misma implementación de la clase), o

- Paquete de Unidades Espaciales: pasa satisfactoriamente la prueba A.2.6.

A.2.2 Identificador del caso de prueba: VersionedObject

42

a) Propósito de la prueba: si se implementa VersionedObject, asegurar que la implementación del paquete bajo prueba contiene al menos una clase conforme con la definición de VersionedObject y que tiene todos los atributos obligatorios y roles de asociación de VersionedObject.

NOTA Los atributos obligatorios o asociaciones tienen una ocurrencia (multiplicidad) de 1 o mayor.

b) Método de la prueba: examinar el esquema de aplicación de la implementación bajo prueba, incluyendo definiciones de clases, atributo(s) y asociaciones.

c) Referencia: requisito de nivel 1, véase el apartado 6.2.1.

d) Tipo de prueba: básica.

A.2.3 Identificador del caso de prueba: Administrative::LA_BAUnit

a) Propósito de la prueba: si se implementa LA_BAUnit, asegurar que la implementación del paquete bajo prueba contiene al menos una clase conforme con la definición de LA_BAUnit y que tiene todos los atributos obligatorios y roles de asociación de LA_BAUnit.

NOTA Los atributos obligatorios o asociaciones tienen una ocurrencia (multiplicidad) de 1 o mayor.




A.2.4 Identificador del caso de prueba: Party::LA_Party

a) Propósito de la prueba: si se implementa LA_Party, asegurar que la implementación del paquete bajo prueba contiene al menos una clase conforme con la definición de LA_BAUnit y que tiene todos los atributos obligatorios y roles de asociación de LA_BAUnit.




A.2.5 Identificador del caso de prueba: Administrative::LA_Right

a) Propósito de la prueba: si se implementa LA_Right, asegurar que la implementación del paquete bajo prueba contiene al menos una clase conforme con la definición de LA_Right y que tiene todos los atributos obligatorios y roles de asociación de LA_Right.


c) Referencia: requisito de nivel 1, véanse los apartados 6.4.2 y 6.4.3.


43

A.2.6 Identificador del caso de prueba: Spatial Unit::LA_SpatialUnit

a) Propósito de la prueba: si se implementa LA_SpatialUnit, asegurar que la implementación del paquete bajo prueba contiene al menos una clase conforme con la definición de LA_ SpatialUnit y que tiene todos los atributos obligatorios y roles de asociación de LA_ SpatialUnit.




A.3 Conjunto de pruebas genéricas para el nivel 2 de conformidad (nivel medio)

A.3.1 General

Este conjunto de pruebas comprueba el siguiente requisito: la implementación del paquete bajo comprobación debe contener al menos la(s) clase(s) básica(s) y las clases más comunes del LADM. Estas clases del LADM son, además de las clases básicas (nivel 1): LA_AdministrativeSource, LA_BoundaryFaceString, LA_GroupParty, LA_PartyMember, LA_Point, LA_Restriction, LA_SpatialSource y LA_SpatialUnitGroup. La implementación de la clase debe ser conforme con la clase básica/común. Esto significa que un (sub)paquete del LADM es conforme a nivel 2 si es conforme a nivel 1 y si:

- Paquete de Interesados: pasa satisfactoriamente las pruebas A.3.4 y A.3.5; - Paquete Administrativo: pasa satisfactoriamente las pruebas A.3.2 y A.3.7; - Paquete de Unidades Espaciales: pasa satisfactoriamente la prueba A.3.9;

- Subpaquete de Topografía y Representación: pasa satisfactoriamente las pruebas A.3.3, A.3.6 y A.3.8.

A.3.2 Identificador del caso de prueba: Administrative::LA_AdministrativeSource

a) Propósito de la prueba: asegurar que la implementación bajo prueba contiene al menos una clase conforme con la definición de LA_AdministrativeSource y que tiene todos los atributos obligatorios y roles de asociación de LA_AdministrativeSource.


c) Referencia: requisito de nivel 2, véanse los apartados del 6.2.2 al 6.2.4


A.3.3 Identificador del caso de prueba: Surveying and Representation::LA_BoundaryFaceString

a) Propósito de la prueba: asegurar que la implementación bajo prueba contiene al menos una clase conforme con la definición de LA_BoundaryFaceString y que tiene todos los atributos obligatorios y roles de asociación de LA_BoundaryFaceString.


44



A.3.4 Identificador del caso de prueba: Party::LA_GroupParty

a) Propósito de la prueba: asegurar que la implementación bajo prueba contiene al menos una clase conforme con la definición de LA_GroupParty y que tiene todos los atributos obligatorios y roles de asociación de LA_GroupParty.




A.3.5 Identificador del caso de prueba: Party::LA_PartyMember

a) Propósito de la prueba: asegurar que la implementación bajo prueba contiene al menos una clase conforme con la definición de LA_PartyMember y que tiene todos los atributos obligatorios y roles de asociación de LA_PartyMember.




A.3.6 Identificador del caso de prueba: Surveying and Represention::LA_Point

a) Propósito de la prueba: asegurar que la implementación bajo prueba contiene al menos una clase conforme con la definición de LA_Point y que tiene todos los atributos obligatorios y roles de asociación de LA_ Point.




A.3.7 Identificador del caso de prueba: Administrative::LA_Restriction

a) Propósito de la prueba: asegurar que la implementación bajo prueba contiene al menos una clase conforme con la definición de LA_Restriction y que tiene todos los atributos obligatorios y roles de asociación de LA_Restriction.



45


A.3.8 Identificador del caso de prueba: Surveying and Representation::LA_SpatialSource

a) Propósito de la prueba: asegurar que la implementación bajo prueba contiene al menos una clase conforme con la definición de LA_SpatialSource y que tiene todos los atributos obligatorios y roles de asociación de LA_SpatialSource.




A.3.9 Identificador del caso de prueba: Spatial Unit::LA_SpatialUnitGroup

a) Propósito de la prueba: asegurar que la implementación bajo prueba contiene al menos una clase conforme con la definición de LA_SpatialUnitGroup y que tiene todos los atributos obligatorios y roles de asociación de LA_SpatialUnitGroup.




A.4 Conjunto de pruebas genéricas para el nivel 3 de conformidad (nivel alto)

A.4.1 General

Este conjunto de pruebas comprueba el siguiente requisito: la implementación del paquete bajo comprobación debe contener la(s) clase(s) básica(s) y todo el resto de clase(s) del LADM. Estas clases del LADM son, además de las clases básicas y las comunes (nivel 1 y 2): LA_BoundaryFace, LA_LegalSpaceBuildingUnit, LA_LegalSpaceUtilityNetwork, LA_Mortgage, LA_RequieredRelationshipSpatialUnit y LA_Responsability. La implementación de la clase debe ser conforme con la clase básica y común. Esto significa que un (sub)paquete del LADM es conforme al nivel 3, si es conforme a nivel 2 y:

- Paquete Administrativo: se pasan satisfactoriamente las pruebas A.4.5 y A.4.7. - Paquete de Unidades Espaciales: se pasan satisfactoriamente las pruebas A.4.3, A.4.4 y A.4.6

- Subpaquete de Representación Espacial: se pasa satisfactoriamente la prueba A.4.2.

A.4.2 Identificador del caso de prueba: Surveying and Representation::LA_BoundaryFace

a) Propósito de la prueba: asegurar que la implementación bajo prueba contiene al menos una clase conforme con la definición de LA_BoundaryFace y que tiene todos los atributos obligatorios y roles de asociación de LA_BoundaryFace.

46




A.4.3 Identificador del caso de prueba: Spatial Unit::LA_LegalSpaceBuildingUnit

a) Propósito de la prueba: asegurar que la implementación bajo prueba contiene al menos una clase conforme con la definición de LA_LegalSpaceBuildingUnit y que tiene todos los atributos obligatorios y roles de asociación de LA_LegalSpaceBuildingUnit.




A.4.4 Identificador del caso de prueba: Spatial Unit::LA_LegalSpaceUtilityNetwork

a) Propósito de la prueba: asegurar que la implementación bajo prueba contiene al menos una clase conforme con la definición de LA_LegalSpaceUtilityNetwork y que tiene todos los atributos obligatorios y roles de asociación de LA_LegalSpaceUtilityNetwork.




A.4.5 Identificador del caso de prueba: Administrative::LA_Mortgage

a) Propósito de la prueba: asegurar que la implementación bajo prueba contiene al menos una clase conforme con la definición de LA_Mortgage y que tiene todos los atributos obligatorios y roles de asociación de LA_Mortgage.




A.4.6 Identificador del caso de prueba: Spatial Unit::LA_RequiredRelationshipSpatialUnit

a) Propósito de la prueba: asegurar que la implementación bajo prueba contiene al menos una clase conforme con la definición de LA_RequiredRelationshipSpatialUnit y que tiene todos los atributos obligatorios y roles de asociación de LA_RequiredRelationshipSpatialUnit.

47




A.4.7 Identificador del caso de prueba: Administrative::LA_Responsability

a) Propósito de la prueba: asegurar que la implementación bajo prueba contiene al menos una clase conforme con la definición de LA_Responsability y que tiene todos los atributos obligatorios y roles de asociación de LA_Responsability.




Anexo B (normativo)

Representaciones 2D y 3D de las unidades espaciales

Las representaciones 2D y 3D de unidades espaciales utilizan las cadenas de caras lindero y las caras lindero como conceptos clave (véase también la figura 12).

En muchos países, se interpreta la representación 2D como un volumen prismático 3D, sin límite superior e inferior. Usando esta interpretación, se pueden unificar las representaciones 2D y 3D:

a) Para representaciones 2D, mediante cadenas de caras lindero utilizando para el almacenamiento una GM_MultiCurve (linestring, cadena de líneas). Las cadenas de caras lindero también implican una serie de caras lindero verticales virtuales, véanse las figuras B.1 y B.2. << copiar la figura B.1 traduciendo: Linestring at local ground level -> Linestring al nivel del terreno local Node = vertical edge -> Nodo = borde vertical >>

Figura B.1 – Conceptos de las cadenas de caras lindero << copiar la figura B.2 traduciendo: Left parcel = parcela izquierda Right parcel = parcela derecha >>

Figura B.2 – Unidades espaciales definidas por cadenas de caras lindero

48

b) Para representaciones 3D de los linderos reales, mediante caras lindero utilizando para el almacenamiento una GM_Surface (que puede ser curvada). Las caras lindero pueden también tener linderos 3D reales no verticales. Esto también permite la representación de un volumen, como un cono invertido, donde la parte superior es más ancha que la inferior.

Las unidades espaciales liminares están en el umbral entre las representaciones 2D y 3D. Estas representaciones son una combinación de cadenas de caras lindero y caras lindero verticales. Las caras lindero verticales se deben disolver en cadenas de caras lindero (al eliminar las parejas de bordes comunes). Las caras lindero deben estar completamente definidas entre un límite superior (indefinido) y un límite inferior (indefinido), véanse las figuras B.3 y B.4. Este método se utiliza para las unidades espaciales 2D que son adyacentes a unidades espaciales 3D, con una separación en las caras lindero verticales compartidas.

<< copiar la figura B.3 traduciendo: Simple 2D spatial unit = Unidad espacial 2D simple Liminal 2D spatial unit = Unidad espacial 2D liminar 3D spatial units = Unidades espaciales 3D 3D spatial units = Unidades espaciales 3D

Liminal 2D spatial unit A = Unidad espacial 2D liminar A Liminal 2D spatial unit = Unidad espacial 2D liminar

>> Figura B.3 – Vista en planta de representaciones mixtas 2D/3D

<< copiar la figura B.4 traduciendo: Liminal = Liminar >>

Figura B.4 – Vista lateral que muestra el uso mixto de cadenas de caras lindero y caras lindero para definir, tanto volúmenes 3D limitados, como ilimitados

El atributo “dimension” de la clase LA_SpatialUnit indica si se refiere a una representación de una unidad espacial 2D, liminar o 3D.

Anexo C (informativo)

Casos a nivel de instancia Este anexo ilustra la flexibilidad y funcionalidad de esta norma internacional, mostrando su uso en casos reales de todo el mundo. El contenido de este anexo se basa en la Normas ISO 19109:2005, ISO 19110:2005, ISO 19126:2009 e ISO 19131:2007. Los ejemplos se basan parcialmente en la terminología del STDM (véase anexo I) para ilustrar el contexto del STDM.

1) Arrendamiento de larga duración (figura C.1).

El arrendamiento y la propiedad están basados en el código civil de un país particular. Un arrendatario (Joe) y un propietario (Fruit Co).

2) Derecho consuetudinario (figura C.2).

Unidades espaciales (Area 1: LA_Parcel y Area 2: LA_Parcel), con un derecho consuetudinario (STDM_Relationship) de la agrupación Dong People.

Comentario [CSS4]: Sin acento porque se trata del nombre de un atributo y va en inglés

49

3) Parcela de servicio – propiedad de los vecinos (figura C.3).

Una parcela de servicio proporciona acceso a cuatro parcelas, y la parcela de servicio no es pública, pero es propiedad común de las cuatro parcelas vecinas (una baunit como interesado).

4) Parcela de servicio – propiedad de un interesado diferente (figura C.4).

Una parcela de servicio proporciona acceso a cuatro parcelas, la parcela de servicio no es pública, pero es propiedad de un quinto interesado. Las cuatro parcelas vecinas tienen derecho de paso.

5) Asociación de interesados (figura C.5).

Una asociación de interesados tiene el derecho de propiedad de una parcela. La asociación de interesados está compuesta de 3 interesados.

6) Edificio de apartamentos (figura C.6).

Un edificio contiene unidades individuales (apartamentos), una unidad compartida con un portal común (entrada) y una parcela de terreno. Cada propietario de cada unidad tiene una participación en la unidad compartida y en la parcela de terreno.

7) Unidad espacial 3D (figura C.7).

Una unidad espacial volumétrica 3D con un propietario.

8) Propiedad a tiempo compartido (figura C.8).

Una propiedad a tiempo compartido para el mes de febrero (los propietarios de otros meses no se muestran).

9) Restricción (figura C.9).

Una restricción de no alterar un edificio por su estatus de monumento.

10) Hipoteca sobre una propiedad (figura C.10).

Una hipoteca sobre una propiedad, el banco se incluye como interesado.

11) Hipoteca sobre una propiedad en usufructo (figura C.11).

Una hipoteca sobre una propiedad en usufructo, la persona que aporta el dinero se incluye como interesado.

12) Derecho no formalizado – unidad espacial textual (figura C.12).

Derecho no formalizado de un interesado (una persona física) sobre una unidad espacial textual.

13) Derecho no formalizado – unidad espacial puntual (figura C.13).

50

Derecho no formalizado de una asociación de interesados sobre una unidad espacial puntual.

14) Conflicto (figura C.14).

Una reclamación con conflicto sobre una unidad espacial.

15) Red de servicios (figura C.15).

Una red de servicios con un propietario y una hipoteca (el banco se incluye como interesado).

16) Pastores (figura C.16).

Una asociación de interesados (pastores) con derecho de paso por cierto periodo de tiempo.

17) Unidad de propiedad básica – Finlandia (figura C.17).

Un caso simple de propiedad de una unidad de propiedad básica con varias unidades espaciales.

18) Valoración (figura C.18).

El valor como base para la tributación válida para cinco años (fíjese que la valoración y la tributación quedan fuera del campo de aplicación del LADM).

19) Derecho a ordeñar (figura C.19).

Un derecho a ordeñar en una unidad espacial

20) Responsabilidad (figura C.20).

La responsabilidad de limpiar las acequias.

21) Derecho de uso (I) (figura C.21).

El derecho de usar una carretera en la propiedad de otro (I).

22) Derecho de uso (II) (figura C.22).

El derecho de usar una carretera en la propiedad de otro (II).

23) Un área de restricción (figura C.23).

Un área de restricción (“no está permitido construir en un entorno de 200 metros de una gasolinera”) con su propia geometría.

24) Complejo de unidades espaciales (I) (figura C.24).

Un complejo de unidades espaciales con un propietario.

25) Complejo de unidades espaciales (II) (figura C.25).

Comentario [CSS5]: Error en la norma, se repite lo del epígrafe anterior. Sin embargo hay dos modelos UML diferentes.

51

Un complejo de unidades espaciales con edificio, de un único propietario (Aurora).

26) Complejo de unidades espaciales (III) (figura C.26).

Un complejo de unidades espaciales de parcelas con dos propietarios.

27) Microcrédito (figura C.27).

Una unidad espacial con un microcrédito

28) Valoración de impuestos - España (figura C.28).

Valoración de impuestos en los derechos de condominio en España. Un propietario de una unidad de edificación y las zonas relacionadas comunes e individuales está sujeto a los impuestos totales, calculados a partir de sub-áreas de categorías de uso fiscales uniformes.

29) Propiedad de un edificio (figura C.29).

Una unidad espacial con un propietario, con un edificio de otro propietario diferente.

30) Matrimonio y herencia (I) – España (figura C.30).

Relaciones de matrimonio y herencia con la propiedad (simple) en España. Una pareja casada posee una propiedad con igual participación.

31) Matrimonio y herencia (II) – España (figura C.31).

Relaciones de matrimonio y herencia con la propiedad (complejo) en España. Después de la muerte de Peter, deja en usufructo su parte de la propiedad a Mary, quien todavía tiene la otra mitad en propiedad. Sus tres hijos, Sasha, Teun e Inge, heredan una participación igual de la parte de Peter.

32) Bien inmueble – España (figura C.32).

El “bien inmueble de características especiales” en España es una clase de propiedad inmobiliaria. El Catastro español distingue dos categorías básicas: bienes inmuebles urbanos y bienes inmuebles rústicos. Existe una tercera categoría residual para bienes inmuebles especiales, cuyas características requieren un tratamiento diferente, concretamente con respecto a la valoración. El ejemplo se centra en un aeropuerto.

33) Unidades de propiedad básicas (I) – Noruega (figura C.33).

Categorías noruegas de unidades de propiedad básicas. Ejemplos de Unidad de Volumen (Volume Unit), Propiedad de terreno (Landed Property) y Unidad de Terreno Arrendada (Leased Land Unit).

34) Unidades de propiedad básicas (II) – Noruega (figura C.34).

Categorías noruegas de unidades de propiedad básicas. Ejemplos de Unidad en Co-Propiedad (Co-Ownership Unit) y Unidad de Sección (Section Unit).

35) Propiedad individual y colectiva – España (figura C.35).

52

Derechos de propiedad individual y colectiva en España. “Corona” es el nombre del edificio.

36) Derechos de pastoreo de los pastores – Kenia (figura C.36).

Derechos de pastoreo de los pastores en Kenia. Un grupo de pastores en Kenia tiene dos tipos de derecho diferentes: 1. un derecho a usar pasillos para el desplazamiento (estos pueden atravesar tierras de granjeros) y 2. un derecho de acceso a zonas de pastoreo por un periodo de tiempo mayor.

37) Derechos consuetudinarios – Ghana (figura C.37).

Derechos consuetudinarios en Ghana. En Ghana los derechos consuetudinarios se basan en una jerarquía de los interesados (el Rey, el Jefe Supremo, el Jefe de la aldea, el Cabeza de familia y el Jefe del hogar), RRRs y las BA/Unidades Espaciales (Reinado, Región, Aldea, Unidad espacial de la Familia y Unidad Espacial del Hogar).

38) Subdivisión (figura C.38).

Una subdivisión aceptada, que resulta en la parcela A y B. El notario A prepara una transacción de propiedad, descrita en la escritura de transacción, que es aceptada por la organización de Administración del Territorio (LA).

39) Compra y venta de una unidad espacial (figura C.39).

Compra y venta de una unidad espacial. El notario A prepara una transacción de propiedad, descrita en la escritura de transacción, que es aceptada por la organización de Administración del Territorio (LA).

<<Copiar la figura C.1 como la original traduciendo las notas de la siguiente manera (de arriba abajo, primero la de la derecha y luego la de la izquierda)

timeSpec debe ser interpretado como un derecho permanente.

timeSpec es a partir de la fecha de registro.

>>

Figura C.1 - Arrendamiento

<<Copiar la figura C.2 como la original >>

Figura C.2 – Derecho consuetudinario

<<Copiar la figura C.3 como la original traduciendo las nota de la siguiente manera

Una parcela de servicio (instancia de LA_BAUnit) no tiene directamente un propietario físico o jurídico, pero en su lugar se define la propiedad por medio de asociaciones a partir de las parcelas a las que da servicio (parcelas de 1 a 4 en el diagrama) mediante el derecho

de propiedad común. >>

Figura C.3 - Parcela de servicio – propiedad de los vecinos

53


Figura C.4 – Parcela de servicio – propiedad de un interesado diferente


Figura C.5 - Asociación de interesados

<<Copiar la figura C.6 como la original traduciendo la nota de la siguiente manera:

Este diagrama se desarrolla desde el punto de vista de un propietario de un apartamento concreto, Frank. >>

Figura C.6 – Edificio de apartamentos


Figura C.7 - Unidad espacial 3D


Figura C.8 – Propiedad a tiempo compartido


Figura C.9 - Restricción


Figura C.10 – Hipoteca sobre una propiedad


Figura C.11 - Hipoteca sobre una propiedad en usufructo


Figura C.12 – Derecho no formalizado – unidad espacial textual


Figura C.13 - Derecho no formalizado – unidad espacial puntual


Esta unidad espacial hace referencia al área con reclamación de solape. >>

Figura C.14 – Conflicto


Figura C.15 - Red de servicios


54

Figura C.16 – Pastores


Figura C.17 - Unidad de propiedad básica – Finlandia


Cada valor (value) se debe corresponder con una fecha de valor (valueDate) en el orden de la lista. La cantidad de impuestos (amount) está calculada solo para la última fecha de

valoración. >>

Figura C.18 – Valoración


Figura C.19 – Derecho a ordeñar


Figura C.20 – Responsabilidad


Se debería verificar que existe una relación espacial (topológica) entre el paso y la unidad espacial de la Parcela 3 que queda debajo. Si se implementa utilizando los Fenómenos

Simples y la Norma ISO 19125-2, se puede usar la operación ST_Within para comprobar la relación entre las dos geometrías. >>

Figura C.21 - Derecho de uso (I)


Como se ha utilizado una construcción explícita parte-de-parcela (unidad espacial), no hay necesidad de comprobación de una relación adicional espacial (topológica). >>

Figura C.22 – Derecho de uso (II)


La unidad espacial que representa la restricción de no construcción (“noBuilding”) debería derivarse a partir de la unidad espacial de la gasolinera (Fuel Station) (suID = 150) a través de una operación de área de influencia. Cuando se implemente, utilizando los Fenómenos Simples y la Norma ISO 19125-2, se puede generar la geometría necesaria con el operación

ST_Buffer(200,metres). >>

Figura C.23 - Un área de restricción


Un número de parcelas no contiguas bajo la misma propiedad, que están en la misma unidad básica administrativa, se pueden relacionar con una sola unidad básica

administrativa (baunit) en algunas jurisdicciones.>>

55

Figura C.24 – Complejo de unidades espaciales (I)


Nota: Las parcelas 1 y 2 del complejo son disjuntas, el edificio debería estar dentro de la parcela 2. Esto se puede comprobar proyectando el borde del edificio sobre el nivel de las

parcelas.>>

Figura C.25 - Complejo de unidades espaciales (II)

<<Copiar la figura C. 26 como la original >>

Figura C.26 – Complejo de unidades espaciales (III)


Figura C.27 - Microcrédito

<<Copiar la figura C.28 como la original traduciendo las notas de la siguiente manera:

En este caso, hay más de un uso fiscal, y la unidad espacial se descompone en unidades espaciales de uso fiscal, como las que se presentan aquí.

Actualmente, la clase de valoración, así como la calle y las direcciones de los edificios, y el uso del suelo, se consideran todas como Registros Externos a los que el LADM tiene

enlaces externos. Esto significa que durante la implementación, se deberían desarrollar interfaces, tales como aquellas que proporcionen conexión a (en este caso) los registros de valoración, proporcionándoles datos de las unidades básicas administrativas y las unidades espaciales relacionadas, con el objetivo de validar, procesar o llevar a cabo las peticiones

de transacción sobre, por ejemplo, las unidades espaciales de uso fiscal.>>

Figura C.28 – Valoración de impuestos - España


Se debería verificar la relación topológica espacial entre el edificio y la unidad espacial que está debajo, por ejemplo, a través de un perfil espacial.>>

Figura C.29 - Propiedad de un edificio


Para este caso, se ha considerado un ejemplo simple de propiedad conjunto de una parcela rural simple. El modelo también podría representar la propiedad de un piso en

condominio, pero esto sería un ejemplo más complejo.>>

Figura C.30 – Matrimonio y herencia (I) – España


Ahora hay un total de 4 propietarios conjuntos de la propiedad, Mary y sus tres hijos. El usufructo debe ser considerado como un tipo derivado (un derecho personal). La

56

constricción de que la suma de las participaciones sea uno tiene que comprobarse de manera separada para cualquier tipo de derecho; en este ejemplo “propiedad” y

“usufructo”. La baunit, al estar basada en parcelas, mantiene el mismo uID pero se actualiza con la nueva situación relativa a los derechos (como se puede comparar con la

Parte 1 – Caso 30). La unidad espacial se mantiene igual, porque no conlleva cambios geométricos.>>

Figura C.31 - Matrimonio y herencia (II) - España


Este caso extiende el LADM genérico, considerando uno de los mecanismos disponibles para los modelos nacionales individuales, concretamente añadir tipos de categorías

específicos en valores codificados y enumeraciones. En este caso, el registerType recibe un nuevo tipo “ES_special”.

Además, las instancias de la clase LA_BAUnit se relacionan con un número diferente de parcelas, que pueden ser espacialmente disjuntas. Aunque estas parcelas son disjuntas,

pertenecen a la partición completa del espacio (2D), que podría ser verificado topológicamente.>>

Figura C.32 – Bien inmueble – España

<<Copiar la figura C.33 como la original traduciendo las notas de la siguiente manera (de arriba abajo y de izquierda a derecha):

Cada una de las cinco especializaciones (junto con las del caso C34 – Parte 2) de las Unidades de Propiedad Básicas Noruegas se muestran mediante una instancia específica

conectada con una unidad básica administrativa de LADM. Las asociaciones con los derechos se muestran siempre que sean relevantes, pero los interesados no se muestran

en estos diagramas.

Otros ejemplos se refieren a esta categoría, como las propiedades 3D (volúmenes) o las piscifactorías en el mar.

Todas las Propiedades de terreno pertenecientes al mismo propietario (con el mismo tipo de derechos) dentro de una división administrativa se registran en una única baunit. Las

unidades espaciales pueden ser espacialmente disjuntas.

Ejemplo de Unidad de Terreno Arrendada>>

Figura C.33 - Unidades de propiedad básicas (I) – Noruega

<<Copiar la figura C.34 como la original las notas de la siguiente manera (de arriba abajo)

Ejemplo de Unidad de Co-Propiedad

Ejemplo de Unidad de Sección

Debido al gran número de objetos en el tipo de Sección de la Unidad Catastral, en este diagrama no se muestran los valores de los componentes espaciales. Los edificios y las

57

unidades de edificación está previsto que se representen en 3D, esto es, en una capa separada de la Unidad Espacial del portal, que representa parcelas pequeñas alrededor de

los edificios. Esto podría representarse en 2D. El conjunto de unidades espaciales (y las especializaciones relacionadas), que representan la totalidad, están bajo Co_Propiedad, y

la edificación está distribuida en dos secciones diferentes.

>>

Figura C.34 – Unidades de propiedad básicas (II) – Noruega


Figura C.35 - Propiedad individual y colectiva – España


Figura C.36 – Derechos de pastoreo de los pastores – Kenia


Figura C.37 - Derechos consuetudinarios – Ghana


Figura C.38 – Subdivisión


Figura C.39 – Compra y venta de una unidad espacial

Anexo D

(informativo)

Perfiles nacionales

En este anexo se mencionan ocho perfiles nacionales del LADM:

1) Portugal (figuras D.1 y D.2). 2) Queensland, Australia (figura D.3). 3) Indonesia (figura D.4). 4) Japón (figura D.5). 5) Hungría (figura D.6). 6) Holanda (figura D.7). 7) Federación de Rusia (figura D.8). 8) República de Corea (figura D.9).

<<Copiar la figura D.1>>

Figura D.1 – Perfil nacional de Portugal – Visión general de los paquetes

58

NOTA 1 El perfil nacional portugués es el resultado de una investigación académica orientada a obtener una metodología para derivar un modelo especializado a partir del modelo de dominio del LADM, usando las tecnologías de la información más innovadoras. Actualmente, el Instituto Geográfico Portugués ha publicado un nuevo modelo de datos catastral conforme con varias normas internacionales ISO. Se está trabajando en actualizar este perfil nacional para reflejar las nuevas especificaciones

El perfil nacional portugués completo incluye varios diagramas de clases, de los cuales, los más importantes se presentan aquí: la vista general de paquetes (figura D.1) y las especializaciones del paquete LADM SpatialUnit (figura D.2). La vista general de paquetes enumera todas las clases creadas en el perfil nacional, agrupadas en dos paquetes: LegalAdministrative y SpatialUnit. Otros paquetes basados en las clases básicas LA_Party y LA_BAUnit del LADM no se han desarrollado a fondo en este perfil, por lo que se usan las clases normalizadas. La vista general muestra las dependencias entre los paquetes del perfil nacional y los de la norma, y el uso de dos perfiles espaciales del LADM: Topológico 2D (figura E.6) y Poligonal 2D (figura E.5). Se han creado también varios diagramas de instancias de nivel mostrando ejemplos concretos combinando objetos de unidades espaciales y legales. Este perfil nacional muestra el elevado nivel de detalle que se puede obtener de la especialización de los paquetes del LADM y el uso de los perfiles del LADM. La especialización de SpatialUnit define tres clases, las cuales pertenecen al Tipo Estructural topológico, por tanto son bidimensionales, y juntas forman una partición planar. Como se explica en la nota del diagrama, se pueden definir más constricciones para implementar tales clases en una base de datos espacial.

<<copiar la figura D.2 traduciendo la nota:

Los Niveles del 1 al 3 en conjunto forman la partición completa (fullPartition) (en un espacio de coordenadas 2D), y por lo tanto, deberían obedecer a la siguiente relación topológica (de acuerdo con

Meijers): “La unión de la geometría de todos los fenómenos poligonales debería cubrir todo el área (por lo que no se permiten huecos), y no está permitido el solape de polígonos (la intersección de los

interiores de todos los polígonos es el conjunto vacío)”.

Actualmente, no hay definido un operador espacial Union en el perfil de Fenómenos Simples, para así obtener la unión de la geometría. Sin embargo, los operadores topológicos binarios ST_Contains y

ST_Overlaps (=False) podrían ser de utilidad para formalizar dichas constricciones, como se ejemplifica en una especialización de LA_RequieredRelationshipSpatialUnit. El área contenida válida podría darse

mediante una instancia de la clase raíz CadastralCoverage. >>

Figura D.2 – Perfil nacional de Portugal - Especializaciones de la Unidad Espacial

El concepto que hay detrás de este diagrama es que cualquier lugar dentro del territorio nacional puede estar cubierto por una instancia de estas tres clases, esto es, cualquier lugar tiene que estar clasificado como PT_ParcelG, PT_SocialArea o PT_Baldio. El siguiente listado proporciona una breve definición de estas clases, las cuales están básicamente arraigadas al marco jurídico.

- PT_ParcelG: clase espacial que representa una parcela perteneciente al régimen jurídico de la propiedad privada inamovible. Estas parcelas son aquellas que se pueden registrar legalmente formando una entidad jurídica autónoma;

- PT_SocialAreal: vías públicas que dan servicio a varias parcelas, o a otras áreas de dominio público nacional o municipal (las cuales no están bajo el régimen de la propiedad privada);

59

- PT_Baldio: clase espacial bajo un régimen jurídico especifico, que pertenece a una comunidad local, como reconoce la Constitución Portuguesa.


Figura D.3 –Perfil nacional de Queensland, Australia


Figura D.4 – Perfil nacional de Indonesia

<<Copiar Figura D.5>>

Figura D.5 – Perfil nacional de Japón

NOTA 2 En Japón, los municipios locales realizan nuevos levantamientos catastrales para mejorar la precisión. Las oficinas del registro actualizan los catastros y los registros de tierras basándose en los resultados de esa nueva medición. El modelo de datos para la transferencia de datos desde los municipios a las oficinas del registro se resume en un diagrama de clases UML. El modelo de datos del sistema de información en las oficinas del registro no está abierto al público.

NOTA 3 Este perfil es un ejemplo de las posibles aplicaciones del LADM en Japón. Cada implementación real no está limitada al perfil.


Figura D.6 – Perfil nacional de Hungría


Figura D.7 – Perfil nacional de Holanda


Figura D.8 – Perfil nacional de la Federación de Rusia


Figura D.9 – Perfil nacional de la República de Corea

Anexo E (informativo)

Unidades espaciales y perfiles espaciales

El LADM soporta diferentes tipos de unidades espaciales tal y como indica el atributo “structure” de la clase LA_Level:

- Una unidad espacial “basada en croquis” se usa cuando hay disponible un croquis (un dibujo rápido de una agrupación de unidades espaciales) por ejemplo un croquis y fotografías, en ausencia de una identificación mejor.

60

- Una unidad espacial “basada en un punto” (unidad espacial puntual) se usa cuando la única información del lugar es un par de coordenadas de un único punto dentro de su área (o volumen). El atributo “referencePoint” de LA_SpatialUnit se usa para anotar esta localización, que puede incluir un valor z.

- Una unidad espacial “basada en texto” (unidad espacial textual) se usa cuando su definición está completamente descrita por un texto. La unidad espacial está acompañada de una o varias cadenas de caras lindero, cada una de las cuales lleva un bloque de texto libre en el atributo “locationByText” de la clase LA_BoundaryFaceString. Ninguna geometría se usa para este tipo de cadenas de caras lindero. El atributo “referencePoint” es opcional y se puede usar como un punto para etiquetar, también puede llevar asociado un valor z;

- Una unidad espacial “basada en líneas no estructuradas” (unidad espacial lineal “espagueti”) se usa cuando en su representación están permitidas las inconsistencias, tales como líneas colgadas y linderos incompletos. Para el caso 2D, las cadenas de caras lindero se almacenan una sola vez, sin romperse en las esquinas de la unidad espacial. Las unidades espaciales están vinculadas con las cadenas de caras lindero que las definen. Para el caso 3D, al menos se incluye una cara lindero (y esta puede intersecarse con otras cadenas de caras lindero y caras lindero);

- Una unidad espacial “basada en polígono” (unidad espacial poligonal) se usa cuando cada unidad espacial se registra como una entidad separada. No hay conexión topológica entre las unidades espaciales vecinas (y no se comparten los linderos), y por tanto, cualquier constricción que fuerce una cobertura completa, se debe aplicar en el software de origen y de destino. En la representación 2D hay exactamente un vínculo a una cadena de caras lindero cerrada para cada anillo del polígono (o un conjunto de cadenas de caras lindero, que juntas forman un anillo cerrado). Una unidad espacial poligonal, utilizada en una representación 3D, utiliza al menos una cara lindero (no compartida).

- Una unidad espacial “basada en topología” (unidad espacial topológica) se usa cuando las unidades espaciales comparten representaciones de linderos. Una unidad espacial topológica esta codificada mediante referencias a sus linderos, almacenando el lindero común entre las dos unidades espaciales una sola vez. De este modo hay una conexión topológica entre los vecinos. Para una representación 2D, las cadenas de caras lindero se utilizan formando bucles cerrados y estas cadenas de caras lindero tienen referencias de las unidades espaciales a izquierda y derecha. En el caso de una representación 3D, al menos se incluye una cara lindero con información de la izquierda y derecha.

También son posibles representaciones mixtas, porque una cadena de caras lindero puede estar definida por una geometría, o bien por una cadena de texto libre. Es posible especificar una unidad espacial, cualquiera que sea su codificación, por una geometría en alguna de sus caras lindero y por texto en otras. También es posible codificar topológicamente unidades espaciales basadas en texto; por ejemplo, una parte de un lindero se puede definir textualmente (por ejemplo, “a lo largo de la orilla natural”), mientras que otros linderos se pueden definir por coordenadas. La cadena de caras lindero que define la orilla se puede utilizar en la definición del fenómeno de agua al otro lado del lindero, esto asegura la corrección topológica sin necesidad de valores de coordenadas. Otra vez, esto puede ocurrir tanto en 2D como en 3D.

61

Se debería resaltar que lo anterior se aplica a cualquier tipo de unidad espacial (incluyendo aquellas que se utilizan para registrar espacios alrededor de edificaciones y redes de servicios, o para servidumbres). Para organizar las instancias, existe el concepto de nivel. Esto es especialmente relevante para unidades espaciales basadas en topología, pero también se aplica a los otros tipos. Por ejemplo, puede haber un nivel base (Nivel 1) con la propiedad de las unidades espaciales, que esté topológicamente definido, y puede haber un nivel adicional (Nivel 2) con unidades espaciales basadas en polígonos que representen las servidumbres. El concepto de nivel también se puede utilizar en otras situaciones. Por ejemplo, el Nivel 1 para presentar la propiedad y el Nivel 2 para presentar la propiedad antes de la guerra. Un ejemplo 3D sería, el Nivel 1 que contenga la propiedad (unidades espaciales 2D, liminares y topológicas 3D) y el Nivel 2 que contenga la propiedad del “espacio jurídico” alrededor de las redes de servicios, cruzando otras muchas unidades espaciales (a partir de las cuáles se puede extraer el espacio de las redes de servicios), véase la figura E.1.

Las estructuras (topológicas) 2D o 3D deben ser válidas en cualquier momento. Con unidades espaciales topológicas, no hay huecos ni solapes en la partición. Sin embargo, los linderos que pertenecen a diferentes periodos de tiempo (definidas por las versiones) se pueden cruzar. La topología temporal también se debe mantener: es decir, no debería haber huecos ni solapes temporales en las representaciones. Por lo tanto, la estructura está basada en una topología espacio-temporal. Los sistemas de administración del territorio actuales, basados en unidades espaciales 2D topológicas y representados geométricamente, han mostrado limitaciones en la definición (2D y 3D) de localizaciones de construcciones 3D (por ejemplo, tuberías, túneles, complejos de edificios) y en la dimensión vertical (profundidad y altura) de los derechos establecidos para las construcciones 3D. En el LADM, los datos 2D y 3D se tratan de manera consistente a lo largo del modelo. Es importante darse cuenta que hay una diferencia entre el objeto físico 3D y el espacio jurídico relacionado con ese objeto. El LADM solo cubre el “espacio jurídico”; que es el espacio que es relevante para la administración del territorio (la envoltura que cubre el objeto). Este es normalmente mayor que la extensión física del objeto en sí misma (por ejemplo incluyendo una zona de seguridad).

<<Copiar Figura E.1 traduciendo:

GM_Curve cerrada

Z=0 o local

Unidad espacial 3D en el Nivel 2 sin romperse por los linderos (cadenas de caras lindero) en el Nivel 1>>

Figura E.1 – Nociones de múltiples niveles

El subpaquete de Topografía y Representación del LADM (véase el apartado 5.6) permite un número de representaciones posibles de unidades espaciales en 2D, 3D o mixta (2D y 3D). Para un tipo específico de representación espacial, hay a menudo un número limitado de clases y atributos necesarios, un perfil espacial. Este anexo muestra las clases y atributos necesarios para cada perfil espacial. Los casos 3D también cubren las configuraciones mixtas 2D y 3D. Además, en un perfil nacional específico, es posible combinar varios perfiles espaciales, por ejemplo, unidades espaciales con topología 2D y edificaciones con polígonos 2D.

- Basado en Puntos 2D (figura E.2) - Basado en Textos 2D (figura E.3)

62

- Basado en líneas no estructuradas 2D (figura E.4) - Basado en Polígonos 2D (figura E.5) - Basado en Topología 2D (figura E.6) - Basado en Topología 3D (figura E.7)

<<Copiar Figura E.2 traduciendo las notas de arriba abajo como sigue:

Las siguientes clases deberían ser omitidas en cualquier implementación del Perfil Puntual:

LA_BoundaryFaceString;

LA_BoundaryFace

Todavía se pueden usar especializaciones de la clase LA_Point dentro de este perfil, a través de la relación existente con una especialización de LA_SpatialSource. Dichas clases no se representan en

este diagrama.

El siguiente atributo opcional de la clase especializada fue omitido: volumen

El atributo referencePoint ahora no es opcional.

Se asume que se requerirán valores de Área y deberían ser aportados por otras fuentes, concretamente por implementaciones de la clase LA_SpatialSource.>>

Figura E.2 – Basado en un Punto 2D

<<Copiar Figura E.3 traduciendo las notas de arriba abajo y de izquierda a derecha como sigue:

Los siguientes atributos opcionales de la clase especializada han sido omitidos: dimension, label, referencePoint y volume.

Se asume que los valores de Área (y Volumen en el perfil homólogo espacial de un texto 3d) se pueden derivar opcionalmente del dato locationByText, además de ser aportados por otras fuentes,

concretamente por implementaciones de LA_SpatialSource.

La constricción de ejemplo debería aplicarse a todas las operaciones (heredadas de la superclase; y que no se muestran aquí) y no sólo a areaClosed(). Se asume que el operador booleano

isGeomDescription está implementado. Este operador debería verificar cuándo el texto contenido en el atributo locationByText puede ser analizado sintácticamente en la descripción geométrica de

la Unidad Espacial.

El siguiente atributo opcional de la clase especializada fue omitido: geometry.

Los atributos fsIS y locationByText se han hecho obligatorios en este perfil. El atributo fsID es el identificador de un objeto Text_BoundaryFaceString dado. Si los datos en la descripción textual

63

contienen información obligatoria de calidad y linaje, entonces los atributos estimatedAccuracy y productionMethod también se pueden omitir.

La siguiente clase se debería omitir de cualquier implementación de un Perfil Textual: LA_BoundaryFace.

Todavía se pueden usar en este perfil especializaciones de la clase LA_Point, a través de la relación existente con una especialización de LA_SpatialSource. Dichas clases no están representadas en

este diagrama.

Figura E.3 – Basado en un Texto 2D


El siguiente atributo opcional de la clase especializada fue omitido: volume.

Se considera un tipo 2D para objetos BoundaryFaceString (representado geométricamente por GM_MultiCurve) que procede de la definición conceptual de BoundaryFaceString como un conjunto

de caras verticales conectadas definidas a través de un objeto lineal. Si los valores de Área se debieran derivar de BoundaryFaceString (concretamente a través de la operación computeArea()),

entonces este atributo debería ser omitido. No se definen constricciones especiales referentes a las operaciones, por ello no se han mostrado, pero se heredan “tal cuál” de la superclase.

El siguiente atributo opcional de la clase especializada fue omitido: locationByText. Los atributos bfsID y geometry se han hecho obligatorios en este perfil. El atributo bfsID es el identificador de un

Unstructured_Boundary dado. Un único Unstructured_Boundary se puede usar en la representación de múltiples Unidades Espaciales (en contraste con la topología normal donde el

máximo es dos: la unidad espacial izquierda y la unidad espacial derecha).

La siguiente clase debería ser omitida de cualquier implementación de un Perfil sin estructura: LA_BoundaryFace. Todavía se pueden usar en este perfil especializaciones de la clase LA_Point, a

través de la relación existente con una especialización de LA_SpatialSource. Dichas clases no están representadas en este diagrama.

Figura E.4 –Basado en líneas no estructuradas 2D


El Perfil Poligonal está restringido al espacio 2D, y por ello considera solo objetos BoundaryFaceString. Añade una nueva clase especializada Polygon_SpatialUnitGroup, para

representar el área total de una Nación. Esto define que la extensión total está contenida en una partición planar 2D. Se omiten algunos atributos, se utilizan nuevos valores por defecto y se

imponen restricciones en cardinalidades de asociaciones.

Figura E.5 – Basado en Polígonos 2D

64


La siguiente clase debería ser omitida en cualquier implementación de un Perfil Topológico 2D: LA_BoundaryFace. Este es el perfil espacial topológico para 2D. Observe que en la clase

Topological_Level el atributo “structure” se fija en “topological”. En la clase Topological_SpatialUnit el atributo “dimensión” se fija en “2D”, todavía existe opcionalmente el atributo referencePoint. En

la clase Topological_Boundary el atributo “geometry” no es opcional, además no hay atributo “locationByText”. Finalmente, hay un conjunto de constricciones que definen una estructura

topológica válida para una partición planar 2D.

<<Invariant>> {non_intersection: los linderos topológicos no se intersecan y no se encuentran con otros linderos al principio y final}

<<Invariant>> {Todos los linderos topológicos se utilizan una vez en sentido positivo y también sólo una vez en sentido negativo. A menos que el lindero esté en el borde del dominio que sólo se utiliza

una vez en sentido negativo o positivo (y cero el resto de las veces).

<<Invariant>> {Todos los linderos asociados forman uno o más anillos que no se intersecan que definen al menos un anillo externo (con orientación en el sentido de las agujas del reloj) y

opcionalmente uno o más anillos internos (con orientación).}

Figura E.6 – Basado en Topología 2D


Este es el perfil espacial de una estructura topológica 3D pura (por lo tanto en este nivel no hay representaciones 2D ni liminares). No hay volúmenes que se solapen (3D_SpatialUnits). Sin

embargo, los volúmenes pueden estar abiertos por arriba o por abajo, lo que se corresponde con Unidades Espaciales 3D no limitadas (en este caso no se puede calcular el tamaño del volumen). La

siguiente clase debería ser omitida de cualquier implementación de un 3D_ProfileDefinition: LA_BoundaryFaceString.

Este es el perfil espacial topológico para el caso de 3D. Observe que en la clase 3D_Level el atributo structure se ha fijado a “topological”. En la clase 3D_SpatialUnit el atributo dimensión se ha fijado a “3D”, sigue habiendo un atributo opcional referencePoint, que se debería proporcionar a través de

un GM_Point 3D. Finalmente, hay un conjunto de constricciones que definen una estructura topológica válida para una partición volumétrica 3D.

<<Invariant>> {Todas las caras lindero topológicas se utilizan una vez en sentido positivo y también sólo una vez en sentido negativo. A menos que la cara lindero esté en el borde del dominio que sólo

se utiliza una vez en sentido negativo o positivo (y cero el resto de las veces).

<<Invariant>> {non_intersection: las caras lindero no se intersecan (consigo mismas) y no se encuentran con otras caras lindero en sus linderos}

<<Invariant>> {Todas las 3D_BoundaryFaces tienen orientación hacia el exterior (los puntos de los vectores normales hacia fuera). Todas las 3D_BoundaryFaces juntas forman al menos una envoltura

(shell) externa. En principio las envolturas son cerradas, con la excepción de que se pueden abrir (ilimitado) en la dirección de arriba (cielo) o abajo (tierra).}

65

Figura E.7 – Basado en Topología 3D

Anexo F

(informativo)

Perfiles jurídicos

Un perfil jurídico es un perfil con elementos del Paquete Administrativo (apartado 5.4) y del Paquete de Interesados (apartado 5.3). Es este anexo se muestran tres perfiles jurídicos:

- un perfil jurídico para los derechos (figura F.1) - un perfil jurídico para las restricciones (figura F.2) - un perfil jurídico para las responsabilidades (figura F.3).

<<Copiar Figura F.1

Traducir:

Realm of Public Law: Ámbito de la Legislación Pública

Realm of Private Law: Ámbito de la Legislación Privada

Traducir las notas de arriba abajo y de izquierda a derecha:

StateEntity puede ser por lo general la Nación, un Estado o un Municipio. Cada uno tiene propiedad de Dominio Público (PublicDomain_Ownership) en tierras Federales, Estatales o Municipales,

respectivamente.

El valor TimeSpec es sólo un valor inicial (por defecto); podría haber límites de tiempo en la jurisdicción no estudiadas hasta el momento.

No se conocen implementaciones de este tipo abstracto, trabajando como Appurtenance. Se ha mantenido aquí porque podría existir una implementación en algún país, no estudiada hasta el

momento.

La propiedad Comunal podría estar ostentada por otra Propiedad Inmobiliaria (como interesados), y en estos casos se clasifica dentro del Common_Right (Derecho Comunal) bajo la Legislación Privada

(por ejemplo, Reino Unido, Suecia). En países como Portugal, la comunidad local constituye una persona jurídica (nonNaturalPerson una asociación) que ostenta el derecho de Propiedad Comunal (Commons_Ownership). Este tipo de propiedad (Form_of_Property) comparte más similitudes con la Legislación Pública, por eso se ha introducido en el Ámbito de la Legislación Pública, pero puede

tener un régimen jurídico especial.

Se deberían definir clases especializadas para cada país y clasificarlas en cada una de las clases abstractas de arriba. Estos Derechos Inmobiliarios se clasifican normalmente como derechos

derivados o menores de la propiedad. Se debe observar que la clase LA_Right del LADM se asoció únicamente (a través de una especialización) con Derechos en el ámbito de la Legislación Privada,

una vez que el dominio está restringido al Registro de la tierra. Considerando un dominio más amplio, los Derechos otorgados y regulados por la Legislación Pública, también se deberían

considerar como una especialización de LA_Right. >>

66

Figura F.1 – Perfil jurídico para los derechos

<<Copiar Figura F.2 traducir



Y traducir las notas de arriba debajo de la siguiente manera:

No se conocen implementaciones de esta clase abstracta de Encumbrances (cargas). Se dejó en el diagrama porque podrían existir ejemplos de ello en países no estudiados hasta el momento.

Esta clase especializada se representa aquí porque es ampliamente aplicable en el mundo, teniendo el mismo significado conceptual, y estando ya presente en el paquete Administrativo del LADM. >>

Figura F.2 – Perfil jurídico para las restricciones

<<Copiar Figura F.3 traducir



Y traducir las notas de arriba debajo de la siguiente manera:

Arriba: Relaciones conceptuales genéricas para LA_Responsability heredadas como en LA_Right o LA_Restriction.

Abajo y a la derecha: tipos específicos de LA_Responsability en el Ámbito de la Legislación Pública

NOTA: ciertas relaciones de generalización han sido omitidas de este diagrama; chequear con los perfiles de Derechos y Restricciones.

Ejemplo del Derecho Romano: “Collatio Viae”, el impuesto para mantener vías públicas que cruzan o son adyacentes a la propiedad.

Puede resultar de la Constitución, en su forma más alta, o de leyes específicas, como por ejemplo, la Reforma Agraria.

Aviso Importante:

Este diagrama incluye componentes derivados tanto del lado positivo (Perfil LA_Right) como del lado negativo (Perfil LA_Restriction). Los últimos pueden afectar a ambos Ámbitos, el de la

Legislación Privada y el de la Pública. El orden correcto de presentación de los Perfiles Jurídicos es este: (1) Derechos, (2) Restricciones y (3) Responsabilidades. Las responsabilidades específicas en

este Diagrama afectan a los tipos concretos encontrados en la legislación portuguesa. La aplicación a otros países requiere una investigación más profunda.>>

Figura F.3 – Perfil jurídico para las responsabilidades

67

Anexo G (informativo)

El LADM e INSPIRE

Para el acceso transfronterizo a los geo-datos, se está desarrollando un perfil de metadatos europeo basado en las normas internacionales ISO, utilizando las reglas de implementación definidas por la Infraestructura de Datos Espaciales de la Comunidad Europea – INSPIRE [5]. Para el intercambio real de datos, las reglas de implementación de INSPIRE definirán más a fondo especificaciones de datos armonizadas y servicios de red. Esto se complementa con las políticas de acceso a los datos, y la supervisión y presentación de informes del uso de INSPIRE. Las parcelas catastrales son uno de los conjuntos de datos [6] armonizados. Las parcelas catastrales en INSPIRE pueden cumplir la función de ser localizadores de información genéricos para aplicaciones medioambientales, es decir, pueden servir para buscar y enlazar otra información espacial.

La Directiva INSPIRE requiere tener en cuenta las normas existentes (artículo 7 de la Directiva). La Norma ISO 19152 puede ser tomada en cuenta cuando hay una necesidad y un consenso de extender la Especificación de Datos de parcelas catastrales. Se presentó una excelente oportunidad de alinear el LADM con las parcelas catastrales de INSPIRE, al desarrollarse ambas al mismo tiempo. Lo que se ha conseguido mediante un trabajo conjunto entre el Grupo de Trabajo Temático de Parcelas Catastrales de INSPIRE (TWG CP) y el equipo de proyecto del LADM. Esto asegura la consistencia entre INSPIRE y el LADM, y resultó en una correspondencia de conceptos y en definiciones compatibles de los conceptos comunes. Por supuesto, se debería recordar que hay diferencias en el objeto y en las áreas de aplicación de este, por ejemplo, INSPIRE está fuertemente enfocado a usuarios medioambientales, mientras que el LADM tiene un carácter multipropósito (admitiendo seguridad jurídica, tributación, valoración, planeamiento, etc.) y permitiendo tanto productores de datos, como usuarios de datos en sus diversas áreas de aplicación. Además, el LADM tiene soluciones armonizadas para los derechos y los propietarios de objetos catastrales 3D (tales como unidades de edificación o redes de servicios), que actualmente están fuera del campo de aplicación de INSPIRE CP. Sin embargo, gracias a esta intensa colaboración, ahora es posible para un país europeo ser conforme con ambas, INSPIRE y el LADM. Además, ahora es posible extender las especificaciones de INPIRE usando el LADM, si hay necesidad y consenso de hacerlo.

Con el objetivo de “demostrar” la compatibilidad, la figura G.1 muestra la versión de las parcelas catastrales de INPIRE basadas en el LADM, indicando explícitamente cómo encaja el desarrollo de INPIRE dentro del LADM y que no hay inconsistencias. Ha sido posible expresar el conjunto de datos de parcelas catastrales de INSPIRE basado en el LADM, seleccionando clases relevantes del LADM, usando herencias, añadiendo atributos y constricciones.

En el contexto de INPIRE hay cuatro clases relevantes: - LA_SpatialUnit (con alias LA_Parcel) como base para las CadastralParcel (parcelas catastrales); - LA_BAUnit como base para BasicPropertyUnit (unidad de propiedad básica); - LA_BoundaryFaceString como base para CadastralBoundary (linderos catastrales); - LA_SpatialUnitGroup como base para CadastralZoning (zonas catastrales);

Los atributos del LADM heredados por INSPIRE pueden tener en INSPIRE un tipo de datos o cardinalidad más específico (en comparación con el LADM). Esto se ha incluido en el diagrama. Esto implica que un atributo opcional del LADM [0..1], podría no ocurrir en INSPIRE ya que la cardinalidad puede estar a 0, por ejemplo, nationalVolume. Esto también implica que un atributo opcional del LADM [0..1], podría ser

68

un atributo obligatorio en INSPIRE, por ejemplo, label. Además se añaden atributos específicos INSPIRE a las diferentes clases. La figura G.1 parece un poco más complicada que los diagramas normales de clases INSPIRE CP UML, porque está mostrando las diferentes clases padre del LADM y el refinamiento de los diferentes tipos de atributos (pero el modelo resultante es el mismo).

Es preciso señalar que el campo de aplicación actual de las parcelas catastrales INSPIRE es más limitado que el LADM, por ejemplo, no incluye derechos, restricciones y responsabilidades.

<<Copiar la figura G.1 como la original traduciendo la nota de la siguiente manera:

Los atributos del LADM heredados por INSPIRE pueden tener en INSPIRE un tipo de datos o cardinalidad más específico (en comparación con el LADM). Esto se ha incluido en el

diagrama. Esto implica que un atributo opcional del LADM [0..1], podría no ocurrir en INSPIRE ya que la cardinalidad puede estar a 0, por ejemplo, nationalVolume. Esto también

implica que un atributo opcional del LADM [0..1], podría ser un atributo obligatorio en INSPIRE, por ejemplo, label. >>

Figura G.1 – El modelo de parcelas catastrales de INSPIRE basado en el LADM

Anexo H (informativo)

El LADM y el LPIS

H.1 Integración del LADM con los Sistemas Europeos de Identificación de Parcelas Terrestres (Land Parcel Identification Systems - LPIS)

Uno de los aspectos de la Política Agrícola Común (Common Agricultural Policy – CAP) de la Unión Europea es centrarse en la gestión de los subsidios agrarios. Para este propósito, los estados miembros han establecido Sistemas Integrados de Administración y Control (Integrated Administration and Control Systems – IACS), incluyendo como componente geoespacial los Sistemas de Identificación de Parcelas Terrestres (LPIS). El LPIS como concepto, ya se desarrolló en 1992, cuando surgió la necesidad de identificar parcelas agrarias como soporte de los IACS. En ese momento, el modelo de datos era puramente alfanumérico sin ninguna referencia geoespacial. En el Reglamento nº 1593 (2000) del Consejo se promovieron los LPIS basados en Sistemas de Información Geográfica (SIG). Se dieron cinco años a los estados miembros para establecer los LPIS en formato digital y georreferenciados. Por lo tanto, el primer año de los LPIS operativos basados en SIG fue el 2005. Aunque los requisitos reglamentarios fueron únicos en todo el sector, lo particular de cada implementación fue asunto de los estados miembros. De hecho, durante las fases de desarrollo de los diferentes LPIS en los diferentes estados miembros, el uso de datos de Administración del Territorio (LA, o Catastro), así como los datos topográficos de escalas grandes, estuvieron en el orden del día por un tiempo considerable [23]. En el siguiente ejemplo, se ha diseñado un modelo de datos que implica la colaboración o integración del LADM y del LPIS. En este ejemplo se utiliza la iniciativa de estandarización en el área de LPIS [20],[3] del Joint Research Centre (JRC) de la Comisión Europea, con el objetivo de representar el potencial de integración/colaboración entre el LADM y los LPIS.

<<Copiar la figura H.1 como la original >>

Figura H.1 – Tipos de parcelas de referencia

69

Una parcela agraria declarada es un concepto clave aplicado en relación a los pagos basados en el área, que determina el objeto de la solicitud de ayuda, la localización geográfica y la extensión (área) de la actividad agraria. La parcela agraria declarada es objeto de cálculo del pago, así como de control administrativo. Debido a la naturaleza dinámica de las actividades agrarias, las parcelas agrícolas declaradas pueden cambiar a lo largo del tiempo y del espacio (rotación de cultivos, fuera de uso, agregación y subdivisión del terreno, diferentes extensiones de uso o condiciones de idoneidad de los pagos). Por lo tanto, la parcela de referencia (Reference Parcel - RP) se utiliza como unidad básica del LPIS con el propósito de identificar las parcelas agrarias declaradas, donde una RP puede contener una o muchas (1..*) parcelas agrarias declaradas. Las regulaciones de la UE especifican que las parcelas de referencia pueden ser parcelas catastrales o bien bloques de producción (véase la figura H.1). Al final, algunos estados miembros decidieron construir sus sistemas lo más parecidos posibles a la práctica agraria declarada, y usar unidades de referencia, las cuales contienen solo una parcela agraria espacial.

Las principales dificultades de la parcela catastral como referencia para las solicitudes de subsidio son que:

i) contiene tierras no-agrarias, por lo que el área idónea para el pago no se puede determinar directamente, y

ii) Los límites de la actividad agraria quedan fuera del campo de aplicación de los LA, y su mantenimiento por medio del ciclo de actualización del catastro es muy complicado.

Por eso, en el capítulo H.2 se introduce el concepto de SubParcel (subparcela), que desempeña el papel de parcela de referencia (y hace de unión entre el LADM y el LPIS).

H.2 Un modelo de datos para la integración del LADM y los LPIS

H.2.1 General

En los diagramas de clases UML se utilizan las clases actuales del LADM, con o sin pequeños cambios en sus atributos, o extendiéndose con nuevas clases.

H.2.2 Elementos básicos del Modelo Esencial del LPIS (LPIS Core Model – LCM)

El Modelo Esencial del LPIS (LCM) ha sido desarrollado por la unidad Agraria del Joint Research Centre (JRC) de la CE. La intención de este modelo es extraer clases generales para sistemas LPIS funcionales, y probar su conformidad con las Regulaciones de la UE; por lo tanto, el modelo esencial no cubre todos los aspectos de un LPIS. Los expertos de los Estados Miembros podrían extender los límites del LCM para cumplir las necesidades particulares de las implementaciones nacionales. La figura H.2 representa el modelo de negocio lógico de los principales conceptos del LCM. Todos los conceptos básicos se representan como clases.


Figura H.2 – Clases esenciales del LCM

H.2.3 Integración del LCM y las clases básicas del LADM

H.2.3.1 Clases espaciales

La clase LA_SpatialUnit es una de las clases básicas del LADM. El LADM también proporciona funcionalidad para la agrupación administrativa de unidades espaciales con la clase LA_BAUnit, a través

70

de la que se relacionan los hechos jurídicos (derechos, restricciones y responsabilidades en la clase LA_RRR). Las clases especializadas de LA_SpatialUnit están fuera del campo de aplicación de la integración del LADM y el LPIS (LA_LegalSpaceBuildingUnit y LA_LegalSpaceUtilityNetwork), tal como la agrupación jerárquica en agrupaciones de unidades espaciales (secciones, municipios, etc.); véase la figura H.3. Para una significativa clasificación del territorio comparable y normalizada, al menos para el caso de las parcelas catastrales como parcelas de referencia agraria, se ha diseñado en el modelo la clase SubParcel como una parte de las parcelas catastrales. La clase SubParcel tiene una asociación de composición con la clase LA_SpatialUnit. En la clase SubParcel, el atributo typeSubParcel está diseñado para almacenar diferentes tipos de SubParcel. Estos se definen en la lista de códigos SubParcelType (véase la figura H.3). Una consideración importante es que los límites de las clases definidas son estables a lo largo del tiempo. De otra manera, los procedimientos de actualización y mantenimiento serían una carga.


Figura H.3 – Clases espaciales para la colaboración del LADM – IACS/LPIS

H.2.3.2 Clases administrativas

LA_Party, Farmer, Right/Restriction/Responsibility (LA_RRR), YearlyAidApplication, YearlyFarmerSketch, DeclaredAgriParcel son las clases básicas diseñadas para gestionar los datos administrativos en el modelo (véase la figura H.4). LA_Party y LA_RRR son dos clases básicas que vienen del LADM. Las otras clases están diseñadas para la descripción de los datos administrativos del LPIS.


Figura H.4 – Clases administrativas para la integración del LADM – IACS/LPIS

La clase Farmer está diseñada como una especialización de la clase LA_Party con el objetivo de manejar atributos específicos de los agricultores. Los agricultores pueden solicitar subsidios agrarios cada año. Para manejar la información de la solicitud de los agricultores, se ha diseñado la clase YearlyAidApplication. Las solicitudes de ayuda remitidas por los agricultores deberían estar acompañadas por declaraciones que describan cada parte del terreno utilizada por los agricultores para actividades agrarias y por un boceto del agricultor. Por lo tanto, hay dos clases correspondientes (DeclaredAgriParcel y YearlyFarmerSketch) que componen la clase YearlyAidApplication (una fuente) en el modelo. Para representar sus derechos de subsidio, se introduce en el modelo la clase PaymentEntitlement. En el boceto, que los agricultores deberían proporcionar junto con sus solicitudes, indicarán los límites de sus parcelas agrarias. Pueden usar una parcela agraria única o muchas. Pueden dibujar los límites de sus tierras en bocetos separados para cada parte de terreno. También es posible la agrupación, dependiendo de la localización y de la escala del boceto. Las solicitudes de ayuda remitidas por los agricultores deberían estar acompañadas por declaraciones de los agricultores, que describan cada parte de terreno utilizada por el agricultor para actividades agrarias. Las declaraciones de los agricultores se representan en el modelo con DeclaredAgriParcel. Se ha diseñado como parte de la clase YearlyAidApplication porque esta clase no puede existir sin alguna solicitud de ayuda.

H.3 Consideraciones especiales para la integración del LADM y el LPIS

En el artículo dos del Reglamento Nº 1782/2003 de la CE se define agricultor como una persona física o jurídica o un grupo de personas físicas o jurídicas. Esta definición de persona se puede representar por

71

la clase LA_Party diseñada para el LADM. En la figura H.5, LA_Party es la clase principal, que representa a personas físicas y jurídicas, y también a grupos de personas físicas y jurídicas mediante la clase LA_GroupParty. Así, las clases de personas del LADM tienen la funcionalidad de representar a los agricultores como cualquier tipo de personas. Sin embargo, se ha diseñado una nueva clase Farmer para representar los atributos que son sólo específicos de los agricultores. Uno es farmerID, que indica que la persona es un agricultor. Otro es farmerAddress, que incluye la información de la dirección postal actualizada.


Figura H.5 – Clases de personas: LA_Party, LA_GroupParty y Farmer


Figura H.6 – Asociaciones de derechos y restricciones con la clase DeclaredAgriParcel

En el LADM, la clase LA_RRR tiene tres tipos principales de clases de especialización: LA_Right, LA_Restriction y LA_Responsability. En el modelo de colaboración para la integración del LPIS, los derechos agrarios se representan por la clase LA_Right y algunas de las limitaciones agrarias se representan por la clase FarmingLimitation que es una especialización de la clase LA_Restriction (véase la figura H.6). El único derecho de IACS/LIPS es el derecho a ser pagado (subsidio). Se asocia con Farmer y con Subparcel vía YearlyAidApplication y DeclaredAgriParcel. No se relaciona directamente con LA_SpatialUnit.

H.4 Discusión

Este anexo muestra que se pueden usar diferentes aspectos del LADM en la integración de diferentes configuraciones de LPIS en diferentes estados miembros de la Unión Europea. No se mencionan aquí otros aspectos importantes, pero se pueden encontrar en Inan et al [4].

Ha habido un entendimiento común sobre que el LPIS trata de agricultores (usuarios del terreno) y el sistema LA/Catastro trata sobre los propietarios y ellos no pueden ser la misma persona. A diferencia de esto, los sistemas LA, por definición, tratan un rango amplio de información relacionada con el terreno incluyendo la propiedad, los derechos de uso del terreno (titulares de un derecho real sobre propiedades), derechos agrarios, restricciones, responsabilidades, etc. También podemos llamar a este tipo de sistema LA un catastro multipropósito. Sin embargo, es un hecho que los sistemas LA convencionales al ser sistemas preexistentes, actualmente no son siempre capaces de administrar todos los tipos de derechos relacionados con el terreno. Esta es la razón por la que los sistemas LA generalmente están subestimados por terceras partes. Por lo tanto, se ha considerado el registro de agricultores y derechos agrarios en un sistema LA como un obstáculo cuando se compara con el LPIS. De hecho, un agricultor es una persona que realiza un tipo de actividad agraria en un parte del terreno. Los agricultores pueden poseer los terrenos para sus actividades. Ellos pueden alquilar o conseguir algún tipo de consentimiento de otros sobre otra parte de terreno.


Figura H.7 – Registro de derechos agrarios con clases del LADM

72

En este ejemplo, se han diseñado los derechos agrarios como parte de un sistema LA extendiendo un poco las listas de códigos (LA_RightType y LA_AdministrativeSourceType) con valores de atributos para los atributos de algunas de las clases del LADM (véase la figura H.7). La idea es que esto permitirá a la aplicación de una solución integrada la gestión de los derechos sobre el uso del terreno, tanto para sistemas LA como para aplicaciones LPIS.

Con el objetivo de intentar diseñar y probar adecuadamente el modelo presentado arriba, se tienen que elaborar modelos de casos de uso (desde el punto de vista empresarial y de sistemas), incluyendo diagramas de actividades de los procesos y flujos de trabajo.

Anexo I

(informativo)

Modelo para el Ámbito de la Tenencia Social (Social Tenure Domain Model - STDM)

El STDM es una iniciativa de UN-HABITAT para apoyar la administración del territorio a favor de los pobres [26]. El STDM está dirigido específicamente para países en desarrollo, países con muy poca cobertura catastral en áreas urbanas o rurales. También está dirigido a áreas después de un conflicto, áreas con asentamientos improvisados de gran escala o a áreas ancestrales de gran escala. El STDM se ha centrado en las relaciones entre las personas y el terreno, independientemente de la formalización o legalidad de esas relaciones. Se busca un modelo que soporte todas las formas de derechos del terreno, las relaciones de tenencia social y la superposición de reclamaciones del terreno [29], [2]. Se debería enfatizar que el STDM es también un modelo conceptual y no un modelo de aplicación. Además ambos, el STDM y el LADM, son descriptivos y no prescriptivos. Ambos proporcionan lenguajes formales para describir los muchos aspectos de la tenencia social, de esta manera se pueden entender mejor las similitudes y diferencias entre los diferentes sistemas LA. El propósito es que el LADM contribuya a un mejor entendimiento de los muchos aspectos de la tenencia social.

Tabla I.1 – Nombres de las clases del LADM con sus alias en el STDM

Nombre de las clases del LADM Alias en el STDM <<copiar igual que el original>> <<copiar la tabla igual que la original, salvo

“identical name” que se debe de traducir por “nombre idéntico.”>>

El LADM proviene de áreas con catastro formal y sistemas de registro de tierras. Se observa que el STDM contiene la mayoría de la funcionalidad del LADM, pero a veces bajo diferente terminología. La terminología formal utilizada en el LADM no siempre se puede aplicar por lo no formalizado del entorno. En el STDM se utilizan la mayoría de las clases iguales que en el LADM, pero a veces con diferente terminología, por ejemplo, la clase RRR se llama SocialTenureRelationship (véase la tabla I.1).

EJEMPLO 1 Los derechos reales de garantías (Collateral) se muestran en diagramas de instancias, véase la figura C.27

73

EJEMPLO 2 Las parcelas (alias de unidades espaciales, véase la figura 5) se muestran en diagramas de instancias, véase la figura C.2.

EJEMPLO 3 Las relaciones con el STDM se muestran en diagramas de instancias, véanse las figuras C.2, C.12, C.13, C.14 y C.27.

Anexo J

(informativo)

Listas de códigos

Las listas de códigos se utilizan para describir enumeraciones más abiertas y flexibles. Las listas de códigos son útiles para especificar una lista larga de valores potenciales. Las listas de códigos incluidas en el LADM aspiran a permitir el uso de terminología local, regional o nacional. Las comunidades de usuarios tienen que definir y gestionar sus propios valores cuando implementen esta norma internacional. Las figuras desde la J.1 a la J.4 muestran posibles ejemplos de valores de estas listas de códigos.

<<Copiar la figura J.1 como la original >>

Figura J.1 – Listas de códigos para el Paquete de Interesados


Figura J.2 – Listas de códigos para el Paquete Administrativo


Figura J.3 – Listas de códigos para el Paquete de Unidades Espaciales


Figura J.4 – Listas de códigos para el Subpaquete de Topografía y Representación

Anexo K

(informativo)

Clases externas

K.1 Introducción

La construcción de bases de datos externas con datos de los interesados, las direcciones, los impuestos, los usos del suelo, las coberturas del suelo, la valoración, la red física de servicios y los archivos, queda fuera del campo de aplicación del LADM. Sin embargo, el LADM proporciona clases estereotipadas para estos conjuntos de datos, que indican qué elementos del conjunto de datos espera el LADM para estas fuentes externas, si están disponibles.

<<Copiar la figura K.1 como la original >>

74

Figura K.1 – Clases externas del LADM

K.2 ExtParty

La clase ExtParty es una clase para el registro externo de interesados, véase la figura K.1.

Los atributos de la clase ExtParty son:

- extAddressID: el identificador, que apunta a la dirección postal externa; - fingerprint: la huella del interesado externo; - name: el nombre del interesado externo; - partyID: el identificador del interesado externo; - photo: la foto del interesado externo; - signature: la firma del interesado externo.

K.3 ExtAddress

La clase ExtAddress es una clase para el registro externo de direcciones postales (una dirección para encontrar una ubicación), véase la figura K.1.

Los atributos de la clase ExtAddress son:

- addressAreaName: el nombre del área de la dirección postal externa; - addressCoordinate: las coordenadas de la dirección postal externa; - addressID: el identificador de la dirección postal externa; - buildingName: el nombre del edificio de la dirección postal externa; - buildingNumber: el número del edificio de la dirección postal externa; - city: la ciudad de la dirección postal externa; - country: el país de la dirección postal externa; - postalCode: el código postal de la dirección postal externa; - postBox: el buzón de la dirección postal externa; - state: el estado de la dirección postal externa; - streetName: el nombre de la calle de la dirección postal externa.

NOTA También se pueden usar las especificaciones de direcciones de INSPIRE.

K.4 ExtTaxation

La clase ExtTaxation es una clase para el registro externo de datos del impuesto. La clase ExtTaxation está asociada con la clase LA_BAUnit, véase la figura K.1.

Los atributos de la clase ExtTaxation son:

- amount: importe del impuesto; - taxDate: la fecha del impuesto; - taxType: el tipo de impuesto.

EJEMPLO La fecha de impuesto se muestra en diagramas de instancias, véase la figura C.18.

K.5 ExtLandUse

75

La clase ExtLandUse es una clase para el registro externo de datos de uso del suelo; el uso del suelo es un acuerdo, actividad o una contribución que las personas realizan en ciertos tipos de coberturas del suelo, para producirlas, cambiarlas o mantenerlas. La clase ExtLandUse está asociada con la clase LA_SpatialUnit, véase la figura K.1.

El atributo de la clase ExtLandUse es:

- type: el tipo de uso del suelo.

K.6 ExtLandCover

La clase ExtLandCover es una clase para el registro externo de datos de cobertura del suelo; la cobertura del suelo es la cobertura (bio) física observada en la superficie de la Tierra. La clase ExtLandCover está asociada con la clase LA_SpatialUnit, véase la figura K.1.

El atributo de la clase ExtLandCover es:

- type: el tipo de cobertura del suelo.

K.7 ExtValuation

La clase ExtValuation es una clase para el registro externo de datos de valoraciones. La clase ExtValuation está asociada con la clase LA_BAUnit, véase la figura K.1.

Los atributos de la clase ExtValuation son:

- value: el valor de la valoración; - valueDate: la fecha de la valoración; - valueType: el tipo de valoración.

EJEMPLO Los datos de valoración se muestran en diagramas de instancias, véase la figura C.18.

K.8 ExtPhysicalUtilityNetwork

La clase ExtPhysicalUtilityNetwork es una clase para el registro externo de datos cartográficos de redes de servicios. La clase ExtPhysicalUtilityNetwork está asociada con la clase LA_LegalSpaceUtilityNetwork, véase la figura K.1.

Los atributos de la clase ExtPhysicalUtilityNetwork son:

- directed: la dirección de flujo, fija o no; - managerID: la organización responsable de la red de servicios;

K.9 ExtPhysicalBuildingUnit

La clase ExtPhysicalBuildingUnit es una clase para el registro externo de datos cartográficos de unidades de edificación. La clase ExtPhysicalBuildingUnit está asociada con la clase LA_LegalSpaceUtilityNetwork, véase la figura K.1.

El atributo de la clase ExtPhysicalBuildingUnit es:

- extAddressID: el identificador, que apunta a la dirección postal externa.

76

K.10 ExtArchive

La clase ExtArchive es una clase para el registro externo de fuentes, véase la figura K.1.

Los atributos de la clase ExtArchive son:

- acceptance: la fecha de vigencia de la ley de la fuente por una autoridad; - data: el contenido de la fuente; - extraction: la fecha en que se consultó la fuente; - recordation: la fecha del registro (grabación) de la fuente por la autoridad registradora; - sID: el identificador de la fuente; - submission: la fecha de presentación de la fuente por un interesado.

K.11 Listas de códigos para las clases externas

La figura K.2 muestra las listas de códigos para las clases externas.

<<Copiar la figura K.2 como la original >>

Figura K.2 – Las listas de códigos del LADM para las clases externas

Anexo L

(informativo)

Clases interfaz

En el LADM se pueden añadir clases interfaz para permitir la generación y gestión de productos y servicios. Estas clases interfaz se consideran definidas por el usuario y quedan fuera del campo de aplicación del LADM. Sin embargo, se muestran tres clases interfaz para ilustrar el concepto de clase interfaz, para interesados (véase la figura L.1), para unidades espaciales (véase la figura L.2) y para mapas con unidades espaciales, por ejemplo, mapas catastrales (véase la figura L.3).

<<Copiar la figura L.1 como la original traduciendo la nota:

LA_PartyPortofolio es una clase interfaz que contiene una vista general (en una fecha folioDate) de toda la información relevante que concierne a las instancias de LA_RRR,

LA_BAUnit y LA_SpatialUnit para un interesado específico. Como es una clase interfaz, es más una vista de datos agregados de otras clases que el contenedor de los datos reales en

sí mismos. >>

Figura L.1 – Clase interfaz para interesados


77

LA_SpatialUnitOverview es una clase interfaz que contiene una vista general (en una fecha overviewDate) de toda la información relevante que concierne a las instancias de

LA_BAUnit, LA_RRR y LA_Party para una unidad espacial específica. Como es una clase interfaz, es más una vista de datos agregados de otras clases que el contenedor de los

datos reales en sí mismos. >>

Figura L.2 – Clase interfaz para unidades espaciales


LA_RegionMap es una clase interfaz que una representación cartográfica (en una fecha mapDate) de toda la información relevante que concierne a las unidades espaciales en una

región dada de los niveles específicos (lId). Si no se especifica nivel, entonces todas las unidades espaciales están contenidas en el mapa. Como es una clase interfaz, es más una

vista de datos agregados de otras clases que el contenedor de los datos reales en sí mismos. >>

Figura L.3 – Clase interfaz para cartografiar unidades espaciales

Anexo M

(informativo)

Modelado de procesos de administración del territorio

Además del modelado de los datos de los procesos dinámicos, el LADM proporciona soporte para investigar cómo se relacionan entre sí las funciones y los procesos. Por lo tanto, los diagramas de clases UML se completarán por los usuarios finales con diagramas de estados (diagramas de casos de uso, diagramas de secuencias, diagramas de colaboraciones, diagramas de estados o diagramas de actividades), cubriendo otros aspectos. Los diagramas de actividades muestran cómo se relacionan los procesos con la información (datos) y cómo es el “flujo” de uno a otro. En el resto de tipos de diagramas UML, los actores u organizaciones ejercen un papel importante y éste puede ser dependiente de acuerdos (nacionales). La introducción de diferentes “fases” de una unidad espacial (punto, imagen, levantamiento), de un derecho (inicio, tenencia, propiedad) o de un interesado, reflejan, además, la naturaleza dinámica del sistema.

Anexo N

(informativo)

Historia y aspectos dinámicos

Se utilizan dos visiones para modelar el resultado de los sistemas dinámicos (cambios discretos en el estado del sistema);

1) Modelado basado en eventos. En el modelado basado en eventos, las transacciones se modelan como entidades separadas dentro del sistema (con su propia identidad y conjunto de atributos). El evento se representa por medio de una instancia de LA_Source. Cuando se

78

conoce el estado inicial, y todos los eventos, es posible reconstruir cada estado del pasado invirtiendo toda la cadena de eventos. También es posible representar el estado actual y no guardar el estado inicial (y volver hacia atrás en el tiempo por medio de los eventos “inversos”). Para tener un soporte total del modelado basado en eventos, se deberían describir los modelos de procesos relacionados (lo que queda fuera del campo de aplicación de esta norma internacional).

2) Modelado basado en estados. En el modelado basado en estados, los estados (es decir, los resultados) se modelan explícitamente: cada objeto tiene asignadas (al menos) dos fechas/horas que indican el intervalo de tiempo durante el cual el objeto se graba en el sistema como versión real. Mediante la comparación de dos estados sucesivos es posible reconstruir que pasó como resultado de un evento. Obtener el estado en un momento dado es directo, mediante la selección del objeto en función del intervalo de tiempo (tmin-tmax). El aspecto temporal se hereda de la clase VersionedObject con sus atributos beginLifespanVersion y endLifespanVersion. La clase LA_RRR tiene un atributo temporal adicional llamado timeSpec, que es capaz de manejar otras representaciones temporales, tal como un patrón recurrente (cada fin de semana, cada verano, etc.). Conviene observar que la mayoría de los objetos heredan los atributos temporales por medio de LA_Party, LA_RRR, LA_BAUnit o LA_SpatialUnit – o directamente por medio de la clase Versioned Object.

El LADM cubre ambos modelados, el basado en eventos (por medio de la clase LA_Source) y el basado en estados (por medio de la clase VersionedObject). Además del modelado basado en eventos y en estados, también es posible hacer asociaciones explícitas padre-hijo entre las unidades espaciales modeladas (linaje), por ejemplo, cuando una unidad espacial se subdivide. Sin embargo, como estas asociaciones también se pueden derivar mediante una superposición espacio-temporal, el LADM no se ha hecho más complicado con estas relaciones explícitas padre-hijo.

79

Anexo O

(informativo)

El LADM y otras normas internacionales ISO/TC211

En este anexo se explican una serie de conceptos y clases de otras normas internacionales ISO de información geográfica (tal y como se usan en esta norma internacional), por ejemplo, GM_Point de la Norma ISO 19107, Sistemas de Referencia de Coordenadas de la Norma ISO 19111, OM_Observation de la Norma ISO 19156 y DQ_Element de la Norma ISO 19115. La clase GM_Point a simple vista puede parecer simple, pero es el principio de gran parte del modelo donde está disponible la funcionalidad relevante del LA; incluyendo el soporte de los Sistemas de Referencia de Coordenadas (SRC) embebidos. GM_Point en sí mismo es un tipo (clase) que hereda de la clase abstracta GM_Primitive, que a su vez hereda de la clase abstracta GM_Object, véase la figura O.1. De estas tres clases solo la clase GM_Point tiene un atributo del tipo (clase) DirectPosition. Las tres clases definen varias operaciones (genéricas). La clase DirectPosition tiene un atributo llamado coordinate del tipo Sequence<Number> y un atributo derivado llamado dimension de tipo Integer. Ambos, GM_Object y DirectPosition tienen una asociación con la clase SC_CRS (Sistema de Referencia de Coordenadas) como se define en la Norma ISO 19111. Ambas asociaciones tiene multiplicidad 0..1 en el lado del SC_CRS.

<<Copiar la figura O.1 como la original >>

Figura O.1 – GM_Point en sí mismo es un tipo (clase) que hereda de la clase abstracta GM_Primitive, que a su vez hereda de la clase abstracta GM_Object

La clase abstracta SC_CRS (Sistema de Referencia de Coordenadas) tiene dos especializaciones: la clase SC_SingleCRS (también abstracta, con varias subclases concretas, por ejemplo, SC_VerticalCRS, SC_GeodeticCRS, SC_ProjectedCRS) y la clase SC_CompoundCRS (abstracta, agregación de SC_SingleCRS), véase la figura O.2. Una clase SC_SingleCRS está asociada con un CS_CoordinateSystem, que tiene a su vez uno o más CS_CoordinateSystemAxis, véase la figura O.3. En resumen, GM_Point y SC_CRS son parte de uno modelo que no es trivial, que debería ser capaz de proporcionar toda la funcionalidad necesaria en el contexto del LADM y del Levantamiento (Survey), permitiendo varios sistemas de coordenadas y transformaciones.


Figura O.2 – La clase abstracta SC_CRS (Sistema de Referencia de Coordenadas) de la Norma ISO 19111


Figura O.3 – Clase SC_CoordinateSystem (de la Norma ISO 19111)

Otra norma internacional ISO de información geográfica utilizada en esta norma internacional es la Norma ISO 19156. La fuente de datos del levantamiento se modela y almacena en la clase LA_SpatialSource. El atributo “measurements” es del tipo OM_Observation (tal y como se define en la Norma ISO 19156) y contiene los datos reales de la fuente del levantamiento. El atributo “procedure” es del tipo OM_Process1) y documenta el procedimiento real del levantamiento. La clase OM_Observation,

80

contiene, además de los datos del levantamiento, los atributos para documentar los aspectos temporales y de calidad del levantamiento; véase la figura O.4.


Figura O.4 – Clase OM_Observation (de la Norma ISO 19156, obsérvese que TM_Instant y TM_Period son ambas de la Norma ISO 19108)

La clase LA_Point hereda de la clase abstracta VersionedObject. Además de atributos temporales, también proporciona atributos de calidad (quality de tipo DQ_Element) y de la fuente (source de tipo CI_ResponsibleParty, esta es la organización responsable de una versión específica de una instancia en la base de datos). El atributo de calidad tiene multiplicidad 0..* y así se pueden representar los diferentes aspectos de calidad modelados por medio de DQ_Element. DQ_Element es una clase de la Norma ISO 19115:2003. Es una clase abstracta con las siguientes subclases: DQ_Completeness, DQ_LogicalConsistency, DQ_ThematicAccuracy y DQ_PositionalAccuracy, véase la figura O.5. El atributo source (fuente) también tiene multiplicidad 0..* y la clase CI_ResponsibleParty también procede de la Norma ISO 19115:2003. Además de diversos nombres (del individuo, de la organización, del cargo), también se modelan el rol y la información de contacto del responsable, véase la figura O.6.


Figura O.5 – Clase DQ_Element (de la Norma ISO 19115)


Figura O.6 – Clase CI_ResponsibleParty (de la Norma ISO 19115)