-
Notifications
You must be signed in to change notification settings - Fork 8
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
add version to payload #162
Comments
Yes, I think that's a sensible idea. This could maybe go into v1.1. I guess it would have to be optional or "strongly recommended" in order to preserve backward compatibility. |
+1. PR in #163 (not sure if master branch is still 1.0 bound). |
@tomkralidis @jonblower We had better leave Master Branch as V1.0 until @ghobona confirms it is published and we can make master v1.1 (or V1.0.1). |
@ghobona @tomkralidis @jonblower I have created a V1.0 tag/release, so we can start developing CoverageJSON V1.1 on the Master branch. So, providing @ghobona has no objection, I propose we merge PR#163. |
Note that we would have to update the JSON schema to accommodate this and other changes in 1.1, in parallel with the spec |
It would be valuable for a CoverageJSON payload to identify conformance (similar to OGC API - Records. Example:
While clause 10 of the DP provides guidance on further qualifying the media type with conformance, would it also be valuable to add to the payload itself (to self identify independent of the transfer mechanism)?
The text was updated successfully, but these errors were encountered: