1. 03 Jul, 2017 1 commit
    • antirez's avatar
      Fix GEORADIUS edge case with huge radius. · b2cd9fca
      antirez authored
      This commit closes issue #3698, at least for now, since the root cause
      was not fixed: the bounding box function, for huge radiuses, does not
      return a correct bounding box, there are points still within the radius
      that are left outside.
      
      So when using GEORADIUS queries with radiuses in the order of 5000 km or
      more, it was possible to see, at the edge of the area, certain points
      not correctly reported.
      
      Because the bounding box for now was used just as an optimization, and
      such huge radiuses are not common, for now the optimization is just
      switched off when the radius is near such magnitude.
      
      Three test cases found by the Continuous Integration test were added, so
      that we can easily trigger the bug again, both for regression testing
      and in order to properly fix it as some point in the future.
      b2cd9fca
  2. 05 Dec, 2016 1 commit
    • antirez's avatar
      Geo: fix computation of bounding box. · 001138ae
      antirez authored
      A bug was reported in the context in issue #3631. The root cause of the
      bug was that certain neighbor boxes were zeroed after the "inside the
      bounding box or not" check, simply because the bounding box computation
      function was wrong.
      
      A few debugging infos where enhanced and moved in other parts of the
      code. A check to avoid steps=0 was added, but is unrelated to this
      issue and I did not verified it was an actual bug in practice.
      001138ae
  3. 27 Jul, 2016 1 commit
    • antirez's avatar
      Multiple GEORADIUS bugs fixed. · 356a6304
      antirez authored
      By grepping the continuous integration errors log a number of GEORADIUS
      tests failures were detected.
      
      Fortunately when a GEORADIUS failure happens, the test suite logs enough
      information in order to reproduce the problem: the PRNG seed,
      coordinates and radius of the query.
      
      By reproducing the issues, three different bugs were discovered and
      fixed in this commit. This commit also improves the already good
      reporting of the fuzzer and adds the failure vectors as regression
      tests.
      
      The issues found:
      
      1. We need larger squares around the poles in order to cover the area
      requested by the user. There were already checks in order to use a
      smaller step (larger squares) but the limit set (+/- 67 degrees) is not
      enough in certain edge cases, so 66 is used now.
      
      2. Even near the equator, when the search area center is very near the
      edge of the square, the north, south, west or ovest square may not be
      able to fully cover the specified radius. Now a test is performed at the
      edge of the initial guessed search area, and larger squares are used in
      case the test fails.
      
      3. Because of rounding errors between Redis and Tcl, sometimes the test
      signaled false positives. This is now addressed.
      
      Whenever possible the original code was improved a bit in other ways. A
      debugging example stanza was added in order to make the next debugging
      session simpler when the next bug is found.
      356a6304
  4. 06 Jul, 2016 4 commits
  5. 30 May, 2016 2 commits
    • antirez's avatar
      Geo: fix typo in geohashEstimateStepsByRadius(). · 5d4b5fbd
      antirez authored
      I'm the author of this line but I can't see a good reason for it to
      don't be a typo, a step of 26 should be valid with 52 bits per
      coordinate, moreover the line was:
      
          if (step > 26) step = 25;
      
      So a step of 26 was actually already used, except when one of 27 was
      computed (which is invalid) only then it was trimmed to 25 instead of
      26.
      
      All tests passing after the change.
      5d4b5fbd
    • antirez's avatar
      Fix GEORADIUS wrong output with radius > Earth radius. · 4eff3dc4
      antirez authored
      Close #3266
      4eff3dc4
  6. 29 Jun, 2015 2 commits
  7. 26 Jun, 2015 1 commit
    • antirez's avatar
      Geo: from lat,lon API to lon,lat API according to GIS standard · fa9d62d3
      antirez authored
      The GIS standard and all the major DBs implementing GIS related
      functions take coordinates as x,y that is longitude,latitude.
      It was a bad start for Redis to do things differently, so even if this
      means that existing users of the Geo module will be required to change
      their code, Redis now conforms to the standard.
      
      Usually Redis is very backward compatible, but this is not an exception
      to this rule, since this is the first Geo implementation entering the
      official Redis source code. It is not wise to try to be backward
      compatible with code forks... :-)
      
      Close #2637.
      fa9d62d3
  8. 24 Jun, 2015 1 commit
    • antirez's avatar
      Geo: Fix geohashEstimateStepsByRadius() step underestimation. · 55c4a365
      antirez authored
      The returned step was in some case not enough towards normal
      coordinates (for example when our search position was was already near the
      margin of the central area, and we had to match, using the east or west
      neighbor, a very far point). Example:
      
          geoadd points 67.575457940146066 -62.001317572780565 far
          geoadd points 66.685439060295664 -58.925040587282297 center
          georadius points 66.685439060295664 -58.925040587282297 200 km
      
      In the above case the code failed to find a match (happens at smaller
      latitudes too) even if far and center are at less than 200km.
      
      Another fix introduced by this commit is a progressively larger area
      towards the poles, since meridians are a lot less far away, so we need
      to compensate for this.
      
      The current implementation works comparably to the Tcl brute-force
      stress tester implemented in the fuzzy test in the geo.tcl unit for
      latitudes between -70 and 70, and is pretty accurate over +/-80 too,
      with sporadic false negatives.
      
      A more mathematically clean implementation is possible by computing the
      meridian distance at the specified latitude and computing the step
      according to it.
      55c4a365
  9. 22 Jun, 2015 2 commits
    • antirez's avatar
    • Matt Stancliff's avatar
      [In-Progress] Add Geo Commands · 7f4ac3d1
      Matt Stancliff authored
      Current todo:
        - replace functions in zset.{c,h} with a new unified Redis
          zset access API.
      
      Once we get the zset interface fixed, we can squash
      relevant commits in this branch and have one nice commit
      to merge into unstable.
      
      This commit adds:
        - Geo commands
        - Tests; runnable with: ./runtest --single unit/geo
        - Geo helpers in deps/geohash-int/
        - src/geo.{c,h} and src/geojson.{c,h} implementing geo commands
        - Updated build configurations to get everything working
        - TEMPORARY: src/zset.{c,h} implementing zset score and zset
          range reading without writing to client output buffers.
        - Modified linkage of one t_zset.c function for use in zset.c
      
      Conflicts:
      	src/Makefile
      	src/redis.c
      7f4ac3d1