-
Notifications
You must be signed in to change notification settings - Fork 9
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
Support for OGC API Styles #43
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this nice contribution and for your interest in the project!
First, the way we have designed APIs so far was mostly driven by usage. If you have a sample of application code that can demonstrate how these new features will be leveraged, that would help a lot with deciding which way to go!
One thing I can say is that so far we used a principle of 1/ get a list of identifiers and 2/ get a full object from an identifier. So, kind of like what you suggested:
allStyles
would return an array of idsgetStyle(styleId)
would return a complete object
And then typically the application code can read stuff from the complete object, e.g. a list of supported formats, and then call getStylesheetUrl
with a given format.
Your approach matches most of this process, which is great! One thing that can make things easier to use would be to:
- rename
getStyleMetadata
intogetStyle
for clarity - only read style metadata from the metadata.json document, instead of parsing it both from the endpoint and the metadata documents (i.e. the
parseStyles
andparseBaseStyleMetadata
functions) - do not include the links in the returned Style object; links are usually not given back to the application code (IIRC), they only have a technical role and ogc-client should allow consumers to not care about links
I hope this is clear. I'm not super familiar with the Styles spec which means I might have misunderstood some things. But again, this looks like a very solid start already!
It's a client which allows to import styles from an OGC API. Right now I don't have a code sample unfortunately. Maybe later. The basic requirements would be:
Sounds very reasonable, I'll change that part!
Thanks! |
Had some time today to implement the changes. I also rebased the branch, so here is the diff: LukasLohoff/ogc-client@b8664f6...LukasLohoff:ogc-client:ogc-styles As suggested, |
I have tested the updates, and everything works!! I do have a few suggestions regarding the styles. Perhaps we could consider implementing the following endpoints for more granular access to styles based on collections:
These changes could also help us get styles from this OGC API service: https://maps.gnosis.earth/ogcapi/ Additionally, I'm wondering about the necessity of the Looking forward to your thoughts on this! |
👍
Definitely sounds useful! I totally forgot about the collections in combination with styles, as the services I used for testing didn't have them. I think this is something we will also need at some point for our application. What would you prefer?
Correct, all information returned by
What's your opinion on this? |
@LukasLohoff here is what I would suggest:
As for collection-specific styles:
Collection-specific styles can be done in a followup PR if needed, no problem 🙂 As for error handling, this is the policy we use:
Thank you for your commitment! |
contains smaller improvements: - remove redundant listAllStyles - merge getStyleMetadata into getStyle and handle fallback internally
Hi @jahow first of all, sorry for the delay. Implemented your suggestions and also added support for collections. I didn't add the Instead of adding additional methods for collections I chose to add an optional parameter instead. If you want to change the API design, that's of course also fine. It just made more sense for me when implementing it. Another way would be switching to an options parameter approach, because having multiple parameters can be confusing. e.g.: await endpoint.getStylesheetUrl({
id: 'Tritanopia',
mimeType: 'application/vnd.ogc.sld+xml;version=1.0',
collectionId: 'airports'
}); Let me know what you think. Here are updated example snippets (note that allStyles is now a function): Get a list of styles: await endpoint.allStyles(); Get a list of styles for a collection: await endpoint.allStyles('airports'); Get style metadata: await endpoint.getStyle('Deuteranopia'); Get style metadata for a collection: await endpoint.getStyle('Deuteranopia', 'airports'); Get stylesheet URL for a collection: await endpoint.getStylesheetUrl(
'Tritanopia',
'application/vnd.ogc.sld+xml;version=1.0',
'airports'
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much! This looks very good. Thank you for committing to this valuable contribution!
This attempts to add basic support for styles. For now just retrieving styles is supported.
Examples:
Get a list of available style identifiers:
Get a list of styles (includes the supported formats, which you need for
getStylesheetUrl
):Get style metadata:
Get stylesheet URL from metadata (or style document):
Some questions / notes:
OgcApiStyleDocument
is needed - you could also useOgcApiDocument
here if you add astyles
subproperty. This would remove the need for casting sometimesallStyles
currently gets all its information from the styles endpoint. There might be a link to a json representation for each style which contains more information. Maybe another function such asgetStyle({styleId})
is useful here?For testing I mainly used the ldproxy demos at https://demo.ldproxy.net/ and https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi
Happy for any suggestions or feedback!