Pieter Roggemans

> I wouldn't count on "mild" canonical form having any particular permanence, as changes in the practical implementations of overlay code can and will change it over time. It's a...

If you would change this behaviour, please make it configurable, as I use this a lot to clean up slivers and almost dangling nodes after applying overlay operations...

Documentation wise, for a while now there has been a PR in the works to document (amongst others) this behaviour in the shapely docs: https://github.com/shapely/shapely/pull/1964/files Possibly the info in this...

I would guess it was just incorrectly implemented in shapely (pygeos) and nobody ever noticed?

I suppose @kylebarron is referring to the new flavour of writing introduced in pyogrio 0.8 that uses the arrow interface of GDAL (`write_dataframe` with `use_arrow=True`)? I think it is too...

> Indeed, I conflated "pyogrio engine" with "arrow interface". So on both the read side and the write side, users will need to pass `use_arrow=True` to use the arrow interface,...

The original reason this issue was opened has been "solved" in GDAL, by an alternative implementation of index creation that doesn't need extra parameters for increased memory usage: https://github.com/OSGeo/gdal/issues/7614

FYI, not 100% same as what is being discussed here, but somewhat related: for e.g. GPKG files GDAL already reads multithreaded is some circumstances: > OGR_GPKG_NUM_THREADS=value: (GDAL >= 3.8.3) Can...

> Also note that there are some parts of the openeo python client code base that are programmatically generated (e.g. "openeo/processes.py"). It takes more effort to make this setup black...

> > While making the changes in #524, they were mixed with changes made by black > > This is a bit intended because we currently use `darker` instead of...