Closed AndrewAnnex closed 1 year ago
ahhhh it's true that when we started rio-tiler/titiler we never though about other planets 😄
I think one quick
fix could be in rio-tiler.
instead of having coord_crs: CRS = WGS84_CRS,
we could have something like
def point(
self,
lon: float,
lat: float,
coord_crs: Optional[CRS] = None,
indexes: Optional[Indexes] = None,
expression: Optional[str] = None,
**kwargs: Any,
) -> PointData:
kwargs = {**self.options, **kwargs}
coord_crs = coord_crs or self.geographic_crs
(same for the part() and feature() methods)
at the same time we could add a coord_crs
, bounds_crs
and shape_crs
option on the endpoints too
okay I can probably start a PR on rio-tiler to start transitioning things over there. I think it may still be useful, but potentially complicated, to allow queries in arbitrary crs's on titiler's side, but then we'd need to consider what encoding for the CRS parameter to support (just authority/code? URIs?, URNs? any input pyproj accepts?)
but then we'd need to consider what encoding for the CRS parameter to support (just authority/code? URIs?, URNs? any input pyproj accepts?)
I think the dependency should process any string by using rasterio.crs.CRS.from_user_input
method.
I'll make a PR here, I think we can wait for rio-tiler
Problem description
using the point value endpoint, I noticed that there is no way to specify the CRS of the lon/lat of the input leading to issues when working with non-earth CRSs (example).
the rio_tiler point method does accept a
coord_crs
parameter that could be used to address this issue. I'd hope it would be possible to update titiler to use the geodetic_crs for the COG or to allow the user to specify the CRS as an optional parameter.That could also be useful if the user wanted to provide coordinates in a different projection/unit but could be an over compilation. Alternatively another endpoint could be added to accept a query point in native coordinates (with no attempts to reproject)
Expected Output
correct point values for various CRSs