DOC: Improve STRtree docstrings

[brendan-ward]

Resolves #1622

Improves STRtree docstrings in an attempt to make it more clear that the tree is based on 2-dimensional bounding boxes. Also added a note about tree efficiency, but that might be overkill for the docstring and more appropriate for dedicated documentation on STRtree - which we have not yet created.

/cc @adishavit

[brendan-ward]

Test failures are unrelated, this is a doc only change

[jorisvandenbossche]

Test failures are unrelated, this is a doc only change

Yes, I am trying to fix those in #1625

[mwtoews]

Nicely written, and good to distinguish between a geometry's "extent" vs "bounding box", among several other details added.

[jorisvandenbossche]

good to distinguish between a geometry's "extent" vs "bounding box",

Apart from that "bounding box" is a clearer name (and I assume more people will understand it), what do you understand to be the difference between both? (my assumption was that GEOS uses "extent" term for bounding box)

[jorisvandenbossche]

Actually, in the STRtree API, they actually use "envelope", not extent (and also the property in shapely is envelope), so yet another term .. :)

[jorisvandenbossche]

Thanks for the clarifications! That are nice improvements, just one nitpicky comment

[adishavit]

I think it helps. That was my original misunderstanding. I would go further and mention `.bounds` too.

[mwtoews]

GEOS uses "extent" term for bounding box.

Yes, but as mentioned previously it is not widely understood as bounding box. Agree there are many terms for the same thing.

[coveralls]

Pull Request Test Coverage Report for Build 3551050299

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 84.754%

---

Totals
Change from base Build 3538932801:	0%
Covered Lines:	2218
Relevant Lines:	2617

---

💛 - Coveralls

[jorisvandenbossche]

Thanks!