ENH: Add option to use proj_normalize_for_visualization with CRS class

[snowman2]

According to PROJ docstring, it can be used with CRS class:

Related to geopandas/geopandas#1101 (comment)

• potentially useful for comparisons of CRS with different axis order (if it works)

Ideas:

1. Add is_equivalent() method to CRS and add ignore_axis_order=False kwarg to both is_equivalent() and is_exact_same() methods.
2. Add set_traditional_axis_order() method to CRS class.

[snowman2]

Looks like it was added here:
OSGeo/PROJ@109f75c#diff-1179756b8a4f716387cbbf34dcc14e32

I think this will be in PROJ 6.3.0. Related to #487

[jorisvandenbossche]

There is actually a PJ_COMP_EQUIVALENT_EXCEPT_AXIS_ORDER_GEOGCRS (https://github.com/OSGeo/PROJ/blob/42e981be8e89f7cfbd6f9cd3672c8e80560f61ad/src/proj.h#L567-L571) which is already available from 6.0.0 I think (similar to the PJ_COMP_STRICT and PJ_COMP_EQUIVALENT that are already used for is_exact_same and __eq__).

+1 on something like is_equivalent().
Potentially it could also subsume is_exact_same's functionality with an additional keyword (exact=True/False, ignore_axis_order=True/False, although those 2 keywords could never be used together, so that might not be the best API). It could also be a .equals(..) method that by default does the same as __eq__ but then can be made more strict or more flexible through such keywords.

[snowman2]

There is actually a PJ_COMP_EQUIVALENT_EXCEPT_AXIS_ORDER_GEOGCRS ...

Nice! I completely missed that. That is exactly what is needed here.

I like the idea if CRS.equals(..) . The name is shorter and have a familiar interface. However, the kwargs exact and ignore_axis_order could potentially conflict with each other. As you already mentioned, we already have CRS.is_exact_same(). So, keeping that separated would simplify things a bit. Maybe just adding CRS.equals(other_crs, ignore_axis_order=True/False) would work?

[snowman2]

Another option could be to add a method kwarg with the options of exact, equivalent, ignore_axis_order.