Refactored sqlalchemy-related parsing of geometry

[ricardogsilva]

This PR refactors parsing of geometries done in the sqlalchemy backend in order to recognize custom CRS definitions.

Further discussion in #66

Included also a couple of tests which should clarify the result of the proposed modification.

• fixes Is Pygeofilter supporting various CRS other than 4326? #66

[francbartoli]

Failing test would be fixed after the merge of #87

[tomkralidis]

@ricardogsilva can you rebase (will also trigger CI)? Thanks.

[ricardogsilva]

@tomkralidis done

[Alex-NRCan]

Thank you for pulling this code in 👍

If I may ask, as this fix was pulled a few months ago, is there an intention to create, in the near future, a new release of pygeofilter? I'm asking, because it'd be great if pygeoapi could, natively, when doing its pip install, benefit from the changes to the parse_geometry function fixed herein. Otherwise, at the moment, here at Natural Resources Canada, I have to maintain a copy of a modified pygeofilter code for our pygeoapi usage and when we deploy.

[francbartoli]

I hope so @Alex-NRCan, if I may suggest you could install pygeofilter from the master branch as a workaround. With or without a docker image

[Alex-NRCan]

For the purpose of follow-up.
The release 0.2.4 of July 10th includes the aforementioned fix now and therefore pygeoapi can install itself with a fixed version of pygeofilter hence automatically supporting CQL queries with different crs better. No need (at least for our usecase and my tests) to work with a distinct clone of pygeofilter anymore. Yay! 👍
Seems fully resolved, for pygeoapi usage, as of July 10th 2024. Best regards.