Skip to content
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

Provider method for metadata #524

Open
rgwozdz opened this issue Mar 24, 2023 · 1 comment
Open

Provider method for metadata #524

rgwozdz opened this issue Mar 24, 2023 · 1 comment
Labels
enhancement LOE: high Level Of Effort: high

Comments

@rgwozdz
Copy link
Member

rgwozdz commented Mar 24, 2023

From @efbenson:

As I play around with getting the related layers working with a custom provider it feels like returning massive metadata and other "configuration" data on the geojson object is getting to be a bit cludgy. Maybe it would be possible to add some additional functions on the Model class for that. Something like getLayersConfiguration(host, id) or something like that where we could return the static configuration about the layers. IMO that would also provide a cleaner way of generating the data for the /layers rest endpoint

Originally posted by @efbenson in #386 (comment)

@rgwozdz
Copy link
Member Author

rgwozdz commented Sep 13, 2023

I think this is a good idea. It will take some doing though.

  1. koop-core already includes pullLayer and pullCatalog methods. I think pullLayer was intended to get metadata for a layer. pullCatalog is a little ambiguous as a "catalog" in ArcGIS can mean a collection of data from various sources, but pullCatalog would only describe a single provider's "catalog". But if you think about this from the feature service perspective a provider's catalog might be built of many different "services" as defined by the providers URL parameters (i.e., id and or host). So pullCatalog might be difficult for providers to support. It might be better to go in a more generalized direction and add a pullMetadata method to Koop-core's model implementation, and have providers implement a getMetadata method.

  2. For use in FeatureServer, routes that could use pullMetadata would need a specialized handler as opposed the existing generalized handler that leverages pullData/getData. We would want to fallback to pullData/getData in the event that the provider doesn't include a getMetadata method.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement LOE: high Level Of Effort: high
Projects
None yet
Development

No branches or pull requests

1 participant