Open nielsbom opened 1 year ago
Thanks for the issue @nielsbom
I think this could be a useful area for PRQL. I imagine we could have a module in the stdlib such as geo
, so then geo.distance
compiles down to the appropriate SQL function.
Or is there something more ambitious we could do?
For transparency, I don't have much experience in the specifics of GIS, so open-minded.
From the standpoint of the language that would be exactly how it should work, yes.
We should be a bit cautious with adding functionality to the standard library, though. The standard library should be "designed" and not just inherit all quirks of some other API, it this case PostGIS. Because eventually, these functions could be implemented for some other database as well, and then we'd have to replicate all of the behavior we accepted into the std.geo
module.
An alternative approach would be to implement 3rd party modules, as outlined in #2491, so we can publish a postgis
module that one could pull into a project on demand. This module can be Postgres specific and does not have to obey the same versioning as the std module and the language in general.
This would be general approach for this kind of issues, I hear that Postgis has quite a nice API, so maybe we could just adopt it into the language.
What's up?
I'm using PostGIS for work and I'm wondering whether PRQL could also work with geospatial datatypes and functions? I'm not even sure whether this is a good idea or not btw.
I did not find an issue for this and after some global GitHub searching I also couldn't find any (open source) code. So maybe this issue could be the discussion people find when they want to use PRQL with geospatial data.
So: could this work? What would be a good place to build this? PRQL core, or an extension, or...?.