Del 15 al 17 de noviembre de 2021, OGC e ISO/TC 211 organizaron conjuntamente el Sprint de código virtual de API geoespacial de noviembre de 2021El sprint de código se centró en el refinamiento de la OGC API – Features Norma y su versión ISO, ISO 19168.

OGC API – Features ofrece la capacidad de servir, crear, modificar y consultar datos espaciales en la Web. El estándar especifica requisitos y recomendaciones para crear API que sigan una forma estándar y consistente de compartir datos de características. El estándar está dividido en varias partes, de modo que un servicio solo tenga que usar aquellas partes relevantes para sus ofertas, lo que lo hace liviano y más fácil de desarrollar y mantener. 

OGC API – Features – Parte 1: Núcleo (la versión ISO es ISO 19168-1:2020 API geoespacial para funciones) se centra en la entrega de contenido de funciones. OGC API – Features – Parte 2: Sistemas de referencia de coordenadas por referencia (ISO/DIS 19168-2) agrega soporte para sistemas de referencia de coordenadas distintos del único CRS especificado en la Parte 1, WGS84.

An Sprint de código OGC es un evento colaborativo e inclusivo impulsado por una programación innovadora y rápida con restricciones mínimas de proceso y organización para respaldar el desarrollo de nuevas aplicaciones y estándares candidatos. 

Durante los últimos tres años hemos estado perfeccionando el proceso de organización y celebración de sprints de código OGC. Para este sprint de código virtual de API geoespacial de noviembre de 2021, se probó un nuevo enfoque: usar Discord para proporcionar servicios de video, voz y chat. También por primera vez en los sprints de código, realizamos un Mentor Stream en paralelo con salas de trabajo para desarrolladores expertos. Los Mentor Streams se diseñaron para ayudar a los desarrolladores a comenzar con las características de la API de OGC y las normas ISO 19168-1:2020.

El primer día comenzó con las palabras de bienvenida de la Dra. Joana Simoes (OGC DevRel) y Peter Parslow (presidente electo de ISO/TC 1). Después de las palabras de bienvenida, Clemens Portele (instrumentos interactivos) y Panagiotis “Peter” Vretanos (CubeWerx) presentaron los objetivos del sprint. El primer día también tuvimos debates sobre Consultables  y  Simplificación de geometría, y sesiones de Mentor Stream en Compartir datos a través de OGC API – Features dirigido por la Dra. Joana Simoes (OGC), así como otra sesión sobre Introducción a los catálogos de activos espaciotemporales (STAC) y su uso de las funciones de la API de OGC Dirigido por Chris Holmes (Planet), Rob Emanuele (Microsoft) y Matthew Hanson (Element 84). Entre los debates y las sesiones de tutoría, hubo mucho trabajo de codificación.

El día 2, tuvimos sesiones de Mentor Stream sobre Cómo cargar datos de características en su aplicación frontend dirigido por Antonio Cerciello (EarthPulse) y Pruebas de implementaciones de OGC API – Features para el cumplimiento de la norma dirigido por el Dr. Gobe Hobona (OGC). Hubo demostraciones preliminares de simplificación de geometría a través de OGC API – FeaturesDe manera similar, entre las discusiones y las sesiones de tutoría hubo mucha más codificación.

El tercer día, se continuó con la codificación y se ofreció una charla breve sobre funciones y geometría de JSON a cargo de Clemens Portele (instrumentos interactivos) y Peter Vretanos (CubeWerx), además de una sesión de demostración final. Consulta las capturas de pantalla de la demostración final al final de este artículo.

 

Lecciones aprendidas

  • Es necesario ofrecer una geometría de respaldo JSON-FG para admitir diferentes situaciones, es decir, cuándo debería estar allí y cuándo no.
  • Para simplificar la geometría, los participantes del sprint comenzaron con el nivel de zoom, el denominador de escala y una serie de otros parámetros y luego, al final del sprint de código, hubo acuerdo en que deberíamos usar el nivel de zoom.
  • Los participantes del sprint querían apoyar situaciones en las que, en función del nivel de zoom, el servidor pudiera devolver algunas funciones y no todas.
  • También se demostró un caso de uso de recorte. Por ejemplo, si se observa Nueva York, no debería ser necesario obtener toda la costa de EE. UU.
  • Los participantes del sprint también avanzaron en cómo manejar esquemas JSON.
  • Los participantes del sprint presentarán un problema en el repositorio JSON-FG para buscar una extensión que marque algo con el clipbox (segmento artificial). MapML ha añadido esta capacidad. La alternativa es siempre exigir un borde adicional. Es decir, si se debe permitir que un clipbox sea más grande que los datos. Por ejemplo, si una geometría real en un shapefile puede ir más allá de los límites de -180 a 180 grados.
  • El sprint de código ha sido bueno tanto para JSON-FG como para OGC API – Features.
  • JSON-FG podría considerarse como una clase de conformidad para OGC API – Features sólo después de que JSON-FG haya sido adoptado como estándar oficial de OGC.
  • STAC tiene varios patrones de implementación. Uno de los patrones expone un OGC API – Features Interfaz, utilizada para búsqueda.
  • La idea es tener una alineación entre STAC y OGC API – FeaturesEsta alineación también beneficiará a OGC API – Records.
  • Algunas de las preguntas son cómo documentamos/describimos los metadatos de los recursos ofrecidos por OGC API – Features, ISO 19168-1 y sus normas candidatas relacionadas, como STAC y OGC API – Registros.
  • STAC será un perfil de registros API de OGC. La comunidad STAC está trabajando en una definición de un registro de conjunto de datos para STAC que se alinearía con el concepto de registro de los registros API de OGC.
  • El Geospatial API Virtual Code Sprint de noviembre de 2021 también demostró el modo de compatibilidad. Escenario de ejemplo: si tiene un edificio en 3D, puede usar JSON-FG, pero si desea mostrar una geometría más simple, el servidor proporcionará GeoJSON.

Trabajo Futuro

Los participantes hicieron las siguientes recomendaciones para el trabajo futuro.

Programa de Innovación

  • Acerca de la entrega MUDDI uso de datos OGC API – Features y JSON-FG
  • Desarrollo de un borrador de especificaciones para nuevas capacidades que se están considerando para futuras versiones.
  • Implementaciones de las nuevas capacidades que se están considerando para futuras ampliaciones: Common Query Language (CQL), CRUD (Crear, reemplazar, actualizar, eliminar), selección de propiedades, OpenAPI 3.1, solicitudes condicionales, almacenamiento en caché web.
  • Seguridad para el piloto de estándares de API de OGC (esto podría incluir los diferentes niveles de seguridad, p. ej., DCS, OpenAPI). Esta podría ser una buena combinación con la extensión CRUD.
  • Otras tareas de generación de código en futuros sprints de código.

Programa de Normas

  • Completando CQL
  • Mayor alineación entre STAC y OGC API – Registros
  • Hay una votación en curso en ISO para la Parte 2, por lo que podría haber una oportunidad de realizar algún evento en el Programa de Normas una vez que se haya aprobado la ISO 19168-2.

Conclusiones

El sprint de código cumplió con éxito sus objetivos. Los participantes del sprint pudieron debatir y crear prototipos de nuevas capacidades. Los participantes del sprint también consideraron que los tutoriales y las charlas breves que se ofrecieron en el Mentor Stream fueron útiles.

Respecto al nuevo enfoque para los OGC Code Sprints, los participantes del sprint ofrecieron las siguientes recomendaciones:

  • Grabe los tutoriales, de modo que si un participante se pierde uno, pueda ponerse al día más tarde.
  • Organice un curso de mentoría para principiantes y expertos que lleve al desarrollador desde los primeros pasos hasta temas más avanzados. Esto requeriría un programa de 3 días.
  • ¡La idea de Discord fue realmente genial!
  • En el futuro podríamos utilizar los demás canales de texto. Quizás el primer mensaje debería explicar que “vamos a utilizar este canal de una manera particular…”

Para obtener más información sobre el Sprint, visite el Repositorio de GitHub del sprint de código de API geoespacial de noviembre de 2021.