[SERVER-772] geo polygon searches Created: 17/Mar/10 Updated: 12/Jul/16 Resolved: 14/Apr/11 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 1.9.0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Eliot Horowitz (Inactive) | Assignee: | Greg Studer |
| Resolution: | Done | Votes: | 27 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Comments |
| Comment by auto [ 13/Apr/11 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: exact results for polygon searches |
| Comment by Greg Studer [ 12/Apr/11 ] |
|
Still should address precision issues in polygon searches. |
| Comment by auto [ 12/Apr/11 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: cache bounding boxes no distance required |
| Comment by auto [ 12/Apr/11 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: randomized polygon test for |
| Comment by auto [ 12/Apr/11 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: converted to new geohash expand algorithm currently uses non-exact matching logic |
| Comment by auto [ 12/Apr/11 ] |
|
Author: {u'login': u'bgianfo', u'name': u'Brian Gianforcaro', u'email': u'b.gianfo@gmail.com'}Message: Add the new GeoPolygonBrowse which uses a point a ray A general unit test was added also for the plugin was added also |
| Comment by Mathias Stearn [ 01/Mar/11 ] |
|
@Germán: no, the 2d index is only for storing points, not shapes. |
| Comment by Germán Sáez [ 10/Feb/11 ] |
|
I'm not sure if this would help me with my current problem. Find below the description: 1. There are venues (e.g shops) stored as documents in the database. Their location is represented as a single point. 2. There are big venues (e.g. airports, parks) stored as documents in the database. Their location is represented as a polygon (array of ordered points = vertexes) instead of as a single point. 3. I need to search (=GeoNear) for the venues around certain coordenates and get back venues whose location is either defined as a single point or a polygon. 4. Bare in mind that I could be near the polygon (e.g. close to one of the edges) but far from its vertexes so a search engine that only check that my coordenates are near the vertexes wouldn't work. In other words, would I be able to use GeoNear() to get the distance between a single point an a polygon? Would this fix help me with my problem? |
| Comment by Andy Ennamorato [ 27/Jan/11 ] |
|
I guess this is a separate issue, but wanted to put in a request for 'finding bounding regions containing a query point.' I mentioned this at MongoBoulder to Kyle and some of the other folks, but it would be fantastic (not to mention a huge advantage over other doc data stores) to query MongoDB for which stored polygons contain a point. Polygon intersection (which polygons intersect with this one?) and other geospatial-ly features would be great, too. Thanks for considering it. |
| Comment by Mathias Stearn [ 25/Jan/11 ] |
|
This ticket is for finding all points within a bounding polygon. Finding bounding regions containing a query point (geocoding) is a different problem and will probably require a different index type since the current one is only for storing points, not shapes. |
| Comment by Justin Palmer [ 14/Jan/11 ] |
|
I think what Carlos is speaking of and what the patch implement are two separate use cases. The proposed patch would return all points within a given bounding box, while Carlos' proposal would return all bounding boxes containing a particular point. It's not 100% clear which one of these scenarios are covered by this ticket. I see value in both of them. |
| Comment by Carlos Rodriguez [ 10/Jan/11 ] |
|
The commit above doesn't enable much in the way of geocoding, which I think would be a huge use case. To geocode, a given point must be checked against geometry stored in mongo. Here's a possible syntax, following the GeoJSON spec (http://geojson.org/geojson-spec.html#geometry-objects) mypoint = {type: "Point", coordinates: [-123.45, 34.56]}; ...where the "geometry" property is a GeoJSON-compliant geometry object of a polygon. A variety of geometric functions could be implemented using this syntax. Perhaps the GEOS library (http://geos.osgeo.org/) could be incorporated as an optional build option, to support some of the more exotic geometric stuff. I would probably use this feature on a daily basis if it was part of mongoDB. For the moment I've implemented equivalent functionality in PHP at https://github.com/carlos8f/metageo |
| Comment by Eliot Horowitz (Inactive) [ 12/Nov/10 ] |
|
working with a contributor on getting a patch merged |
| Comment by Eliot Horowitz (Inactive) [ 29/Oct/10 ] |
|
Patch here: |
| Comment by Carlos Molina [ 21/Oct/10 ] |
|
After benchmarking against PostGIS, all we need to switch our entire vast amount of geospatial data crunching to mongodb is this feature. +1 |
| Comment by Michael Stephens [ 30/Sep/10 ] |
|
Polygon indexes is the one thing preventing my project from dumping postgres entirely. Specifically we need to store various political boundaries (US state borders, legislative district boundaries, zip code areas, etc.) and then query which polygons a given point is within (being able to query which polygons a different given polygon is completely or partially contained within would be a plus, too). |
| Comment by Chris Griego [ 27/Mar/10 ] |
|
+1 for adding this feature. I want the ability to do queries based around Flickr's Shapefiles public dataset. |