Caso de estudio: seguimiento de la actualización catastral

📎 Presentación: SeguimientoActualizacionCatastral.pptx · PDF

Antes de escribir código conviene ver para qué sirve todo esto en un sistema real. La presentación describe una aplicación web para el seguimiento del proceso de actualización catastral: una plataforma que acompaña a una entidad territorial desde que define un proyecto de actualización hasta que verifica sus entregables y la retroalimentación ciudadana.

El objetivo de esta página es leer la presentación como un arquitecto frontend: identificar qué pantallas, rutas, componentes y servicios aparecerían si la construyéramos en Angular.

---

1. La idea central

La aplicación gira alrededor de un eje —la actualización catastral— y lo aborda desde tres frentes:

Frente	Qué permite	Pregunta que responde
Ejecución de flujos	Gestionar y ejecutar los flujos de trabajo definidos	¿Qué hay que hacer y quién lo está haciendo?
Seguimiento administrativo	Controlar y monitorear el estado de los procesos	¿Cómo vamos?
Configuración de información	Definir y administrar la información usada en los procesos	¿Con qué reglas trabajamos?

La aplicación conecta operación, seguimiento y configuración alrededor del objetivo central.

Estos tres frentes son, casi literalmente, tres áreas funcionales de la SPA. En Angular se traducen en tres grupos de rutas (ver Routing).

2. Ejecución y seguimiento de flujos

El flujo operativo convierte una necesidad de actualización en una ejecución controlable, en tres pasos:

1. Crear proyectos — definición del proyecto de actualización y sus parámetros de trabajo.
2. Crear áreas de interés — delimitación de áreas geográficas o temáticas dentro del proyecto.
3. Seguimiento de ejecuciones — consulta del avance, estado y trazabilidad por área.

Los indicadores del flujo son avance, estado y trazabilidad.

Fíjate en la relación entre los pasos: un proyecto tiene muchas áreas, y cada área tiene muchas ejecuciones. Esa jerarquía aparece en el modelo de datos, en las rutas y en la composición de componentes.

3. Seguimiento administrativo

Visión integral de la cartera de proyectos, apoyada en cuatro herramientas:

• Tableros Power BI — evolución de los proyectos activos y estado de la cartera.
• Verificación ArcGIS — control de versión de las capas y entregables geográficos.
• Interacción ciudadana — seguimiento a las marcas y retroalimentación del ciudadano.
• Búsqueda de predios — localizar predios y apoyar la gestión territorial.

Aquí la SPA no lo hace todo sola: integra servicios externos (tableros embebidos, servicios de mapas). Es un ejemplo de por qué el frontend habla con varias APIs y no solo con el backend propio.

4. Configuración de información

Convierte criterios en capacidades reutilizables:

• Calidad y validación — inventario de reglas para identificar marcas e inconsistencias.
• Validación documental — gestión de revisiones documentales con trazabilidad y soporte normativo.
• Actualización ciudadana — validaciones aplicadas a reportes ciudadanos.

Estas pantallas son, en su mayoría, CRUD con formularios y validación: el terreno de Formularios.

---

De la presentación a Angular

Modelos (ver Modelos)

export interface Proyecto {
  id: number;
  nombre: string;
  municipio: string;
  fechaInicio: string;            // ISO 8601, tal como llega en el JSON
  estado: 'BORRADOR' | 'EN_EJECUCION' | 'FINALIZADO';
}

export interface AreaInteres {
  id: number;
  proyectoId: number;
  nombre: string;
  tipo: 'GEOGRAFICA' | 'TEMATICA';
}

export interface Ejecucion {
  id: number;
  areaId: number;
  avance: number;                 // 0 – 100
  estado: 'PENDIENTE' | 'EN_CURSO' | 'COMPLETADA' | 'CON_HALLAZGOS';
  actualizadaEn: string;
}

Cada interfaz es el espejo del DTO que expone el backend (ver DTO).

Rutas (ver Routing)

/                                   → redirige a /proyectos
/proyectos                          → listado de proyectos
/proyectos/nuevo                    → formulario de creación
/proyectos/:id                      → detalle del proyecto
/proyectos/:id/areas                → áreas de interés del proyecto
/proyectos/:id/areas/:areaId        → ejecuciones del área (avance, estado, trazabilidad)
/seguimiento                        → tableros, verificación de capas, interacción ciudadana
/seguimiento/predios                → búsqueda de predios
/configuracion/reglas-calidad       → reglas de calidad y validación
/configuracion/validacion-documental
/configuracion/actualizacion-ciudadana

Estructura de carpetas sugerida

src/app/
├── models/                   ← contratos de datos (Modelos)
│   ├── proyecto.model.ts
│   ├── area-interes.model.ts
│   └── ejecucion.model.ts
├── services/                 ← lógica y acceso a la API (Servicios)
│   ├── proyecto.service.ts
│   ├── area-interes.service.ts
│   └── ejecucion.service.ts
├── core/
│   └── error.interceptor.ts  ← política global de errores (Excepciones)
├── shared/                   ← componentes reutilizables
│   └── indicador/
├── flujos/                   ← frente 1: ejecución de flujos (Componentes)
│   ├── proyecto-lista/
│   ├── proyecto-form/        ← formulario reactivo (Formularios)
│   ├── proyecto-detalle/
│   ├── area-lista/
│   └── ejecucion-lista/
├── seguimiento/              ← frente 2: seguimiento administrativo
├── configuracion/            ← frente 3: configuración de información
├── app.config.ts
├── app.routes.ts
└── app.component.ts

Árbol de componentes de una pantalla

La pantalla Seguimiento de ejecuciones de un área podría componerse así:

flowchart TD
    P[EjecucionListaComponent<br/>página] --> H[EncabezadoAreaComponent]
    P --> I1[IndicadorComponent<br/>Avance]
    P --> I2[IndicadorComponent<br/>Estado]
    P --> I3[IndicadorComponent<br/>Trazabilidad]
    P --> T[TablaEjecucionesComponent]
    P -. inject .-> S[EjecucionService]
    S -. HttpClient .-> API[(API REST)]

• La página pide los datos al servicio y los reparte.
• IndicadorComponent es un solo componente reutilizado tres veces con distintos @Input.
• Los componentes hijos no saben de HTTP: solo reciben datos y emiten eventos.

Ese reparto —página que coordina, componentes de presentación simples, servicios que hablan con la API— es exactamente el que se desarrolla en Componentes, Servicios y Excepciones.

Pregunta de reflexión

La presentación separa operación, seguimiento y configuración. ¿Qué ventaja tiene que esa misma separación aparezca en las carpetas y en las rutas del código, y no solo en el menú de la aplicación?