Progettazione di un'API per dati spaziali

Sto pensando di provare a creare un'API in modo da poter rendere disponibili alcuni set di dati spaziali per i colleghi per l'analisi.

Parte del mio lavoro è stato quello di analizzare e preparare i dati che possono quindi essere utilizzati per ulteriori analisi da parte di altri. Il lavoro (sebbene attualmente su scala ridotta e meno sofisticato) è simile a walkcore ma comporta alcuni enormi set di dati. Ci sono crescenti restrizioni su come posso condividere i dati originali, ma il mio lavoro derivato è condivisibile. Ho pensato al modo migliore per condividere i risultati della mia analisi (oltre a trasmettere set di dati di grandi dimensioni) e ho pensato che un'API sarebbe un approccio. A che tipo di cose dovrei pensare quando costruisco un'API? Ci sono specifiche di progettazione che posso seguire?

La mia visione sembra un po 'più grandiosa di quanto non sia attualmente, ma penso che sarebbe un quadro utile da considerare all'inizio di questo lavoro.

Per API, presumo tu intenda una sorta di accesso alla rete ai tuoi dati attraverso una relazione di tipo POST / GET HTTP come l'API di Google Maps? Saranno dati raster o vettoriali? Assumerò il vettore ai fini di questa discussione. Questo è davvero solo un protocollo di comunicazione piuttosto che un'interfaccia di programmazione dell'applicazione.

Non dovrai progettare nulla da zero, perché ci sono molti protocolli standard (piuttosto che le API di per sé, ho un po 'di bugbate nel chiamare cose API quando non lo sono, ma non ti annoierò! ). Se sei solo interessato a fornire dati vettoriali di sola lettura ai tuoi clienti, hai solo bisogno di un server WFS che si trovi davanti al tuo database. Ho usato GeoServer in passato, ma preferisco la leggerezza di TinyOWS . Entrambi fanno lo stesso lavoro: configurali per accedere al tuo database di dati derivati, impostali come parte di un server web ( Apache è comune, ma preferisco lighttpd), E il gioco è fatto. QGIS può caricare dati da un server WFS, e senza dubbio anche Arc. OpenLayers ha anche funzionalità di rendering WFS per una soluzione basata su browser. Al livello inferiore, GDAL può essere utilizzato per convertire i dati da WFS a qualsiasi supporto OGR in formato vettoriale.

Se desideri funzionalità di modifica, sia GeoServer che TinyOWS supportano WFS-T, consentendo ai tuoi utenti di caricare nuovamente le loro analisi sul tuo server.

La creazione di una tua API sconfigge davvero lo scopo di avere questi standard in primo luogo, a meno che tu non sia incredibilmente specializzato e tu abbia requisiti specifici come le prestazioni, ed ecc ... questo è tutto ciò a cui riesco a pensare. Seguire questa strada, senza una ragionevole quantità di risorse, è un compito arduo, sebbene non impossibile.

Hai un paio di opzioni; la scelta dipenderà dal modello di dati, dal tipo di dati da fornire, dal modello di utilizzo previsto, dal controllo degli accessi e dalla piattaforma di consegna (Web, HTML, Java Server, IIS, set di dati statici).

1. Estendi un prodotto esistente per utilizzare il tuo set di dati. Puoi guardare l'hosting di un'istanza di GeoServer sul tuo computer (o dedicato?) E fornire i tuoi dati in quel modo. Se i tuoi dati non sono di un formato comprensibile da GeoServer, hai la possibilità di scrivere un pacchetto Java per fornire tale capacità. Il vantaggio è che si dispone di uno standard ben definito per la fornitura di informazioni spaziali sia per la visualizzazione (WMS) che per la manipolazione / download delle funzionalità (WFS), nonché per altri vantaggi come geocaching e piastrellatura.
2. Prendi la tua opzione API e hai il pieno controllo su come gli utenti si interfacciano con essa. Quale è il tuo primo compito, Definisci come desideri che gli utenti interagiscano con i tuoi dati. Questa interfaccia per i tuoi dati sarà la chiave tra successo o fallimento. Se la tua interfaccia è troppo aperta, può diventare complessa e inutilizzabile, troppo semplice e restrittiva, adozione lenta o assente. In entrambi i casi, sarà importante definire il modo in cui desideri che gli utenti accedano ai tuoi dati e il modo in cui prevedi che gli utenti vorranno utilizzare i tuoi dati.

Buona fortuna, un'API non è una piccola impresa in quanto è necessario considerare il metodo e i cicli di rilascio, le correzioni di bug, i test. Tutto ciò contribuisce all'usabilità. Non sto dicendo di non farlo, sarebbe una bella esperienza. Anche se basarsi su un prodotto esistente potrebbe essere un'esperienza positiva.