Skip to content
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

Closed
isVoid opened this issue Jul 28, 2022 · 3 comments
Closed

[DISCUSSION] ST_DISTANCE Method Namings #607

isVoid opened this issue Jul 28, 2022 · 3 comments
Assignees
Labels
doc Documentation
Milestone

Comments

@isVoid
Copy link
Contributor

isVoid commented Jul 28, 2022

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 in point_linestring_distance.cuh.

Method namings

The method should be prepended with the parallel model, which could be either pairwise or all_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.

@harrism
Copy link
Member

harrism commented Jul 28, 2022

Should mention the rule for when testing the same geometry, e.g. point-to-point distance. Is it named pairwise_point_to_point_distance or pairwise_point_distance?

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 pairwise_point_distance. directed_hausdorff_distance would become all_pairs_point_distance with a directed_hausdorff metric parameter.

Ultimately the types of the first and second geometries could be parameters of a higher level distance() API which dispatches to these lower-level APIs.

@jarmak-nv jarmak-nv added this to the ST_Distance milestone Aug 2, 2022
@jarmak-nv jarmak-nv moved this to Todo in cuSpatial Aug 2, 2022
@harrism harrism moved this from Todo to In Progress in cuSpatial Aug 6, 2022
@harrism harrism removed the Needs Triage Need team to review and classify label Aug 24, 2022
@github-actions
Copy link

This issue has been labeled inactive-30d due to no recent activity in the past 30 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed. This issue will be labeled inactive-90d if there is no activity in the next 60 days.

@isVoid
Copy link
Contributor Author

isVoid commented Apr 7, 2023

I think the discussion is settled. Closing.

@isVoid isVoid closed this as completed Apr 7, 2023
@github-project-automation github-project-automation bot moved this from In Progress to Done in cuSpatial Apr 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Documentation
Projects
Status: Done
Development

No branches or pull requests

3 participants