docs(geospatial): add examples for duckdb supported methods

[ncclementi]

Description of changes

• Add docstring examples for duckdb geospatial functions

Issues closed

Closes #7959

TODO/Problems/need help

• Understand why CI is broken and fix it.
• Make sure examples render properly in CI, I can't get the docs to build locally because of seg fault (xref BUG: Seg Fault when st_aswkb() to arrow duckdb/duckdb_spatial#236)
• Need to figure out quarto syntax to include in the geospatial expressions page point (which is in numeric types)
• Decided what to do about a few methdos that are specific to LineStrings and the zones example doesn't contain such type of geometry.

[cpcloud]

Thanks for churning through this!

Can you also apply ruff format .? The version of ruff listed in pyproject.toml should automatically format the code in docstrings.

[ncclementi]

The failures I'm seeing are weird, because the expected and the result match. This is only happening for the operations that return geometries. The only difference I see is that the result seems to be truncated shorter than the expected value. But I'm not sure if that can be the problem.

[gforsyth]

The failures I'm seeing are weird, because the expected and the result match. This is only happening for the operations that return geometries. The only difference I see is that the result seems to be truncated shorter than the expected value. But I'm not sure if that can be the problem.

It's a character-by-character check, so having the results displayed in fewer columns will break the doctests

[ncclementi]

It's a character-by-character check, so having the results displayed in fewer columns will break the doctests

@gforsyth ok, this makes sense, but I'm using whatever is the default but what gets produced on my end but that doesn't seem to match whatever CI is producing.

[gforsyth]

@gforsyth ok, this makes sense, but I'm using whatever is the default but what gets produced on my end but that doesn't seem to match whatever CI is producing.

yeah, it's frustrating. The output gets resized depending on terminal width, so I would recommend narrowing your terminal (and then making note of how many columns you want the output to take up)

[gforsyth]

yeah, it's frustrating. The output gets resized depending on terminal width, so I would recommend narrowing your terminal (and then making note of how many columns you want the output to take up)

The github actions terminal is set to an 80 character width. Might be possible to change that, but for now, I would just set your terminal to that for generating the doctest outputs

[ncclementi]

Ok getting closer.
The ones failing, I'm expecting them to fail (kind off) because of #8143 but, somehow that is working on CI, though the output is different because I was not able to create the expected output locally.

[ibis-docs-bot]

Docs preview: https://pr-8128-efa28abdba3e124f26a6dc626f38bc407a6a5c7f--ibis-quarto.netlify.app

[ncclementi]

I think this is ready for a final look, got to render the NumericValue.point in the geospatial expressions page too. I think it looks good.

EDIT: Not so fast!

• (It's been green for couple CI runs now, I'd merge and keep and eye) looks like sometimes we ran into the spatial extension not being loaded (see this CI job) for the literal cases. bug: geospatial literals don't work out of the box with the default backend #8143
• FIXED: For some reason the literals examples are not rendering as they should, I'm not sure why. For example (This happens when you miss the "s" in Examples)
  

[ibis-docs-bot]

Docs preview: https://pr-8128-ad765e0ec94780fc001f5bae4ff069758305e41a--ibis-quarto.netlify.app

[cpcloud]

SWEET 🚢 it!

[ncclementi]

This is ready for final review.

We'll solve/discuss the literals issue #8143 in a separate PR.