Refactor lonlat_to_cartesian to header-only API #514
Conversation
Co-authored-by: Jake Hemstad <jhemstad@nvidia.com> Co-authored-by: Paul Taylor <paul.e.taylor@me.com>
…ial into fea-header-only-haversine
cpp/include/cuspatial/experimental/detail/coordinate_transform.cuh
Outdated
Show resolved
Hide resolved
| CUSPATIAL_EXPECTS(origin.x >= -180 && origin.x <= 180 && origin.y >= -90 && origin.y <= 90, | ||
| "origin must have valid longitude [-180, 180] and latitude [-90, 90]"); | ||
|
|
||
| return thrust::transform(rmm::exec_policy(stream), |
There was a problem hiding this comment.
I was wondering, for methods that does not fit into the transform framework (e.g. linestring instance kernel that launches on num_points and writes to num_segments output), what's the STL convention to follow? cc @jrhemstad
There was a problem hiding this comment.
What exactly at your looking for? An example of an algorithm that operates on N inputs and produces M outputs where N != M?
Stream compaction algorithms like copy_if are one example ( M <= N).
Offhand I can't think of algorithms where M >= N. Maybe set_union?
@codereport would be the real guru to ask here.
There was a problem hiding this comment.
For pairwise linestring distance the input the data structure is segmented, and each pair of segments (non-geometric meaning) map to a single value. It's like segmented reduction with two value input iterators.
There was a problem hiding this comment.
@isVoid Do you mean two elements at a time are mapped to a single value? Something like this:
Prelude> [1..10] -- [1,2,3,4,5,6,7,8,9,10]
Prelude> chunksOf 2 [1..10] -- [[1,2],[3,4],[5,6],[7,8],[9,10]]
Prelude> map sum . chunksOf 2 $ [1..10] -- [3,7,11,15,19]There was a problem hiding this comment.
@codereport no. Two separate segmented input arrays. Equal number of segments in the two arrays, but corresponding segments need not have the same length. Apply an operator to corresponding pairs of segments.
|
rerun tests |
|
@gpucibot merge |
Following #477, implements the header-only API for
cuspatial::lonlat_to_cartesianand implements existing C++ API on top of it.Follows the refactoring guide introduced in #477.
Note this branch is based on the branch for #477 so diff includes all changes from that PR as well. Once #477 is merged this PR will simplify a lot.