Diseñando una API para datos espaciales

Estoy considerando intentar crear una API para poder poner a disposición de mis colegas algunos conjuntos de datos espaciales para su análisis.

Parte de mi trabajo ha sido analizar y preparar datos que luego pueden ser utilizados por otros para su posterior análisis. El trabajo (aunque actualmente en una escala más pequeña y menos sofisticado) es similar al walkcore pero involucra algunos conjuntos de datos enormes. Existen restricciones cada vez mayores sobre cómo puedo compartir los datos originales, pero mi trabajo derivado es compartible. He estado pensando sobre la mejor manera de compartir los resultados de mi análisis (además de transmitir grandes conjuntos de datos) y pensé que una API sería un enfoque. ¿En qué tipo de cosas debería pensar al construir una API? ¿Hay especificaciones de diseño que pueda seguir?

Mi visión suena un poco más grandiosa de lo que es actualmente, pero creo que sería un marco útil para considerar al principio de este trabajo.

Por API, supongo que se refiere a algún tipo de acceso de red a sus datos a través de un asunto de tipo HTTP POST / GET, como la API de Google Maps. ¿Serán datos ráster o vectoriales? Asumiré vector para los propósitos de esta discusión. Esto es realmente solo un protocolo de comunicación en lugar de una interfaz de programación de aplicaciones.

No necesitará diseñar nada desde cero, ya que hay muchos protocolos estándar (en lugar de API en sí, me molesta un poco llamar a las API de cosas cuando no lo son, ¡pero no lo aburriré! ) Si solo está interesado en servir datos vectoriales de solo lectura a sus clientes, solo necesita un servidor WFS que se encuentre frente a su base de datos. He usado GeoServer en el pasado, pero prefiero la ligereza de TinyOWS . Ambos hacen el mismo trabajo: configúrelos para acceder a su base de datos de datos derivados, configúrelos como parte de un servidor web ( Apache es común, pero prefiero lighttpd), Y ahí lo tienes. QGIS puede cargar datos desde un servidor WFS, y sin duda también Arc. OpenLayers también tiene capacidades de representación WFS para una solución basada en navegador. En el nivel inferior, GDAL se puede usar para convertir los datos de WFS a cualquier formato vectorial compatible con OGR.

Si desea capacidades de edición, tanto GeoServer como TinyOWS admiten WFS-T, lo que permite a sus usuarios cargar sus análisis nuevamente en su servidor.

La creación de su propia API realmente anula el propósito de tener estos estándares en primer lugar, a menos que sea increíblemente especializado y tenga requisitos específicos como el rendimiento, y er ... eso es todo lo que puedo pensar. Seguir esta ruta, sin una cantidad razonable de recursos, es una tarea difícil, aunque no imposible.

Tienes unas cuantas opciones; la elección de la cual dependerá de su modelo de datos, el tipo de datos a servir, el modelo de uso previsto, el control de acceso, así como la plataforma de entrega (Web, HTML, Servidor Java, IIS, conjunto de datos estáticos).

1. Extienda un producto existente para consumir su conjunto de datos. Puede buscar alojar una instancia de GeoServer en su computadora (¿o dedicada?) Y entregar sus datos de esa manera. Si sus datos no tienen un formato que GeoServer pueda entender, tiene la opción de escribir un paquete Java para proporcionar esa capacidad. La ventaja es que tiene un estándar bien definido para entregar información espacial tanto para visualización (WMS) como para manipulación / descarga de características (WFS), así como otros beneficios como geocaching y mosaico.
2. Tome su opción de API y tendrá control total sobre cómo los usuarios interactúan con ella. Lo que viene a su primera tarea, defina cómo desea que los usuarios interactúen con sus datos. Esta interfaz para sus datos será la clave entre el éxito o el fracaso. Si su interfaz es demasiado abierta, puede volverse compleja e inutilizable, demasiado simple y restrictiva, lenta o sin adopción. De cualquier manera, será importante definir la forma en que desea que los usuarios accedan a sus datos, y la forma en que anticipa que los usuarios querrán usar sus datos.

Buena suerte, una API no es una tarea pequeña, ya que debe considerar el método de lanzamiento y los ciclos, las correcciones de errores y las pruebas. Todo esto contribuye a la usabilidad. No digo que no lo hagas, sería una gran experiencia. Aunque construir sobre un producto existente también podría ser una experiencia positiva.