You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
I think this is a good idea. It will take some doing though.
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.
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.
From @efbenson:
Originally posted by @efbenson in #386 (comment)
The text was updated successfully, but these errors were encountered: