Conception d'une API pour les données spatiales

J'envisage d'essayer de créer une API afin de pouvoir mettre à la disposition de mes collègues des jeux de données spatiales pour analyse.

Une partie de mon travail a consisté à analyser et à préparer des données qui peuvent ensuite être utilisées par d'autres pour une analyse plus approfondie. Le travail (bien qu'actuellement à une échelle plus petite et moins sophistiquée) est similaire au walkcore mais implique des jeux de données énormes. Il y a des restrictions croissantes sur la façon dont je peux partager les données originales, mais mon travail dérivé est partageable. J'ai réfléchi à la meilleure façon de partager les résultats de mon analyse (en dehors de la transmission de grands ensembles de données) et je pensais qu'une API serait une approche. À quel genre de choses dois-je penser lors de la construction d'une API? Existe-t-il des spécifications de conception que je peux suivre?

Ma vision semble un peu plus grandiose qu'elle ne l'est actuellement, mais je pense que ce serait un cadre utile à considérer dès le début de ce travail.

Par API, je suppose que vous entendez une sorte d'accès réseau à vos données via une affaire de type HTTP POST / GET telle que l'API Google Maps? Sera-ce des données raster ou vectorielles? Je suppose que le vecteur est utilisé aux fins de cette discussion. Il s'agit vraiment d'un protocole de communication plutôt que d'une interface de programmation d'application.

Vous n'aurez pas besoin de concevoir quoi que ce soit à partir de zéro, car il existe de nombreux protocoles standard (plutôt que des API en soi, j'ai un peu de bogue à propos d'appeler des choses API quand elles ne le sont pas, mais je ne vous ennuierai pas! ). Si vous souhaitez simplement servir des données vectorielles en lecture seule à vos clients, vous avez juste besoin d'un serveur WFS qui se trouve devant votre base de données. J'ai utilisé GeoServer dans le passé, mais je préfère la légèreté de TinyOWS . Les deux font le même travail: les configurer pour accéder à votre base de données de données dérivées, les configurer en cours d'exécution dans le cadre d'un serveur Web ( Apache est courant, mais je préfère lighttpd), Et voila. QGIS peut charger des données à partir d'un serveur WFS, tout comme Arc. OpenLayers dispose également de capacités de rendu WFS pour une solution basée sur un navigateur. Au niveau inférieur, GDAL peut être utilisé pour convertir les données de WFS en n'importe quel format OGR pris en charge.

Si vous souhaitez des capacités d'édition, GeoServer et TinyOWS prennent en charge WFS-T, permettant à vos utilisateurs de télécharger à nouveau leurs analyses sur votre serveur.

Créer votre propre API va vraiment à l'encontre du but d'avoir ces normes en premier lieu, à moins que vous ne soyez incroyablement spécialisé et que vous ayez des exigences spécifiques telles que les performances, et euh ... c'est à peu près tout ce à quoi je peux penser. Aller dans cette voie, sans une quantité raisonnable de ressources, est une tâche difficile - mais pas impossible -.

Vous avez plusieurs options; dont le choix dépendra de votre modèle de données, du type de données à servir, du modèle d'utilisation prévu, du contrôle d'accès ainsi que de la plateforme de livraison (Web, HTML, Java Server, IIS, ensemble de données statiques).

1. Étendez un produit existant pour consommer votre ensemble de données. Vous pouvez envisager d'héberger une instance GeoServer sur votre ordinateur (ou dédié?) Et de livrer vos données de cette façon. Si vos données ne sont pas d'un format que GeoServer peut comprendre, vous avez la possibilité d'écrire un package Java pour fournir cette capacité. L'avantage est que vous disposez d'une norme bien définie pour fournir des informations spatiales à la fois pour la visualisation (WMS) et la manipulation / téléchargement d'entités (WFS), ainsi que d'autres avantages tels que la géocachette et la mosaïque.
2. Prenez votre option API et vous avez un contrôle total sur la façon dont les utilisateurs interagissent avec elle. Pour votre première tâche, définissez comment vous souhaitez que les utilisateurs interagissent avec vos données. Cette interface avec vos données sera la clé entre le succès ou l'échec. Si votre interface est trop ouverte, elle peut devenir complexe et inutilisable, trop simple et restrictive, lente ou pas d'adoption. Quoi qu'il en soit, il sera important de définir la façon dont vous souhaitez que les utilisateurs accèdent à vos données et la manière dont vous pensez que les utilisateurs voudront utiliser vos données.

Bonne chance, une API n'est pas une mince affaire car vous devez considérer la méthode et les cycles de publication, les corrections de bugs, les tests. Tous ces éléments contribuent à la convivialité. Je ne dis pas ne le fais pas, ce serait une super expérience. Bien que s'appuyer sur un produit existant puisse également être une expérience positive.