Mark Harris

> Yet another simpler solution is just to add documentation and make the requirement on matching between poly_offsets and poly_ring_offsets clear. No change to our code is needed. Users just...

Another suggestion, from @isVoid: https://github.com/rapidsai/cuspatial/pull/497#issuecomment-1082621159 > would it be helpful to add an example of input to help demonstrate the use of the API?

@hakantekbas in #497 I improved the documentation of this function in the C++ and Python APIs. We have not yet corrected the notebook or taken further steps to make the...

@trxcllnt would you be able to knock this out while adding the header-only API?

@isVoid I think you have made progress on this issue with recent PRs. Could you perhaps add a checklist to track what remains?

Is turfjs implemented in Javascript? For your small-ish data size (O(100K) boats) you may not even need a GPU, just a better CPU implementation (e.g. in C++)

> Ideally, the above APIs should look like: > > `def directed_hausdorff_distance(points: cuspatial.GeoSeries):` Hmmm, this ignores the spaces in the Hausdorff distance API. This is a directed all-pairs distance computation....

I like this direction. API looks much cleaner. As long as we provide factories / converters from other layouts / dataframes.

Wow, I didn't know that. We are kind of relying on pretty deeply hidden implementation details of Thrust here, which makes me a tiny bit nervous.

#669 made it so that this isn't an issue as long as we use `expect_vector_equivalent`.