triangulate() does not triangulate a PSLG with two holes correctly about rtriangle

[epipping]

I was puzzled by the fact that more than one hole wasn't properly triangulated at some point as well. Then I noticed that transposing H fixed the issue for me. If I continue to work with such a transposed H, I now get an error (albeit fortunately a rather helpful one). So even though the previous solution maybe shouldn't have worked, this is actually a bit of a breaking change...

The issue even goes a bit further: The case of no holes now needs to be special cased. I'm generating my list of holes through rgeos::gPointOnSurface(...)@coords inside sapply. To address the aforementioned issue, I now need to transpose the result. But if sapply is applied to an empty list, I'll get an empty list in return (previously an acceptable H), which is unchanged by t(), yet the pslg() constructor will always make sure the number of columns is equal to 2 now while the empty list has no columns.

Maybe it would be a good idea to carry out the number-of-columns check only after H is found to contain anything at all so that I don't need to pass a matrix(ncol=2,nrow=0)? I thought I'd at least suggest it...

[davidcsterratt]

Oh dear, I'd not realised this would break some things. However, the fix does now mean that pslg() is doing what it's documented to do. I'm a little anxious about adding sanitisation of empty lists, as I then feel I might need to document it. Also, perhaps then it would make sense to supply options for giving lists of hole coordinates... However, I'd be open to suggestions for patches.

[mdsumner]

Fwiw I post-process holes by testing if any triangle centroid falls in a hole, it's pretty efficient. This is in r-gris/trimesh in the tri_mesh function. It's not ready for general use yet but getting close.