API considerations

Hi,
I am just reviewing this package and have some remarks about the API of inpolygon.

The untyped input argument p obiously expects a vector-like object, which contains the x and y coordinate of the point to be processed. I think, it would be a better idea to allow for multiple input points to be processed in one go.

The untyped input argument poly expects a vector of vectors of x-y- coordinates. Here I see a potential performance bottleneck, if that is compared to a nx2 matrix.
There is also a restriction of generality, because describing the polygon only by a list of vertices does not allow unconnected components, as it is used. The sample data found in inpoly-bench-data are are not easily or not at all translated to this restricted format. Again I would propose toe use a mx2 matrix for the vertices and add an extra integer mx2 matrix to define the edges more liberately.

For the output data stat a vector of integer values in {-1,0,1} is returned. I would expect stat == 0 for on boundary, and abs(stat) == 1 for not on boundary, more intuitive than you have.

Start by reviewing the inpolygon API and the sample data in inpoly-bench-data. Separate the proposals for batch point processing, polygon and edge representation, and stat semantics, then seek a maintainer decision on scope. Done requires an agreed API design and corresponding implementation and validation plan.