Bugs and deficiencies

Known issues

• This module is not believed to be thread-safe. In specific:

  • The SetUpDistance(…) function stores the first point's position in global variables.

    To fix this, DistanceFrom*(…) and DistanceTo(…) would need to be removed plus SetUpDistance(…) and HaversineDistance*(…) would need to be combined into a single 4-argument HaversineDistance*(…) function.
    Calling code would need to be modified as appropriate. In terms of performance, the
    overall cost of doing this is likely quite low.

  • The search code stores distances computed for a specific search into the point datastructures. If multiple concurrent searches are run against a single index then distances computed by one search may overwrite those from another search.
    This can lead to inconsistent results.

    To fix this a per-search distance hash would need to be maintained. This could have serious performance implications and would preclude returning the point distances within the point hashes. The distances could, however, be returned in an additional datastructure.

  • Adding and deleting points to/from the index is not atomic. Running e.g. a search while points are being added or deleted can lead to unpredictable behavior (up to and including the program crashing).

    One could fix this by adding object-level locks:

    • Block concurrent calls to the Index(…) and DeletePointIndex(…)methods
    • Block calls to the Index(…) and DeletePointIndex(…) methods while searches are running
    • Block calls to Search(…) et al. when the Index(…) or DeletePointIndex(…) methods are active
    • Likewise, calls to Sweep(…) and Vacuum(…) should block (and block on) everything.

• Including the same point in multiple indices or searches at the same time could lead to interesting results.

  As mentioned above, this is due to the storage of search result distances within the points and not within the index object. Each search that involves a given point will likely overwrite its search_result_distance value.

  This could be encountered in a number of ways. For example, a search using a condition function that itself runs a search against the second index could be problematic. This could be encountered even when using a single index. For example, if code relies on the distances values from a search it should save a copy of them before running subsearches against the same set of points. If this is not done then the distance values from the first search may be overwritten by those of the subsequent searches.

• Geo::Index uses the spherical haversine formula to compute distances. While quite fast, its accuracy over long distances is poor, with a worst case error of about 0.1% (22 km). Since the module already has provision for changing the backends used for the distance methods, adding a new backend to, for example, compute accurate distances on e.g. a WGS-84 spheroid would be simple and straight-forward.

• In places the code can be repetitious or awkward in style. This was done because, especially in the inner loops, speed has been favoured over clarity.

Reporting bugs

Please submit any bugs or feature requests via this repository's issue tracker, to bug-geo-index at rt.cpan.org or through the CPAN bug tracker web interface. In any case I will receive notification when you do and you will be automatically notified of progress on your submission as it takes place. Any other comments can be sent to akh@cpan.org.