回答:
Google AppEngineを使用して空間/属性クエリを実行します。主な問題（初日から）は、任意のサイズのライン/ポリゴンの大きなセットをインデックスする方法です。ポイントデータはそれほど難しくありません（ジオハッシュ、ジオモデルなどを参照）が、ランダムにクラスター化された小さな/大きなポリゴンのセットは常に問題でした（そして場合によっては依然としてそうです）
GAEで空間インデックスのいくつかの異なるバージョンを試しましたが、ほとんどは以下の2つのバリエーションです。SQLデータベースほど高速ではなく、すべてに賛否両論があります。ただし、ほとんどのインターネットベースのマッピングアプリでは、トレードオフが妥当と思われます。また、以下の2つをインメモリジオメトリカリング（JTSなどを介して）と組み合わせて、最終的な検索パラメーターに適合しない機能を削除する必要があります。そして最後に、GAE固有の機能に依存していますが、他のアーキテクチャにも適用できると確信しています（または、TyphoonAEを使用してLinuxクラスター、ec2などで実行できます）
グリッド -特定の領域のすべての機能を既知のグリッドインデックスにパックします。グリッドに小さな空間インデックスを配置して、グリッドに含まれる一連の機能をすばやくナビゲートします。ほとんどのクエリでは、正確なグリッドの命名規則とK / Vエンティティ（クエリではなく取得）との関係を知っているので、ほんの少しのグリッドを引くだけで済みます。
長所 -非常に高速で、実装が簡単で、メモリフットプリントがありません。
短所 -前処理が必要、ユーザーはグリッドサイズを決定する必要があり、大きなジオムは複数のグリッドで共有され、クラスタリングによりグリッドが過負荷になる可能性があり、シリアル化/逆シリアル化のコストが問題になる可能性があります
QuadKeysこれは現在の実装です。基本的にはグリッドと同じですが、グリッドレベルが設定されていない点が異なります。機能が追加されると、境界が完全に含まれるクワッドキーグリッドによってインデックス付けされます（または、場合によっては、1つのクワッドキーが使用できないときに2つに分割され、日付変更線が考えられます）。qkが見つかったら、それを最大数の小さなqkに分割し、フィーチャのよりきめの細かい表現を提供します。次に、その機能へのポインター/ bboxは、クエリ可能な軽量のグリッドインデックス（機能のグループ）にパックされます（元のデザインは機能を直接照会しましたが、結果セットが大きい場合、これは遅すぎる/ CPUに負荷がかかります）
Polyline Quadkeys http://www.arc2earth.com/images/help/GAE_QKS_1.png Polygon Quadkeys http://www.arc2earth.com/images/help/GAE_QKS_2.png
上記で使用されるクワッドキーの命名規則はよく知られており、さらに重要なことには、局所性を保持する傾向があります（ここで詳しく説明します）
上記のポリゴンは次のようになります：0320101013123 03201010131212 03201010131213 0320101013132 0320101013133 03201010131302 03201010131303 032010101313002 032010101313003 032010101313012 032010101313013 03201010131312 03201010131313 032010101313102 ...
クエリの境界が十分に小さい場合は、qkを介して直接フェッチできます。これは、GAE datatoreに対する単一のバッチrpc呼び出しのみであるため、最適です。境界が十分に大きく、可能なqks（> 1000）が多すぎる場合は、代わりにフィルターを使用してクエリを実行できます（例：qk> = 0320101013およびqk <= 0320101013 + \ ufffd）。クアッドキーの命名規則に加えて、GAEが文字列にインデックスを付ける方法により、上記のクエリはそのqk値を下回る既存のグリッドのみを取得できます。
他にも注意点とパフォーマンスの問題がありますが、一般的には、クワッドキーでクエリを実行して実行可能にする機能
例-米国の郡のクエリ：geojson
長所 -かなり高速、グリッドサイズの設定なし、メモリフットプリントなし、過密グリッドなし
短所 -前処理が必要、いくつかのシナリオでオーバーフェッチが発生する可能性があり、極性データなし
空間充填曲線 - 今年のGoogle I / O でのAlfredのNextGen Queriesトークをご覧ください。新しいMultiQuery演算子（並列で実行）と共に汎用の空間/時間充填曲線を含めることで、いくつかの本当にクールな空間クエリが可能になります。従来のSQLパフォーマンスに勝るでしょうか？言うのは難しいですが、本当にうまくスケーリングするはずです。そして、あらゆる形状/サイズの常時オンのモバイルデバイスがサイト/サービスへのトラフィックを劇的に増加させる未来に急速に近づいています。
最後に、NoSQLよりもSQLを選択する前に、問題のあるドメインをよく見る必要があることに同意します。私たちの場合、GAEの価格設定モデルが本当に好きだったので、選択の余地はありませんでしたが、スケーリングする必要がない場合は、時間を節約して、標準のSQLデータベースを使用してください
GeoCouchのことを聞いたことがあります。GeoCouchは、位置情報ベースのデータ用のCouchDBの実装です。また、MongoDBには地理空間インデックス機能があると思います。
これは主にアルゴリズムに関する質問です。スタックオーバーフローは、それを尋ねるのに適した場所かもしれません。
いずれにせよ、あなたの直接の質問に対する答えは「はい、kvpストアを使用して空間データを表すことができます」です。しかし、より良い質問は、「空間データを表すためにkvpストアを使用する必要がありますか？」
その質問への答えは（他の多くの人と同様に）「依存する」です。それは、規模、（トランザクション）作業負荷、データの性質、および自由に使用できる計算インフラストラクチャに依存します。
kvpストアのオーバーヘッドは低く、大量の挿入および更新の並列処理のスループットを向上させることができます。ただし、空間検索（長方形内のすべてのオブジェクトを検索）を実行するのはそれほど高速ではありません。そのためには、Rツリーのような空間インデックスが必要です。
ただし、データボリュームが非常に大きく、コンピューターの巨大なクラスターがある場合は、kvpインデックスを使用すると、パフォーマンス上の利点が得られます。実際に確実に知る唯一の方法は、実際のデータを使用してパフォーマンス測定を行い、遭遇することが予想されるパターンにアクセスすることです。
更新：
ここにもう少し情報があります。KVPストアを使用して、空間検索を実行できます。問題は、遅いことです。理由を確認するには、次のようなものを検討してください。
***********
***********
***********
***********
****###****
****###****
****###****
***********
***********
***********
************と＃は、11x11グリッドにレイアウトされたオブジェクトを表し、原点は左上隅にあります。長方形（4,4）-（7,7）内のオブジェクトの検索を想像してください。これですべての「＃」が見つかるはずです。KVPストアのインデックスを表すためにb +ツリーを使用していると仮定すると、「X」インデックスまたは「Y」インデックスのいずれかを使用して結果を見つけることができます。この場合、どちらでもかまいません。議論のために、xインデックスを使用します。Xインデックスでlog（n）ルックアップを実行して、X値が「4」の最初のノードを見つけ、7より大きい値を持つノードが見つかるまでb +ツリーリーフノードを反復処理します。 xインデックスを反復処理すると、必要なyの範囲外にあるものはすべて拒否されます。
これは遅いです。同じ密度、たとえば100 K * 100 Kの大きなグリッドでそれを想像してください。9つのレコードだけを見つけるには、「300、000」のインデックスエントリをスキャンする必要があります。ただし、適切にバランスのとれたRツリーを使用する場合、インデックスルックアップはおそらく約90レコード程度をスキャンするだけで済みます。それは大きな違いです。
ただし、問題は、Rツリーのバランスを保つのに費用がかかることです。これが、答えが「依存する」である理由であり、「これをすべきか」という質問が「どうやってそれをするか」よりもはるかに重要である理由です。
レコードを頻繁に挿入および削除し、ほとんどが「オブジェクトID」ルックアップを行い、「空間」ルックアップを頻繁に行わない場合、KVPインデックスを使用すると、実際にシステムを使用したいパフォーマンスが向上します。ただし、挿入または削除の頻度は低いが、空間検索を頻繁に行う場合は、Rツリーを使用する必要があります。
lat / long値を使用している場合、ストアの値部分としてジオハッシュを使用できる場合があります。
NYCの1つです。dr5regy6rc6ye
：ジオハッシュを使用すると、様々な精度のグリッドを取得するジオハッシュの末尾に文字をオフにノックを開始することができhttp://geohash.org/dr5reを
ほとんどの場合、キー/値またはキー/値/タイプのストレージからよりも、リレーショナルデータストレージからより多くのユーティリティを取得します。この種のデータスキームの効率的なクエリとレポート作成にはかなりの複雑さがあります。
私のアドバイスは、使用方法を検討する前に、スケールに実際にNoSQLが必要かどうかを厳密に評価することです。
見てみましょう。このGAEアプリシリアライズJTSのにジオメトリをBigTableのを。他のNoSQLストレージエンジンにも採用できる場合があります。
MongoDBには、ドキュメントの厳密な2d [x、y]タプルプロパティに基づいて地理空間インデックスを作成および使用する機能があり、「near」タイプと「bounds」タイプの両方のクエリが可能です。ただし、投影の補正は一切行わず、平面地球の理想的なモデルを使用します
キー/値ストアをキャッシュレイヤーとしてのみ使用します。http：//www.membase.org/またはhttp://wiki.basho.com/display/RIAK/How+Things+Work（riak_kv_cache_backend）を参照してください
アプリのニーズに応じて、データへのSQLアクセスが必要になる場合があります。
これは確かに関心のある新興分野です。 FOSS4Gカンファレンスです。