Revamp spatial APIs that use primitives (or arrays of primitives) in their
args/results so that they use strongly typed objects
-------------------------------------------------------------------------------------------------------------------------------
Key: LUCENE-3610
URL: https://issues.apache.org/jira/browse/LUCENE-3610
Project: Lucene - Java
Issue Type: Improvement
Components: modules/spatial
Reporter: Hoss Man
Fix For: 4.0
My "spatial awareness" is pretty meek, but LUCENE-3599 seems like a prime
example of the types of mistakes that are probably really easy to make with all
of the Spatial related APIs that deal with arrays (or sequences) of doubles
where specific indexes of those arrays (or sequences) have significant meaning:
mainly latitude vs longitude.
We should probably reconsider any method that takes in double[] or multiple
doubles to express latlon pairs and rewrite them to use the existing LatLng
class -- or if people think that class is too heavyweight, then add a new
lightweight class to handle the strong typing of a basic latlon point instead
of just passing around a double[2] or two doubles called "x" and "y" ...
{code}
public static final class SimpleLatLonPointInRadians {
public double latitude;
public double longitude;
}
{code}
...then all those various methods that expect lat+lon pairs in radians (like
DistanceUtils.haversine, DistanceUtils.normLat, DistanceUtils.normLng,
DistanceUtils.pointOnBearing, DistanceUtils.latLonCorner, etc...) can start
having APIs that don't make your eyes bleed when you start trying to understand
what order the args go in.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
