How should we process the 22 outstanding CoverageJSON issues

[chris-little]

The original specification has about 20 issues outstanding. We need to discuss which can be addressed and incorporated into the proposed OGC Community Standard (assuming strong backward compatibility) and which are future work or enhancements.

Should we copy them across to here, or leave them in the original repo?

[lewismc]

@chris-little +1 for copy here. I'll do that in 72 hrs if there are no objections.
Some basic metadata tagging will allow us to organize and prioritize.

[chris-little]

@lewismc +1 to your idea. Tagging or naming them so we can filter them from those required to get the Community Standard across the finishing line.

[chris-little]

@lewismc As we are:

1. Making good progress with addressing the Vote comments;
2. Producing a schema for conformance testing;
3. Setting up project framework in the repo;
   could you transfer across the 20 outstanding issues from the original COvJSON repo please?

[jonblower]

@chris-little @lewismc could we chat about this before transferring the issues please? There may be some that could be closed, or left where they are. I'm just trying to figure out how to best organise things between the original and OGC repos in general. (Sorry I missed the call yesterday.)

[chris-little]

@jonblower @lewismc Does this list of Issue titles help? We could edit while we discuss, then bring across the agreed list.
[Updated with annotations from @letmaik in later comment]
covjson/specification#95 needs discussion
covjson/specification#94 needs discussion
covjson/specification#93 needs discussion
covjson/specification#91 CLOSED
covjson/specification#88 crs 5 tasks
covjson/specification#86 needs discussion
covjson/specification#82 CLOSED
covjson/specification#81 needs discussion
covjson/specification#78 CLOSED
covjson/specification#75 needs discussion CLOSED
covjson/specification#71 needs discussion CLOSED
covjson/specification#66 needs discussion 1.0 CLOSED
covjson/specification#63 needs discussion CLOSED
covjson/specification#61 needs discussion CLOSED
covjson/specification#60
covjson/specification#55 needs discussion 1.0 CLOSED
covjson/specification#45 needs discussion 1.0
covjson/specification#38 needs discussion future CLOSED
covjson/specification#32 needs discussion future CLOSED
covjson/specification#29 needs discussion future CLOSED
covjson/specification#15 needs discussion 1.0 CLOSED
covjson/specification#3 needs discussion future CLOSED

[lewismc]

OK to state the obvious it looks like there is a lot of discussion needed. Can the ones without a qualifying comment can be moved over?

[letmaik]

I commented on and closed 13 of those issues for various reasons: out of scope, not an issue, etc.

The remaining ones are:

Ideally looked at before first release:

• Potentially backwards-incompatible: CRS Definitions in CovJSON covjson/specification#88
• Potentially backwards-incompatible: Allow for polygons to be labelled covjson/specification#94

Can be deferred to a future version:

• Comparison: Compare and contrast CoverageJSON with CF-NetCDF covjson/specification#60
• Comparison: CovJSON, CF-JSON and NCO-JSON covjson/specification#86
• Backwards-compatible: Define "preferredColor" for observed property categories or remove from playground example covjson/specification#95
• Backwards-compatible: Regularly spaced temporal axis? covjson/specification#93
• Backwards-compatible: Describing ParameterGroup objects covjson/specification#81
• Backwards-compatible: How to identify the meaning of a time axis? covjson/specification#45

[jonblower]

Thanks for doing this @letmaik!

How about we move the "comparison" discussions to this (OGC) repo, as they are not so much about CovJSON itself, but more about its place in the world?

From my point of view, I'd like to discuss 88, 93 and 94 a bit further, as we've had specific user requests about these topics. It would be good to establish whether we need them for a first release.

I agree that the other tickets can wait until a future version. The "multiple time axes" one (number 45) is something that @chris-little has flagged before, so he might want to consider making this in scope for the first release too. But my feeling is that there won't be many people wanting to create CovJSON objects that have two time axes (although they may very well want to interrogate a back-end dataset that has them). I wonder how this would interact with the behaviour of an API like EDR?

[chris-little]

@jonblower I am happy for multiple time axes to be deferred to a later version.
As for the API-EDR, there is a presumption that there are 4 coordinates for any data (x,y,z,t), but we are adding to the maintenance release next week the support for the possiblity of further 'coordinate' axes, consistent with the other OGC APIs such as API-Coverage.

[chris-little]

@letmaik @lewismc @jonblower @jerstlouis After Maik's helpful comments, I will create new issues in this repo for the outstanding topics.

[jonblower]

Do the issues have to be moved here, or could we direct people to the original repo? I'm just a bit worried about duplication. Perhaps we could discuss on the call before moving?

[chris-little]

@jonblower I have copied , so people can pursue issues in either place, unless we decide otherwise. Let us discuss and close issues and leave their counterparts open, as we agree.
I am keen that the CoverageJSON repo does have a full recognition of the issues with the format, even if discussions take place elsewhere.

[chris-little]

2022-03-23 agreed to close as all relevant issues now have a current entry in this repo.