You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (Created) (JIRA)" <ji...@apache.org> on 2011/11/29 23:59:41 UTC
[jira] [Created] (LUCENE-3610) Revamp spatial APIs that use
primitives (or arrays of primitives) in their args/results so that they use
strongly typed objects
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-3610) Revamp spatial APIs that use
primitives (or arrays of primitives) in their args/results so that they use
strongly typed objects
Posted by "Hoss Man (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159718#comment-13159718 ]
Hoss Man commented on LUCENE-3610:
----------------------------------
That's one example ... some of the other methods i was mentioned deal with (either as an argument or as a result) two element arrays of doubles ... which one comes first in the array? ... you can't fix that by renaming the variable.
in either case: is there really any downside against having a simple object that wraps the latlon pair so you *always* know which one is which? is the RAM/GC overhead of an object like i described really significant compared to a double[2] ?
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-3610) Revamp spatial APIs that use
primitives (or arrays of primitives) in their args/results so that they use
strongly typed objects
Posted by "Yonik Seeley (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159729#comment-13159729 ]
Yonik Seeley commented on LUCENE-3610:
--------------------------------------
bq. in either case: is there really any downside against having a simple object that wraps the latlon pair so you always know which one is which?
We should always do lat first (and I believe we do).
bq. is the RAM/GC overhead of an object like i described really significant compared to a double[2] ?
The object (compared to a double[]) could actually be better - no array bounds checks. If you're only talking about replacing double[2] w/ an object, I'm all for it. Otherwise, it's case by case - it depends if it's going to be used in an inner loop.
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-3610) Revamp spatial APIs that use
primitives (or arrays of primitives) in their args/results so that they use
strongly typed objects
Posted by "Yonik Seeley (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159714#comment-13159714 ]
Yonik Seeley commented on LUCENE-3610:
--------------------------------------
I think we should just avoid using "x" and "y", and use "lat" and "lon".
The error was in parameter naming only, but was never apparent to me because when I saw "x", I thought "first parameter" which is "lat" in a lat,lon pair (and this is why the params were always passed correctly... it didn't cause confusion until someone with more geo experience looked at it).
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org