空間データ用のAPIの設計

一部の空間データセットを同僚が分析のために利用できるようにするために、APIを作成することを検討しています。

私の仕事の一部は、他の人がさらに分析するために使用できるデータを分析および準備することでした。作業（現在は小規模で洗練されていない）はwalkscoreに似ていますが、いくつかの巨大なデータセットが関係しています。元のデータを共有する方法に制限が増えていますが、私の派生物は共有できます。私は（大規模なデータセットを渡す以外に）分析の結果を共有するための最良の方法について考えており、APIが1つのアプローチになると考えていました。APIを構築する場合、どのようなことを考慮すべきですか？従うことができる設計仕様はありますか？

私のビジョンは現在よりも少し壮大に聞こえますが、この作業の早い段階で検討することは有用なフレームワークになると思います。

APIとは、Google Maps APIなどのHTTP POST / GETタイプの問題を介した、データへのある種のネットワークアクセスを意味していると思いますか？ラスターデータですか、ベクターデータですか？この説明では、ベクターを想定します。これは、実際にはアプリケーションプログラミングインターフェイスではなく、単なる通信プロトコルです。

標準プロトコルがたくさんあるので、最初から何も設計する必要はありません（API自体ではなく、APIがない場合にAPIを呼び出すことには少しバグがありますが、退屈することはありません！ ）。読み取り専用のベクターデータをクライアントに提供するだけの場合は、データベースの前にあるWFSサーバーが必要です。私は過去にGeoServerを使用しましたが、TinyOWSの軽さを好みます。どちらも同じ仕事をします：派生データのデータベースにアクセスするように設定し、Webサーバーの一部として実行するように設定します（Apacheが一般的ですが、私はlighttpdを好みます）、そしてあなたはそれを持っています。QGISはWFSサーバーからデータをロードでき、Arcも同様にロードできます。OpenLayersには、ブラウザーベースのソリューション用のWFSレンダリング機能もあります。下位レベルでは、GDALを使用して、WFSからOGRがサポートする任意のベクトル形式にデータを変換できます。

編集機能が必要な場合は、GeoServerとTinyOWSの両方がWFS-Tをサポートしているため、ユーザーは分析をサーバーにアップロードできます。

独自のAPIを作成することは、非常に専門的で、パフォーマンスなどの特定の要件がない限り、そもそもこれらの標準を持つ目的を完全に覆します。適度な量のリソースなしにこのルートを進むことは、不可能ではありませんが、困難な作業です。

いくつかのオプションがあります。どちらを選択するかは、データモデル、提供するデータの種類、使用目的のモデル、アクセス制御、および配信のプラットフォーム（Web、HTML、Javaサーバー、IIS、静的データセット）によって異なります。

1. 既存の製品を拡張してデータセットを使用します。あなたの（または専用？）コンピュータでGeoServerインスタンスをホストしているのを見て、その方法でデータを配信することができます。データがGeoServerが理解できる形式でない場合は、その機能を提供するJavaパッケージを作成するオプションがあります。利点は、視覚化（WMS）と機能の操作/ダウンロード（WFS）の両方に空間情報を提供するための明確な標準があり、ジオキャッシングやタイリングなどの他の利点があることです。
2. APIオプションを選択すると、ユーザーがそれとどのようにインターフェースするかを完全に制御できます。これが最初のタスクです。ユーザーがデータを操作する方法を定義します。 このデータへのインターフェースは、成功と失敗の間の鍵となります。インターフェースがオープンすぎると、インターフェースが複雑になり、使用できなくなったり、単純になりすぎたり、制限されたり、遅くなったり、採用されなくなったりします。どちらの方法でも、ユーザーがデータにアクセスする方法と、ユーザーがデータを使用することを期待する方法を定義することが重要です。

幸運なことに、リリース方法とサイクル、バグ修正、テストを考慮する必要があるため、APIは小さな仕事ではありません。これらすべてがユーザビリティに貢献しています。やらないと言っているのではなく、素晴らしい経験になるでしょう。ただし、既存の製品に基づいて構築することも、良い経験になる可能性があります。