Paul Ramsey
Paul Ramsey
Well, flipping it back to catching `std::exception` lets this test case pass, and also all the unit tests pass... so? I honestly cannot quite remember the logic around this, so...
Mixed collections are handled better in modern releases, this branch is not going to get any further love.
But with a non-mitre end-cap? (I kind of wonder what a mitre even means in the case of polygon buffer/unbuffer)
You specified mitre in your description so I wondered if you were seeing it having an effect. I agree, for polygons it should be a no-op.
Or an interaction with some element of the input that is itself has a size of exactly 2?
Actually the question of "return `POLYGON()` or return `MULTIPOLYGON()`" for single-item collections seems a little fraught... doing so over a set could result in a heterogeneous set of POLYGON/MULTIPOLYGON instead...
There should be some material added to the documentation to explain this new feature. Also, I could not quite see what kinds of user-facing errors are returned if the system...
That's a good question and without looking at the code, the /index.json end point should still be available and will trigger a refresh?
In the limit, the existing rules of the road are fine: check for validity with isValid(); expect things to fail in exciting ways if your geometry is not valid; fix...
I think a few extra things need to be added to the summary. On the utility of non-finite coordinates, I agree with the summary, there is none. However, we do...