pygeoapi
pygeoapi copied to clipboard
geopython
Provide a way to allow an implementer to map provider column names to provider names
Is your feature request related to a problem? Please describe. In our use case we have legacy tables where the column names are not human readable. We also have columns that we don't want to expose.
Describe the solution you'd like I'd like to come up with a way of adding configuration parameters to define a mapping of field names to property names. Initial implementation will focus on postgres provider but a general solution would be best.
@mbucknell, should we in stead consider to allow a sql query as a base for a datastore, in such a sql query you could limit and rename fields, but also create joins and filters. Geoserver knows this concept as sql views
But for sure at some point I guess we'll need some configuration options on the attribute level, and renaming the property could be one of them. I haven't checked #246 in detail yet, but I guess a json-ld encoding will require for example ontology-information for each attribute.
@pvgenuchten , I absolutely want to be able to allow a sql query as a base for a datastore. In fact, I'm going to explore that as part of the OGC/STAC hackathon. Trying to set up a postgres database with somewhat really data from our use case.
I have submitted a PR for an example implementation: https://github.com/geopython/pygeoapi/pull/302
As this is PostgreSQL, can't this be simply solved by creating a PG VIEW? Unless offcourse you are not allowed to modify the DB...And even then possibly could be solved at core API level? i.s.o a variant for each driver?
It could be solved by a view but it would be a database modification. Forgive my ignorance, but I'm not sure what you mean by solving at the core API level. Also I have implemented as a variant but I think that we can easily merge this code with the existing postgres provider. I wanted to get feedback before doing that.
Yeah, the goal here is that there are many organizations that may have an existing database table with a geospatial index, but the processes for making any actual database schema changes (including a materialized view) may be on a vastly slower timeline than the ability to deploy a web application. Generalizing from postgres to being able to support any database should probably be addressed in a separate issue, and probably only if someone actually expresses an interest in an RBDMS other than postgres/postgis
@jkreft-usgs From your last comment, then the idea would be for a generic RBDMS dataprovider based on SQLAlchmey (or another ORM).
Sure, I can see a goal of supporting a generic RBDMS, but my my limited understanding, spatial implementations between different database tools are quite different, so it might be a challenge.
...And even then possibly could be solved at core API level? i.s.o a variant for each driver?
@mbucknell sorry late reply: what I meant is that there is a common/core API handler api.py that intercepts all API requests and delegates methods like get_collection_items(self, headers, args, dataset, pathinfo=None) to the Provider configured for the dataset and returning/formatting the Provider response objects into e.g. JSON, before sending the response back to the remote client. My thinking was that column-mapping (in request and reverse in response) could be handled in api.py (i.s.o. Providers). But possibly I don't oversee all consequences. So let's go ahead with your PR #303 and we may refactor at a later time.
As per RFC4, this Issue has been inactive for 90 days. In order to manage maintenance burden, it will be automatically closed in 7 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}