Diseño de una API para datos espaciales

Question

Estoy considerando la posibilidad de hacer una API para poder poner a disposición de los colegas algunos conjuntos de datos espaciales para su análisis.

Parte de mi trabajo ha consistido en analizar y preparar datos que luego pueden ser utilizados por otros para su análisis. El trabajo (aunque actualmente a menor escala y menos sofisticado) es similar a walkscore pero implica algunos conjuntos de datos enormes. Cada vez hay más restricciones para compartir los datos originales, pero mi trabajo derivado se puede compartir. He estado pensando en la mejor manera de compartir los resultados de mis análisis (fuera de la transmisión de grandes conjuntos de datos) y pensé que una API sería un enfoque. ¿En qué tipo de cosas debería pensar cuando construya una API? ¿Existen especificaciones de diseño que pueda seguir?

Mi visión suena un poco más grandiosa de lo que es en la actualidad, pero creo que sería un marco útil a tener en cuenta al principio de este trabajo.

Answer 1

Por API, supongo que te refieres a algún tipo de acceso de red a tus datos a través de un asunto de tipo HTTP POST/GET como la API de Google Maps. ¿Serán datos rasterizados o vectoriales? Asumiré que son vectores para los fines de esta discusión. En realidad se trata de un protocolo de comunicación más que de una interfaz de programación de aplicaciones.

No necesitarás diseñar nada desde cero, porque hay un montón de protocolos estándar (más que APIs per se, tengo un poco de manía con llamar a las cosas APIs cuando no lo son, ¡pero no te voy a aburrir!) Si sólo te interesa servir datos vectoriales de sólo lectura a tus clientes, sólo necesitas un Servidor WFS que se encuentra frente a su base de datos. He utilizado GeoServer en el pasado, pero prefiero la ligereza de TinyOWS . Ambos hacen el mismo trabajo: configúralos para que accedan a tu base de datos derivados, ponlos a funcionar como parte de un servidor web ( Apache es común, pero yo prefiero lighttpd ), y ahí lo tienes. QGIS puede cargar datos de un servidor WFS, y sin duda también Arc. OpenLayers también tiene capacidades de renderizado WFS para una solución basada en el navegador. En el nivel inferior, GDAL puede utilizarse para convertir los datos de WFS a cualquier formato vectorial que admita OGR.

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

La creación de una API propia no cumple con el propósito de tener estos estándares en primer lugar, a menos que seas increíblemente especializado y tengas requisitos específicos como el rendimiento, y... eso es todo lo que se me ocurre. Ir por este camino, sin una cantidad razonable de recursos, es una tarea complicada, aunque no imposible.

Answer 2

Tiene un par de opciones, cuya elección 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, Java Server, IIS, conjunto de datos estáticos).

1. Amplíe un producto existente para consumir su conjunto de datos. Podría considerar la posibilidad de alojar un GeoServer en su ordenador (¿o en el dedicado?) 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 se dispone de un estándar bien definido para la entrega de información espacial, tanto para la visualización (WMS) como para la manipulación/descarga de características (WFS), además de otras ventajas como el geocaching y la creación de mosaicos.
2. Tome la opción de la API y tendrá el control total sobre la forma en que los usuarios interactúan con ella. Lo que lleva a su primera tarea, Defina cómo quiere que los usuarios interactúen con sus datos. Esta interfaz con sus datos será la clave entre el éxito o el fracaso. Si su interfaz es demasiado abierta, puede resultar compleja e inutilizable, o demasiado sencilla y restrictiva, con una adopción lenta o nula. En cualquier caso, será importante definir la forma en que quiere que los usuarios accedan a sus datos y la forma en que prevé que los usuarios querrán utilizarlos.

Buena suerte, una API no es una empresa pequeña, ya que hay que tener en cuenta el método y los ciclos de publicación, las correcciones de errores y las pruebas. Todo ello contribuye a la usabilidad. No digo que no lo hagas, sería una gran experiencia. Aunque construir sobre un producto ya existente también podría ser una experiencia positiva.