Header-only refactoring of points_in_spatial_window

[harrism]

Fixes #564

A couple of notes:

1. For clarity and generality, this name for the header-only version of the function is now copy_points_in_range() rather than points_in_spatial_window(). This is the reflect that it is a range filter, and we may want to enable constraining the dimensions of the range in the future.
2. I have renamed the parameters for the range delimiters and clarified their documentation. This API is not limited to Cartesian coordinates and the documents make that clear by specifying that the input points and the range limits are specified using points in the same coordinate system. It also uses "quadrilateral" rather than "rectangle", since in lon/lat (spherical) coordinates the range is not a rectangle, but it is a quadrilateral.
3. Note that the change to the iterator-based API means that the user is responsible for allocating the output (as they are with STL and Thrust). Therefore, they need a way to know how much to allocate. In addition to the header-only copy_points_in_range(), this PR also adds a new function, cuspatial::count_points_in_range().

Previously, the cuDF-based API used cudf::copy_if, which does the equivalent of both of the above functions and returns a properly sized pair of columns. The new column-based implementation calls count_points_in_range, then allocates the result columns, and then calls cuspatial::copy_points_in_range().

[isVoid]

Only several minor comments. At first I find it striking to see the refactor breaks the original function into two kernel calls. Later I realized cudf::copy_if does two kernel launches internally (one pass to count the output size and another pass to copy the result).

[harrism]

Only several minor comments. At first I find it striking to see the refactor breaks the original function into two kernel calls. Later I realized cudf::copy_if does two kernel launches internally (one pass to count the output size and another pass to copy the result).

Yes that's what I explained here: #579 (comment)

[isVoid]

Just some doc related issue.

[thomcom]

Specify cartesian coordinates, I think.

[thomcom]

Down the road this, along with pip, would be really effective if they took a coordinate system pair as arguments.

[harrism]

Actually I don't think we have to limit this to cartesian coordinates. This is effectively a 2D range query. There's no reason you can't use lonlat points and a 2D lonlat range.

[harrism]

(In the future we may want to replace this API with a generic ND range query API...)

[thomcom]

I don't think that's strictly true - lon/lat is not cartesian. There exist points along a line of longitude that fall inside of the spherical "rectangle" defined by a lower left and upper right pair of coordinates that do not fall inside of the cartesian rectangle that is defined by those same coordinates.

[harrism]

The API doesn't specify that the points are in any projection -- they can be Cartesian, Lon/Lat, or anything else, as long as the query window and the points are coordinates in the same dimensions. This is a good reason to replace this with an API called "points_in_range" or something like that.

[harrism]

I've renamed the APIs and clarified the docs. See commit #88e7ee1 and after.

[harrism]

Did you create a new file for the new tests? I see one new test, Empty, and that you renamed the file from .cpp to .cu, but I don't see an all points or edge test.

@thomcom I think you went looking in an old commit for new changes. :) Click "Files Changed" at the top or see here: 464cbcc

[harrism]

@gpucibot merge