Answers:
我们使用Google AppEngine来运行空间/属性查询，并且主要的问题（从第一天开始）就是如何索引大型的任意大小的线/多边形。点数据并不太困难（请参见geohash，geomodel等），但是随机聚集的小/大多边形集始终是个问题（在某些情况下仍然是）
我在GAE上尝试了几种不同版本的空间索引，但大多数只是下面两种版本的变体。没有一个像SQL数据库一样快，而且都有优点/缺点。不过，对于大多数基于Internet的地图绘制应用程序而言，这种权衡似乎是合理的。同样，下面的两个需要与内存中的几何剔除（通过JTS等）结合使用，以删除任何不适合最终搜索参数的特征。最后，它们依赖于GAE特定的功能，但我确定它可以应用于其他体系结构（或使用TyphoonAE在Linux集群，ec2等上运行）
网格 -将特定区域的所有要素打包到已知的网格索引中。在网格上放置一个小的空间索引，以便您快速浏览其包含的一组要素。对于大多数查询，您只需要快速拉出少数几个网格，因为您知道确切的网格命名约定及其与K / V实体的关系（获取，而不是查询）
优点 -速度快，易于实现，无内存占用。
缺点 -需要进行预处理，用户需要确定网格大小，在多个网格上共享大几何，群集可能导致网格过载，序列化/反序列化成本可能成为问题（即使通过协议缓冲区压缩）
QuadKeys-这是当前的实现。基本上与Grid相同，只是没有设置网格级别。添加功能时，它们会由完全包含其范围的四键网格索引（或者在某些情况下，当无法使用单个四键时，请分成两部分，请考虑日期线）。找到qk之后，将其拆分为最大数量的较小qk，以提供该特征的更细粒度表示。然后将指向该功能的指针/ bbox打包到可以查询的轻量级gridindex（一组功能）中（原始设计直接查询该功能，但是事实证明这太慢了/在结果集很大的情况下占用大量CPU）
折线四键http://www.arc2earth.com/images/help/GAE_QKS_1.png折线四 键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
优点 -快速，无网格大小配置，无内存占用，无拥挤网格
缺点 -需要预处理，在某些情况下可能超量提取，没有极性数据
空间填充曲线 -看看今年Alfred在Google I / O上的NextGen Queries演讲。包含通用的空间/时间填充曲线以及新的MultiQuery运算符（并行运行）将允许进行一些非常酷的空间查询。它会击败传统的SQL性能吗？很难说，但它应该可以很好地扩展。而且，我们正在迅速接近一个未来，各种形状/尺寸的始终在线移动设备将极大地增加您的站点/服务的流量。
最后，我也同意在选择NoSQL而不是SQL之前，应该非常仔细地研究问题域。在我们的案例中，我真的很喜欢GAE的定价模型，因此确实没有选择，但是如果您不需要扩展，可以节省一些时间，而只使用标准的sql db
我听说过GeoCouch，它是基于位置数据的CouchDB的实现。而且我还认为MongoDB具有地理空间索引功能。
这主要是关于算法的问题。堆栈溢出也可能是个好地方。
无论如何，直接问题的答案是“是的，您可以使用kvp存储来表示空间数据。” 但是，更好的问题可能是“应该使用kvp存储代表空间数据吗？”
与其他许多问题一样，该问题的答案是“取决于”。这取决于您的规模，您的（事务性）工作负载，数据的性质以及您可以使用的计算基础结构。
kvp存储将具有较低的开销，这有助于增加大量插入和更新并行性的吞吐量。但是，执行空间搜索（查找矩形内的所有对象）不会很快。为此，您需要一个空间索引，例如R-Tree。
但是，如果您的数据量非常大，并且计算机集群很大，那么使用kvp索引可能会带来一些好处。真正确定的唯一方法是使用您期望遇到的实际数据和访问模式进行性能测量。
更新：
这里是更多信息。您可以使用KVP存储进行空间查找。问题是它很慢。要了解原因，请考虑以下内容：
***********
***********
***********
***********
****###****
****###****
****###****
***********
***********
***********
***********
其中*和＃代表对象，以11x11网格布局，原点位于左上角。想象一下在矩形（4,4）-（7,7）中搜索对象。那应该找到所有的“＃”。假设您使用b +树表示KVP存储中的索引，则可以使用“ X”索引或“ Y”索引找到结果。在这种情况下，哪一个都没有关系。为了便于讨论，我将使用x索引。您将在X索引中进行log（n）查找，以找到X值为“ 4”的第一个节点，然后遍历b + -tree叶子节点，直到找到一个值大于7的节点。遍历x索引，然后您将拒绝超出所需y范围的任何内容。
太慢了 想象一下，在一个具有相同密度（例如100 K * 100 K）的大型网格上。在那里，您最终不得不扫描“ 300，000”索引条目以仅找到9条记录。但是，如果使用适当平衡的R-Tree，则索引查找可能仅需要扫描大约90条记录。那是巨大的差异。
但是，问题是保持R-Tree平衡很昂贵。这就是为什么答案是“取决于”的原因，以及为什么问题“我应该这样做”比“我如何做”重要得多的原因。
如果您插入和删除记录很多，并且大多数情况下执行“对象ID”查找，并且不经常执行“空间”查找，那么使用KVP索引将为您实际想要使用系统的性能提供更好的性能。 。但是，如果您不经常插入或删除，但是经常进行空间查找，那么您想使用R-Tree。
在大多数情况下，与从键/值或键/值/类型存储相比，从关系数据存储中获得的实用性更高。有效查询和报告此类数据方案存在相当大的复杂性。
我的建议是在考虑如何使用NoSQL之前，仔细评估您的规模是否真正需要NoSQL。
MongoDB具有根据Documents的严格2d [x，y]元组属性创建和使用地理空间索引的功能，并且允许“近”和“边界”类型查询。但是，它不处理任何投影校正，并使用理想的平坦地球模型
我只会将键/值存储区用作缓存层，请参见http://www.membase.org/或http://wiki.basho.com/display/RIAK/How+Things+Work（riak_kv_cache_backend）
根据您的应用程序需求，您可能仍希望对数据具有SQL访问权限。
FOSS4G会议即将进行的一些演讲无疑是一个令人关注的新兴领域：