Matt Richards

I can verify this is the case, I think I'm missing something here, because this seems to just be the same as https://github.com/geopandas/geopandas/issues/3406. Is there something else you're pointing out...

I think your last sentence is the key point. Current geopandas will only read geoparquets, with the geoparquet metadata, no regular parquets without geometry and no parquets written via arrow...

Just to round out from me - looking again today, I certainly think we should have a tool for reading these "geometry parquets which aren't geoparquets", and a PR exploring...

Agree with Martin that there's no realistic way to implement a change like this given the api breakage, especially given that there is a quite simple if not so elegant...

I'm going to close this as there's nothing realistically actionable here. Can be reopened if we find a way to progress.

> I'm working on some open-source project that doesn't use pixi, so I add my own `pixi.toml`. Ideally I could just leave that and the rest of the pixi files...

@cosmicBboy I'd be interested in trying to help out with this too - but it sounds like it makes the most sense to wait until you've done some structural setup...

@romaingd-spi this originates upstream in pyproj - which is not supressing the warning internally due to the performance hit - see https://github.com/pyproj4/pyproj/issues/1307. Given this, there's not really a whole lot...

I understand the rationale with wanting to make this change, and appreciate that since you're building tools leveraging geoarrow you're getting more exposure to people using it than I am...

>Design problem: I usually don't expect imports to have side effects on code without explicitly using the imported module. Practical problem: Linters like ruff, black, etc. remove the import line...