[DOC/QST] Scale parameter in quadtree methods

[buckeye17]

The API documentation describes the scale parameter as, "Scale to apply to each point’s distance from (x_min, y_min)." While this is comprehensible, I'm struggling to understand why someone would want to change it. Is it so that the location data can be kept in coordinate reference frame, while outputs for trajectories, etc. can be given in another? I've looked over the demos and examples and can't find any explanation for why this feature is useful, and I'm not sure how it affects the quadtree results, if at all. Thanks for any clarification you can provide!

[zhangjianting]

quadtrees work on a discrete space. scale, together with x_min and y_min, defines the configuration of the grid that a quadtree works on. The smaller the scale, the more rows/columns of the grid and typically the larger and the deeper of the resulting quadtree. That being said, the tradeoff between filtering and refinement (for spatial join and other query types) when utilizing quadtree indexing does not have a definite relationship with scale (or grid resolution). Ideally, a "smarter" indexing technique can determine scale automatically but it is still pretty much an open research question. As such, cuspatial allows users to specify scale for better control. It is understandable that some background expertise is needed. Hopefully the slides at following link can provide some additional info https://github.com/zhangjianting/cuspatial/blob/fea-spatial-join/docs/quadtree_indexing_spatial_join.pdf

[github-actions[bot]]

This issue has been labeled inactive-90d due to no recent activity in the past 90 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.

[github-actions[bot]]

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.

[harrism]

We should add more of an explanation as provided by @zhangjianting to the documentation for this function.

[github-actions[bot]]

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.

[harrism]

@trxcllnt can you add the explanation as part of your refactoring?

[github-actions[bot]]

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.

[harrism]

We need to update the documentation here: https://github.com/rapidsai/cuspatial/blob/930a2f33953ce1abe8f0680ebbf418675db4b362/python/cuspatial/cuspatial/core/spatial/indexing.py#L35

We should also provide default values for scale, max_depth.

Also the Python API for min_size needs to be updated to match max_size in the C++ API.

Discussion:

• Scale is not a great name, since we divide by it. Almost a normalization factor?

[harrism]

@trxcllnt can we also consider this issue fixed by #797 ?