我正在从不同来源收集位置信息，并将所有内容存储在 MongoDb 集合中。除了具有单个 lat/lng 坐标的点位置外，我还存储区域。
现在，一个数据给了我GeometryCollection 的位置信息，但所有元素都是Polygons。另一个数据源给了我MultiPolygon 的位置。虽然我实际上正在考虑为每个数据源收集一个集合，但我想知道哪种方法总体上更好。
GeometryCollection 当然更灵活，但也许MultiPolygon 显示更好的查询性能（假设我总是在位置字段上创建2dspehere 索引）。将一种表示转换为另一种表示是否值得？
【问题讨论】：
标签： mongodb geospatial geojson spatial-index
好消息：MongoDB 中所有支持的 GeoJSON 类型的查询性能和可索引性都相同。
您决定的主要驱动因素应该是您的地理字段信息架构和使用它的软件是否需要包含更多类型而不仅仅是多边形。你说你在存储点位置？如果您想将所有地理数据保存在单个字段中，例如location（并且可能带有 2dsphere 索引）然后您将需要GeometryCollection，您可以将Point 和MultiPolygon 放入其中。在 GeoJSON 规范中建议 https://www.rfc-editor.org/rfc/rfc7946#page-9 not 嵌套 GeometryCollection，因此对于那些为您提供 GeometryCollection 的数据源，您将迭代内容并填充您自己的 GeometryCollection你的Points 等等。
如果您要单独存储积分，例如eventCenter 与eventAreasEffected 分开，那么eventCenter 可以只是一个Point 而eventAreasEffected 可以是一个单一的'MultiPolygon'；不需要GeometryCollection。在多个字段中拥有 geo 并且在这些字段上拥有或不拥有多个 2dsphere 索引是完全可以的。从 MongoDB 4.0 开始，您可以通过包含 key 选项对具有多个 2dsphere 索引的集合使用 $geoNear。
这是一种非官方但合理的定义方法：MultiPolygon 不是Polygon 的任意集合，而是恰好具有不相交多边形的单个“形状概念”。美国可以用一个MultiPolygon 来描述，其中有阿拉斯加、夏威夷、美国大陆，可能还有波多黎各等。事实上，为此，您会注意到存储与MultiPolygon 的每个成员，因为 coordinates 只能是点数组的数组。例如，关于第三个多边形的信息必须在对等字段中传送到单个顶级coordinates 字段。但是Polygon 的离散数组或Polygon 的GeometryCollection 可以以each 形状存储额外信息。请注意，除了 type 和 coordinates 之外，GeoJSON 和 MongoDB 都不会限制您为每个形状添加字段。
一个更微妙的问题是GeometryCollection 与Polygon 与MultiPolygon 的设计和语义。更复杂的是，Polygon 中定义的显式漏洞与由地理软件在数据库外部进行后处理的隐式“分层”Polygon 集合存在问题。
【讨论】：
Point 的点，（b）一个用于位置字段为 MultiPolygon 的区域（如果只有一个多边形数组的长度仅为 1)。现在我不认为我会在MultiPolygon 中为每个形状/多边形提供单独的信息，但你的观点是有效的。我不喜欢当前的设计——尤其是使用 2 而不是 1 集合——但很高兴知道性能不是一个因素。
这个主题的问题是没有一个好的答案。 这一切都与您将喜欢或需要什么有关。这是在 stackExchange 上写的一个很好的答案。
而且我不知道 GeometryCollection，所以不能告诉你任何关于它的事情。但是这个链接会向你透露很多信息。
【讨论】：
GeometryCollection 只允许将多边形、线和点放入同一个位置对象中。当然，这允许GeometryCollection 可能只包含多边形，据我所知，这使得它在概念上与MultiPolygon 对象相同。我只是想知道在使用这些位置类型查询大型集合时是否存在性能差异。