Reproject `always_xy` is true

[evetion]

Which goes against the defaults in GeoDataFrames, Proj (both our wrapper and the library itself). However, there's something to say for always defaulting to true, both for ease of use, performance of GeoInterface.x (and y) and related methods. The Rust Proj crate does also default to true https://docs.rs/proj/latest/proj/struct.Proj.html#a-note-on-coordinate-order.

@rafaqz @visr

[rafaqz]

I think it should be true pretty much everywhere in the ecosystem. To me crs specifying point order was a mistake, and order switching due to a reprojection is basically never what the user expects or wants.

(we also ignore it in GeoInterface.x, so... )

I guess the main case is where the user is doing nothing manual and somehow is interacting with other packages. Like probably we should write points in the correct order? And using always_xy kind of breaks that. So there is a conflict between expectations in interactive use, and writing correct files.

Plotting is also an issue, we would need to flip everything for Makie based on crs. Its doable just a lot of work for it to always be correct.

[asinghvi17]

So I just experimented with Proj. If we extract the CRS after the transformation is constructed we should get a "correct" crs that we can attach to the object, with correct axis order. Then any file written is at least not technically incorrect. And a user can always set always_xy=false if they want the "defined" behaviour.

[evetion]

I think you're looking for https://proj4.org/en/stable/development/reference/functions.html#c.proj_normalize_for_visualization