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

Add Doxygen Documentation for libcuspatial #534

Merged
merged 14 commits into from
Jun 1, 2022

Conversation

isVoid
Copy link
Contributor

@isVoid isVoid commented May 23, 2022

This PR adds doxygen documentation for libcuspatial.

In general, groupings to c++ APIs per our discussion on cuspatial method categories. There are 4 main categories:

  • spatial APIs
  • trajectory APIs
  • spatial indexing
  • spatial join

I took liberty on sub-categories and is subject to discussion and change, as part of discussion in #525 .

Many docstring for APIs were missing and are added in this PR. Such as factory methods in type_utils.hpp.

Some docstrings broke when being rendered in pages, such as point_in_polygon, these were also fixed.

@isVoid isVoid requested a review from a team as a code owner May 23, 2022 22:26
@isVoid isVoid requested review from cwharris and zhangjianting May 23, 2022 22:26
@github-actions github-actions bot added the libcuspatial Relates to the cuSpatial C++ library label May 23, 2022
Copy link
Member

@harrism harrism left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is awesome, what an improvement! Thanks very much. I just have minor fixes.

cpp/doxygen/main_page.md Outdated Show resolved Hide resolved
cpp/doxygen/Doxyfile Show resolved Hide resolved
cpp/include/cuspatial/experimental/type_utils.hpp Outdated Show resolved Hide resolved
cpp/include/cuspatial/experimental/type_utils.hpp Outdated Show resolved Hide resolved
cpp/include/cuspatial/experimental/type_utils.hpp Outdated Show resolved Hide resolved
cpp/include/cuspatial/haversine.hpp Outdated Show resolved Hide resolved
cpp/include/cuspatial/types.hpp Outdated Show resolved Hide resolved
cpp/include/cuspatial/types.hpp Show resolved Hide resolved
cpp/include/doxygen_groups.h Outdated Show resolved Hide resolved
cpp/include/doxygen_groups.h Show resolved Hide resolved
@isVoid
Copy link
Contributor Author

isVoid commented May 24, 2022

isVoid and others added 2 commits May 24, 2022 10:24
Co-authored-by: Mark Harris <mharris@nvidia.com>
@isVoid isVoid added doc Documentation non-breaking Non-breaking change 3 - Ready for Review Ready for review by team labels May 24, 2022
Copy link
Contributor

@vyasr vyasr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have some minor requests for changes and some points for discussion. I'd probably be OK with approving this PR even if you decide not to change any of them, but I think they are at least worth quick discussions before finalizing.

cpp/include/cuspatial/distances/linestring_distance.hpp Outdated Show resolved Hide resolved

/**
* @internal
* @brief Helper to convert a tuple of elements into a `vec_2d`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This question is out of scope for this PR, but why a tuple and not a pair? Issues with thrust::pair?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is a pair preferable to a tuple?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preferable is both subjective and circumstantial. As far as subjective arguments, on one hand we're making a 2d vector, which is exactly a pair of values, so it seems intuitive to use a pair. On the other hand I guess you could argue that you might want to generalize this to other dimensionality and returning a tuple across all dimensions would be more consistent. It's also convenient to use pair.first/second accessors rather than having to call a method.

As far as circumstantial arguments, the only real important thing that I can see is that in some situations you might care that pairs are standard layout while tuples are not. I don't think that really matters for us here.

I don't particularly think that we need to change this, just thought I'd check.

cpp/include/cuspatial/experimental/type_utils.hpp Outdated Show resolved Hide resolved
cpp/include/cuspatial/utility/vec_2d.hpp Outdated Show resolved Hide resolved
cpp/include/doxygen_groups.h Show resolved Hide resolved
cpp/include/doxygen_groups.h Show resolved Hide resolved
cpp/include/doxygen_groups.h Outdated Show resolved Hide resolved
cpp/include/cuspatial/spatial_join.hpp Show resolved Hide resolved
cpp/include/cuspatial/utility/vec_2d.hpp Outdated Show resolved Hide resolved
cpp/include/doxygen_groups.h Show resolved Hide resolved
@vyasr
Copy link
Contributor

vyasr commented May 31, 2022

I've addressed my own comments on this PR and I approve. I think we can continue further discussions on the appropriate groups etc in the future, but those shouldn't block merging of this PR.

@vyasr
Copy link
Contributor

vyasr commented Jun 1, 2022

rerun tests

@harrism harrism removed the request for review from zhangjianting June 1, 2022 06:54
@harrism
Copy link
Member

harrism commented Jun 1, 2022

@gpucibot merge

@rapids-bot rapids-bot bot merged commit d60fda3 into rapidsai:branch-22.06 Jun 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3 - Ready for Review Ready for review by team doc Documentation libcuspatial Relates to the cuSpatial C++ library non-breaking Non-breaking change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants