-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DISCUSSION] ST_DISTANCE
Method Namings
#607
Comments
Should mention the rule for when testing the same geometry, e.g. point-to-point distance. Is it named Should we consider making the distance metric a parameter of these methods? Then the current "haversine" distance would go away, and a haversine metric would be a parameter to Ultimately the types of the first and second geometries could be parameters of a higher level |
This issue has been labeled |
I think the discussion is settled. Closing. |
Orginally ported from #558 (comment)
Considering the
st_distance
covers many geometry combinations, there needs to be a way to make each distance primitive easy to find by users.File Organizations
All distances files should live under
distance
folder. Name of the file should include the name of geometries in the operation, ranking from low dimension to high dimension. For example, methods computing distances between point and linestring distance should be placed inpoint_linestring_distance.cuh
.Method namings
The method should be prepended with the parallel model, which could be either
pairwise
orall_pairs
. Followed by the type of the distance operator. In order to support reflected operation between geometries, there can be an extra argument "reflected" for control. For example,pairwise_point_linestring_distance
vectorizes computation between an array of point and an equal length array of linestrings.The text was updated successfully, but these errors were encountered: