[SERVER-18186] $geoWithin edge problems Created: 23/Apr/15 Updated: 04/May/15 Resolved: 04/May/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Geo |
| Affects Version/s: | 2.6.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | john gregorski | Assignee: | Siyuan Zhou |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||
| Steps To Reproduce: | Here's the REPL transcript.
|
||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
(I posted to the user group for help, see here: https://groups.google.com/forum/#!topic/mongodb-user/iOEDaxjDyHY) I make a square but can't find it via $geoWithin in cases where the query rectangle has some same edges as the square but not all same edges. But the $geoWithin docs say "When determining inclusion, MongoDB considers the border of a shape to be part of the shape, subject to the precision of floating point numbers." This happens in versions 2.6 and 3 |
| Comments |
| Comment by Siyuan Zhou [ 24/Apr/15 ] |
|
Hi John, Thank you for explaining the use case. I get that it's intuitive to have edges as part of a polygon. The workaround sounds good to me. The computation is very stable numerically, so the floating point errors should be very tiny, even though inevitable. Because collinear case means the determinant of a 3X3 matrix is zero numerically, a very tiny perturbation will break the tie. I am closing this ticket as duplicate of SERVER-17851. Feel free to update this ticket if you have any questions. Thanks, |
| Comment by john gregorski [ 24/Apr/15 ] |
|
Re how I encountered this problem: We have documents in our system summarizing info about square areas, e.g. a document to tell us that in the square with SW corner [37.8125,-122.25] and NE corner [37.84375,-122.21875] that there are N things of this sort, M things of that sort, etc. Clients ask for these documents in some larger coverage area, e.g. [37,-123],[38,-122]. That's when I noticed some docs not getting returned. I tried switching to $geoIntersect, but then got docs bordering the coverage square. As a workaround I am thinking I'll use $geoWithin with a slightly expanded coverage area to get all the included docs but not the bordering docs (hoping that the floating point errors are smaller than the slight expansion) ... |
| Comment by Siyuan Zhou [ 23/Apr/15 ] |
|
Thanks for reporting this problem. MongoDB cannot guarantee shared edges of a polygon are contained by the polygon. This is because it's expensive, if not impossible, to test whether three points are collinear due to the floating number errors. It is a known issue in SERVER-17851. We'll update the documentations to reflect the current behavior. Besides, I am interested in your application of "$geoWithin a polygon" and why it is useful for a polygon to contain its edges. Your feedback will help guide our design of geo features. Thanks, |
| Comment by Ramon Fernandez Marina [ 23/Apr/15 ] |
|
At first sight this looks like a duplicate of SERVER-17851, so you may want to read that ticket for more details. Please see also Will take a closer look soon and determine if this is the same issue reported on SERVER-17851 or a different one. Cheers, |