-
-
Notifications
You must be signed in to change notification settings - Fork 261
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Convert coordinates to storage crs when filtering via cql #1489
Convert coordinates to storage crs when filtering via cql #1489
Conversation
The failing CI is unrelated to the changes contained in this PR, as mentioned in #1490 |
a938938
to
3b5850f
Compare
@ricardogsilva Hi 👋. I think the standards based approach to specifying the CRS of geometries in a CQL filter is via the |
hi @walkermatt thanks for the pointer 👍 I'll take a look at the spec and implement accordingly |
@ricardogsilva fantastic. Thanks for implementing support for EWKT in geopython/pygeofilter, it's a great help. |
@walkermatt I've now updated this PR to use a |
I've just updated my local copy of pygeoapi to use this PR branch and it's working well for me. I have a table in Postgres/PostGIS in EPSG:27700 with
|
@ricardogsilva found a small bug if the SRID is explicitly sent in the EWKT: # no CRS specified - pygeoapi assumes OGC:CRS84 by default
curl http://localhost:5000/collections/beni_confiscati/items?\
filter=DWITHIN(geometry,SRID=4326;POINT(12.626000006069875 41.8108000011414),100,meters) returns |
Overview
This PR implements conversion of geometries supplied in CQL filters to the storage CRS of a feature collection.
The main part of the implementation follows this logic:
pygeofilter.values.Geometry
, retrieve its CRS information or default to theOGC:CRS84
CRS if none is provided - CRS information is gotten from thefilter-crs
query parameter, if present - it can also be provided in the geometry definition, using EWKT notationstorage_crs
configuration option of the relevant provider, determine whether it is necessary to transform the geometry to match the same CRS and the one used by the providerThis PR includes the following related modifications:
pygeoapi.util.get_crs_from_uri()
has been refactored in order to support both URN and URL types of URI. This was done in order to accomodate the fact that pygeofilter is using the URN form internallythe logic to iterate through the pygeofilter node tree was previously only available inside the postgres provider. It has been moved out to the
pygeoapi.util.modify_pygeofilter()
function. This function now performs two checks:geometry
name to whatever name the provider specifies in itsgeom_field
configuration parameter - This is the same functionality introduced recently in Translate between genericgeometry
queryable name and the actual geom field name in postgres db #1453This PR enables the use cases mentioned in #1488, which is basically to use whatever CRS when defining a geometry in a CQL filter, and default to assuming
OGC:CRS84
.Example requests:
Note that regardless of the CRS being defined in the request, this PR makes pygeoapi ensure that it will always use the CRS of the underlying collection (as defined in its
storage_crs
configuration parameter), converting the filter geometry to the correct CRS if needed.Related issue / discussion
Dependency policy (RFC2)
Updates to public demo
Contributions and licensing
(as per https://github.com/geopython/pygeoapi/blob/master/CONTRIBUTING.md#contributions-and-licensing)