Projetando uma API para Dados Espaciais

Estou pensando em tentar fazer uma API para que eu possa disponibilizar alguns conjuntos de dados espaciais para análise dos colegas.

Parte do meu trabalho tem sido analisar e preparar dados que podem ser usados ​​para análises posteriores por outros. O trabalho (embora atualmente em menor escala e menos sofisticado) é semelhante ao walkcore, mas envolve alguns conjuntos de dados enormes. Existem restrições crescentes sobre como posso compartilhar os dados originais, mas meu trabalho derivado é compartilhável. Eu estive pensando sobre a melhor forma de compartilhar os resultados da minha análise (além de transmitir grandes conjuntos de dados) e pensei que uma API seria uma abordagem. Em que tipo de coisas devo pensar ao construir uma API? Existem especificações de design que eu posso seguir?

Minha visão parece um pouco mais grandiosa do que é atualmente, mas acho que seria uma estrutura útil a ser considerada no início deste trabalho.

Por API, presumo que você queira dizer algum tipo de acesso de rede aos seus dados por meio de um caso do tipo HTTP POST / GET, como a API do Google Maps? Serão dados rasterizados ou vetoriais? Assumirei vetor para os propósitos desta discussão. Este é realmente apenas um protocolo de comunicação, e não uma interface de programação de aplicativos.

Você não precisará projetar nada do zero, porque existem muitos protocolos padrão (em vez de APIs em si, eu tenho um pouco de dificuldade em chamar coisas de APIs quando não são, mas não vou aborrecer você! ) Se você está interessado apenas em fornecer dados vetoriais somente leitura para seus clientes, precisa de um servidor WFS que fica na frente do seu banco de dados. Eu usei o GeoServer no passado, mas prefiro a leveza do TinyOWS . Ambos fazem o mesmo trabalho: configure-os para acessar seu banco de dados de dados derivados, configure-os como parte de um servidor web (o Apache é comum, mas eu prefiro o lighttpd) e aí está. O QGIS pode carregar dados de um servidor WFS e, sem dúvida, o Arc também. O OpenLayers também possui recursos de renderização WFS para uma solução baseada em navegador. No nível mais baixo, o GDAL pode ser usado para converter os dados do WFS em qualquer formato vetorial suportado pelo OGR.

Se você deseja recursos de edição, o GeoServer e o TinyOWS suportam o WFS-T, permitindo que os usuários enviem suas análises de volta para o servidor.

Criar sua própria API realmente derrota o propósito de ter esses padrões em primeiro lugar, a menos que você seja incrivelmente especializado e tenha requisitos específicos, como desempenho e ... é tudo o que consigo pensar. Seguir esse caminho, sem uma quantidade razoável de recursos, é uma tarefa árdua - embora não impossível -.

Você tem algumas opções; a escolha dependerá do modelo de dados, do tipo de dados a ser veiculado, do modelo de uso pretendido, do controle de acesso e da plataforma de entrega (Web, HTML, Java Server, IIS, conjunto de dados estáticos).

1. Estenda um produto existente para consumir seu conjunto de dados. Você pode hospedar uma instância do GeoServer no seu computador (ou dedicado?) E fornecer seus dados dessa maneira. Se seus dados não estiverem em um formato que o GeoServer possa entender, você poderá escrever um pacote Java para fornecer essa capacidade. A vantagem é que você possui um padrão bem definido para fornecer informações espaciais para visualização (WMS) e manipulação / download de recursos (WFS), além de outros benefícios, como geocaching e lado a lado.
2. Escolha sua opção de API e tenha controle total sobre como os usuários interagem com ela. Em sua primeira tarefa, defina como você deseja que os usuários interajam com seus dados. Essa interface para seus dados será a chave entre o sucesso ou o fracasso. Se sua interface estiver muito aberta, ela poderá se tornar complexa e inutilizável, simples e restritiva, lenta ou sem adoção. De qualquer forma, definir a maneira como você deseja que os usuários acessem seus dados e a maneira como você antecipa que os usuários desejarão usar seus dados serão importantes.

Boa sorte, uma API não é uma tarefa pequena, pois você precisa considerar o método de liberação e ciclos, correções de bugs e testes. Tudo isso contribui para a usabilidade. Não estou dizendo para não fazer, seria uma ótima experiência. Embora desenvolver um produto existente também possa ser uma experiência positiva.