EG, Issue #45 Improving rtree distance with Haversine

[evageier]

Changed map_edge_rtree_object and map_vertex_rtree_object with Haversine functionality

[robfitzgerald]

@evageier the PR isn't passing the Rust CI/CD because of a test that is failing. you can run tests locally to see this via cargo test --manifest-path rust/Cargo.toml.

i believe the problem is actually in the design of the test, as it's not using valid coordinate values. we would want to change the test case's vertex file to fix this. any numbers will do as long as they are isomorphic to the current values (i.e., the triangular relationship between the vertex locations remains consistent).

[robfitzgerald]

@evageier pinging you regarding my previous comment in case you missed it

[evageier]

I think the issue is with converting the system from the coordinates -> lat/lon for Haversine

[robfitzgerald]

@evageier as discussed, please roll in your latest changes here and add documentation. tag me when it's up, i'd like to try running the test case on my side and review your debug messaging. thank you! 🎸

[evageier]

@robfitzgerald With these new coordinates in rtree_vertices.csv, we still have the problem of the NearestSearchResult::NearestVertex giving Vertex(0) instead of Vertex(1) for test coordinate (-121.843872, 39.066114).

I was able to figure out that (1) our Haversine function should be working, but it might be good to change let a = (d_lat / 2.0).sin().powi(2) + (d_lon / 2.0).sin().powi(2) * lat1.cos() * lat2.cos();

to a = (d_lat / 2.0).sin().powi(2) + lat1.cos() * lat2.cos() * (d_lon / 2.0).sin().powi(2); [haversine.rs] just to be following the ordering of the formula - should give the same result though.

(2) Switching from f32 -> f64 doesn't resolve the problem (I literally changed all files to use f64, and still the issue persisted). Still, it might be worth discussing further whether that switch could be a safe guard against precision issues in the future.

(3) The iteration through vertexes 0-2 to find the closest to the test coordination stopped at vertex 0 for the first point: (-121.843872, 39.730426) which returns vertex 0 correctly. However, for the second point: (-121.843872, 39.066114), first the distance to vertex 0 is calculated correctly (62556.98226607894 m^1) and then to vertex 1 (correctly: 2418.2760363883153 m^1), clearly a shorter distance. Yet, Vertex 0 is returned to be the shorter point.

We discussed how (3) could be the result of rtree metrics versus our Haversine - radian measurements.

[evageier]

@robfitzgerald With these new coordinates in rtree_vertices.csv, we still have the problem of the NearestSearchResult::NearestVertex giving Vertex(0) instead of Vertex(1) for test coordinate (-121.843872, 39.066114).

I was able to figure out that (1) our Haversine function should be working, but it might be good to change let a = (d_lat / 2.0).sin().powi(2) + (d_lon / 2.0).sin().powi(2) * lat1.cos() * lat2.cos();

to a = (d_lat / 2.0).sin().powi(2) + lat1.cos() * lat2.cos() * (d_lon / 2.0).sin().powi(2); [haversine.rs] just to be following the ordering of the formula - should give the same result though.

(2) Switching from f32 -> f64 doesn't resolve the problem (I literally changed all files to use f64, and still the issue persisted). Still, it might be worth discussing further whether that switch could be a safe guard against precision issues in the future.

(3) The iteration through vertexes 0-2 to find the closest to the test coordination stopped at vertex 0 for the first point: (-121.843872, 39.730426) which returns vertex 0 correctly. However, for the second point: (-121.843872, 39.066114), first the distance to vertex 0 is calculated correctly (62556.98226607894 m^1) and then to vertex 1 (correctly: 2418.2760363883153 m^1), clearly a shorter distance. Yet, Vertex 0 is returned to be the shorter point.

We discussed how (3) could be the result of rtree metrics versus our Haversine - radian measurements.

Accidentally committed twice!

[robfitzgerald]

@evageier please update this branch so that cargo test compiles, then i can begin my review. may just be as simple as un-commenting spatial_index.rs:135 but i didn't want to make any assumptions and wanted to be sure it is set up the way that matches your mental model of the problem.