Arquitectura de capas alojadas

Las capas alojadas de Meratyn permiten a un usuario publicar archivos que existen solo en su computadora y luego referenciar esas capas desde un proyecto compartido. Los consumidores no instalan los archivos originales ni configuran URLs de WMS, WFS u otros servicios.

El diseño mantiene GeoNode deliberadamente sin interfaz:

Meratyn es el límite del producto. Es propietario de los IDs de capa, la autenticación, la autorización, las referencias de proyecto, los descriptores de servicio y la interfaz de gestión. GeoNode gestiona los metadatos de recursos espaciales y los flujos de publicación. GeoServer sirve representaciones generadas a partir de datasets vectoriales y ráster. El almacén de activos cubre los formatos que resultan más útiles cuando se sirven directamente.

Por qué una sola API

Los proyectos almacenan una referencia a capa alojada, nunca una clave primaria de GeoNode, un nombre de workspace de GeoServer, un nombre de host interno o un endpoint suministrado por el usuario. Una respuesta de capa contiene uno o más descriptores de servicio normalizados:

{
  "id": "share-layer-uuid",
  "kind": "vector",
  "services": [
    {
      "id": "wms",
      "type": "wms",
      "url": "https://share.example/api/layers/share-layer-uuid/gateway/wms"
    },
    {
      "id": "wfs",
      "type": "wfs",
      "url": "https://share.example/api/layers/share-layer-uuid/gateway/wfs"
    }
  ]
}

El cliente selecciona su representación soportada preferida. Meratyn construye y autoriza cualquier solicitud al proveedor. No debe aceptar una URL del proveedor arbitraria a través de su proxy.

Publicación de archivos locales

1. El usuario elige uno o más archivos locales en la aplicación de escritorio o en la interfaz de gestión.
2. El cliente realiza una validación económica y agrupa sidecars como los componentes de un Shapefile.
3. Meratyn crea la capa y el registro de subida/importación y reserva cuota.
4. El origen se envía al almacenamiento de objetos o a un volumen local de desarrollo acotado.
5. El worker de ingesta detecta el formato y elige una estrategia de publicación.
6. GeoNode importa los datasets vectoriales/ráster soportados. Otros formatos se convierten a una representación canónica o permanecen como activos directos.
7. Meratyn registra privadamente los identificadores del proveedor y publica los descriptores de servicio normalizados.
8. Un proyecto almacena el ID de capa de Meratyn. Al abrir el proyecto se resuelve un descriptor de servicio actual y autorizado.

La publicación es asíncrona en despliegues reales. Los estados de la capa son draft, uploading, processing, published, failed y deleting. Los reintentos deben ser idempotentes y la eliminación debe limpiar tanto el estado del proveedor como el de los activos.

Estrategia de representación

La regla confiable más simple es «GeoNode para datasets, entrega directa para activos cloud-native».

Esto da a los usuarios GIS ordinarios el catálogo, los metadatos, los permisos y los servicios OGC de GeoNode sin forzar formatos naturalmente cloud-native a través de GeoServer. El proveedor es un detalle de implementación; cada representación sigue apareciendo en el mismo espacio de trabajo Layers de Meratyn.

Las colecciones son registros organizacionales propiedad de Meratyn dispuestos sobre el catálogo normalizado. Contienen IDs de capa de Meratyn estables y nunca cambian los metadatos del proveedor de una capa, su visibilidad ni su dependencia de proyecto. La membresía pública está restringida a capas públicas, de modo que las lecturas anónimas del catálogo no puedan revelar un recurso privado.

Mapeo de funcionalidades de GeoNode

Meratyn expone estas áreas de gestión:

• Resumen y estado de publicación
• Metadatos, incluido el esquema dinámico de metadatos del proveedor
• Presentación de atributos: orden, visibilidad, alias, descripción, formato, widget, editabilidad y restricciones
• Estilos y selección del estilo predeterminado
• Permisos para usuarios, organizaciones, grupos y acceso público
• Representaciones de servicio y descargas
• Versiones, linaje, actividad, uso y ajustes
• Mapeo de identidad del propietario, aprobación de publicación y ubicación destacada
• Documentos de GeoNode, activos complementarios e importación de metadatos ISO
• Creación vectorial schema-first, restricciones, validación y upsert masivo nativo
• Catálogos remotos WMS, GeoNode y ArcGIS mediante harvesting de GeoNode

GeoNode REST v2 se usa cuando tiene una operación estable. Una reducida app Django compañera suministra identidad/propiedad, publicación de documentos, descubrimiento de enlaces de recursos, presentación de atributos y operaciones del ciclo de vida de estilos que GeoNode 5.1 no expone como APIs estables. Las reglas de acceso geográfico siguen siendo política de Meratyn, y Meratyn realiza ediciones de features protegidas a través del servicio transaccional interno de features. Esto mantiene la extensión pequeña, evita una migración de base de datos del proveedor y preserva la copia local de Meratyn si una escritura al proveedor no está disponible temporalmente.

Modelo de acceso

Descubrimiento y autorización están separados:

• public: descubrible y potencialmente accesible sin iniciar sesión
• unlisted: accesible mediante un enlace/referencia autorizado pero no listado públicamente
• private: visible solo para principals explícitamente autorizados

Las concesiones apuntan a un usuario, organización o grupo e incluyen independientemente View, Download, Edit y Manage. El acceso público se representa mediante una concesión a un principal anónimo, no saltándose las verificaciones de política.

Los consumidores de proyectos privados reciben una sesión de acceso de corta duración acotada al proyecto y a las capas referenciadas. Los tokens personales permanentes deben soportar scopes tales como layers:read, layers:publish y layers:manage. Los tokens y las credenciales del proveedor nunca deben aparecer en archivos de proyecto ni en URLs de servicio.

Fallos y consistencia

Meratyn conserva únicamente la proyección necesaria para navegación, política, dependencias de proyecto, estado y reconciliación. GeoNode continúa siendo la autoridad para su modelo de recursos rico. Los enlaces al proveedor registran el ID del recurso remoto, la revisión o ETag, la hora de última sincronización, el estado y el error.

Las operaciones de subida, importación, actualización y eliminación son jobs. Un timeout del proveedor no descarta el origen ni simula que la publicación tuvo éxito. La reconciliación repara desviaciones recuperables y expone fallos accionables en la interfaz de gestión. Los jobs del proveedor son registros duraderos y no estado de polling exclusivo de la UI. La sincronización del catálogo es idempotente, se ejecuta periódicamente, importa recursos creados por el proveedor, mapea los propietarios del proveedor de vuelta a identidades de Meratyn y marca los recursos faltantes para reconciliación en lugar de eliminar silenciosamente los registros locales.

La pasarela OGC guarda en caché el descriptor inmutable del dataset del proveedor para cada recurso activo y comparte las búsquedas de descriptor en vuelo. Los clientes de mapa solicitan muchas teselas adyacentes concurrentemente; resolver el mismo dataset una sola vez evita que esa ráfaga de teselas multiplique el tráfico hacia la API de metadatos. La caché tiene límite acotado y las búsquedas fallidas se retiran para que una solicitud posterior pueda recuperarse.

Límite de despliegue

Solo Meratyn y su pasarela pública de activos/OGC requieren exposición a internet. GeoNode Django, la administración de GeoServer, PostGIS, Redis, memcached y Celery permanecen en la red privada de contenedores. El perfil Compose local expone el proxy de GeoNode en un puerto loopback de diagnóstico; producción debe dirigirlo únicamente a través de Meratyn o de una ruta de proxy inverso autenticado.

Consulte Desplegar capas alojadas para conocer la pila incluida y los ajustes operativos.