Проектування API для просторових даних

Я розглядаю спробу зробити API, щоб я міг зробити деякі набори просторових даних доступними колегам для аналізу.

Частина моєї роботи полягала в аналізі та підготовці даних, які потім можуть бути використані для подальшого аналізу іншими. Робота (хоча зараз у меншому масштабі та менш складна) схожа на оглядовий бал, але передбачає величезні набори даних. Зростають обмеження щодо того, як я можу ділитися оригінальними даними, але моя похідна робота може бути спільною. Я думав про те, як найкраще поділитися результатами мого аналізу (за винятком передачі великих наборів даних) і думав, що API - це один підхід. Про які речі я повинен думати, будуючи API? Чи є специфікації дизайну, яких я можу дотримуватися?

Моє бачення звучить трохи більш грандіозно, ніж зараз, але я думаю, що це було б корисною основою для розгляду на початку цієї роботи.

Під API я припускаю, що ви маєте на увазі якийсь мережевий доступ до своїх даних за допомогою HTTP POST / GET типу, наприклад, API Google Maps? Це будуть растрові чи векторні дані? Я буду припускати вектор для цілей цієї дискусії. Це дійсно просто протокол зв'язку, а не інтерфейс програмування програми.

Вам не потрібно буде нічого розробляти з нуля, тому що існує багато стандартних протоколів (а не API, як наслідок, у мене є певна помилка щодо виклику API API, коли їх немає, але я вам не набридаю! ). Якщо ви просто зацікавлені в наданні векторних даних лише для читання своїм клієнтам, вам просто потрібен сервер WFS, який сидить перед вашою базою даних. Раніше я використовував GeoServer , але я віддаю перевагу легкій вазі TinyOWS . Обидва роблять одну і ту ж роботу: налаштовують їх на доступ до вашої бази даних похідних даних, встановлюють їх як частину веб-сервера ( Apache є загальним, але я віддаю перевагу lighttpd), і там у вас є. QGIS може завантажувати дані з сервера WFS, і безсумнівно, це може і Arc. OpenLayers також має можливість відображення WFS для браузерного рішення. На нижньому рівні GDAL може використовуватися для перетворення даних з WFS в будь-який підтримку OGR у векторному форматі.

Якщо ви хочете можливості редагування, і GeoServer, і TinyOWS підтримують WFS-T, що дозволяє вашим користувачам завантажувати свої аналізи назад на ваш сервер.

Створення власного API справді перемагає призначення цих стандартів у першу чергу, якщо ви не неймовірно спеціалізовані і не маєте конкретних вимог, таких як продуктивність та ер ... це все, про що я можу придумати. Пройти цей маршрут без розумної кількості ресурсів - це загроза - хоча і не неможлива - завдання.

У вас є пара варіантів; вибір яких буде залежати від вашої моделі даних, типу даних, які будуть надані, призначеної моделі використання, контролю доступу, а також платформи доставки (Web, HTML, Java Server, IIS, статичний набір даних).

1. Розгорніть існуючий продукт, щоб споживати ваш набір даних. Ви можете подивитися хостинг примірника GeoServer на своєму (або виділеному?) Комп’ютері та передати свої дані таким чином. Якщо ваші дані не в форматі, який може зрозуміти GeoServer, у вас є можливість написати пакет Java для надання цієї можливості. Перевагою є те, що у вас є чітко визначений стандарт для надання просторової інформації як для візуалізації (WMS), так і для маніпулювання / завантаження функцій (WFS), а також інших переваг, таких як геокешування та плитка.
2. Візьміть свій параметр API і ви маєте повний контроль над тим, як користувачі взаємодіють з ним. Що стосується вашого першого завдання, визначте, як ви бажаєте, щоб користувачі взаємодіяли з вашими даними. Цей інтерфейс до ваших даних стане ключем між успіхом чи невдачею. Якщо ваш інтерфейс занадто відкритий, він може стати складним і непридатним, занадто простим і обмежуючим, повільним або без прийняття. Так чи інакше, важливим буде визначення способу доступу користувачів до ваших даних та спосіб очікування, що користувачі захочуть використовувати ваші дані.

Успіхів, API не є малим завданням, оскільки вам потрібно розглянути спосіб випуску та цикли, виправлення помилок, тестування. Все це сприяє зручності використання. Я не кажу, що не роби цього, це було б чудовим досвідом. Хоча надбудова на існуючому продукті теж може бути позитивним досвідом.