GH-3320: Support non-euclidean distance for geosparql#4016
Merged
Conversation
…computation routing
afs
changed the title
afs
reviewed
Jun 24, 2026
…ntopological/filter_functions/DistanceFFTest.java Co-authored-by: Andy Seaborne <andy@apache.org>
Contributor
Author
|
Thanks for the suggested commit - I definitely butchered the language of "non euclidean" vs the core issue of it being units related ^_^. |
afs
approved these changes
Jun 25, 2026
Member
|
This is a "go" from me. I'll leave it a few days so that everyone has a chance to take a look at it (please add a review or a comment if it "LGTM" for you). |
rvesse
approved these changes
Jun 25, 2026
Member
|
And noted to go in the release announcment. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
GitHub issue resolved #3320
Pull request Description:
This PR supports computing distance with linear units. To do this we make use of the great circle... DistanceFF.java currently hardcodes the distance to be Euclidean however, the generic distance method already has routing to select the appropriate distance function (as per the reporting ticket). The comment on the changed line refers to geosparql 1.0 only supporting euclidean distances! With Geosparql 1.1 we can now support others so I believe this change is in line with the spec.
I don't think we need to do any doc updates for this; I don't see any language about different unit support and this is the least restrictive so I think we're good there.
By submitting this pull request, I acknowledge that I am making a contribution to the Apache Software Foundation under the terms and conditions of the Contributor's Agreement.
See the Apache Jena "Contributing" guide.