Michael Kirk

> *Looks at https://link.springer.com/content/pdf/10.1007/s00190-012-0578-z.pdf and immediately passes out You know it's going to be a good paper when a bunch of the citations are from the 19th century (and one...

Some maybe related discussion on point-to-polygon distances https://github.com/locationtech/jts/issues/929

> Thanks for the thorough review! Should the inline pr merge as part of https://github.com/georust/geo/issues/816? Also, I suspect we may want to sprinkle a few more inlines in other geotypes....

Another thought, as I've been iterating on this, is it would be nice if we had an explicit use case to evaluate the 3d+ geometries against. You know how sometimes...

My concern is that this is an intrusive change, and that it is going to be hard to back out if it proves to be the wrong approach. Is there...

What's the goal of removing patching? It's a pretty commonly used approach. And if someone is building within the georust/geo workspace (as in they've checked out the code and are...

> and it worked wonderfully, without requiring patches that pointed to unreleased git branches. Just to make sure we're on the same page here, the changes in this commit will...

To help me understand, can you lay out a specific "bad" scenario that might plausibly arise if we did not merge this PR?

As I understand it, the scenario of concern is: If the unreleased commits in the dependency (e.g. proj) get deleted, then people might not be able to build the unreleased...

I'm still not really sold on the changes in this PR. I expect people who have checked out the repo and are building the local workspace are going to be...