Разработка API для пространственных данных

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

Часть моей работы заключалась в анализе и подготовке данных, которые затем могут быть использованы для дальнейшего анализа другими. Работа (хотя в настоящее время в меньшем масштабе и менее сложная) похожа на Walkscore, но включает в себя некоторые огромные наборы данных. Существуют все более строгие ограничения на то, как я могу поделиться исходными данными, но моя производная работа доступна для совместного использования. Я размышлял о том, как лучше всего поделиться результатами своего анализа (за исключением передачи больших наборов данных), и подумал, что API будет одним из подходов. О каких вещах я должен думать при создании API? Существуют ли технические требования, которым я могу следовать?

Мое видение звучит немного более грандиозно, чем в настоящее время, но я думаю, что это будет полезной основой для рассмотрения в начале этой работы.

Под API я предполагаю, что вы имеете в виду какой-то сетевой доступ к вашим данным через HTTP POST / GET-тип, например API Карт Google? Это будут растровые или векторные данные? Я возьму вектор для целей этого обсуждения. Это на самом деле просто протокол связи, а не интерфейс прикладного программирования.

Вам не нужно ничего разрабатывать с нуля, потому что существует множество стандартных протоколов (а не 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 это не маленькое начинание, так как вам нужно учитывать метод выпуска и циклы, исправление ошибок, тестирование. Все это способствует удобству использования. Я не говорю, не делай этого, это был бы отличный опыт. Хотя использование существующего продукта также может быть положительным опытом.