Change `range-subset=` to `properties=`
Closed this issue · 7 comments
The selection of range values to return in the output of a coverage request is very similar to the selection of properties in Features and of parameter names in EDR. I suggest that we standardize on the use of properties= throughout the OGC API, also with the advantage that this will feel much more familiar to non-expert developers, for whom range may easily have a domain connotation (e.g. the range of coordinates for which you request values), confusing this with the domain set subsetting operation (subset=).
(related to #155)
I agree that "range" is one of the most unnatural names we could have selected but, with time, I got used to it.
In SensorThings is called "observedProperties". In the Python XArray are called "data variables". In addition, there are now discussions about Essential Variables (Such as the ones for Climate: Essential Climate Variables). Properties and Variables seem natural names to me. I agree that ranges names in coverages and property names in features are equivalent concepts and I'm in favor of any effort to bring coverage and feature world closer.
(this is assuming that we forget about the GFM where features has attributes and some attributes are "geo" and some are not. I do not think we can play this game in coverages. Actually geojson has completely forgotten about this for good).
"range" has been established long before my time, which means a thing ;-) Stemming from the functional view...maybe another name could have been found, but I agree with Joan: we all got used to it.
"property", otoh, is one of the most general words around. To me that means one suboptimal term is substituted by another suboptimal term, at the price of years of confusion and without improvement. Any better name around?
In API- EDR, we used parameter-name as it was what our users were used to, for a long time too.
We considered much geospatial terminology off-putting for the non-specialists.
We also considered the O&M terminology, observedProperty, but thought it misleading in non-observational cases.
property seemed too generic to be helpful.
The other short-listed candidate was variable - something that varies with postion/time. We didn't use it because sometimes the quantity does not vary much with time (e.g. orography). I admit that is a feeble argument.
We did start using parameter but that was definitely confusing because OpenAPI/Swagger got it first, so moved to parameter-name!
HTH
The most important objective of the OGC API family of standards in my opinion is that these specifications present consistency, and do not differ merely because of terminology a sub-community got used to. The goal is to bring these sub-communities closer together enhancing interoperability and unlocking new possibilties in the process. OGC API - Features talks about feature properties. O&M has observed properties.
It seems clear to me that properties= is a simple obvious choice for commonality. Despite it being generic, there is no possible confusion about what this refers to -- the observed (or measured, or sensed?) is implied but omitted for a shorter query parameter name.
We discussed in the SWG today and thought that perhaps fields= would be another option, aligning with what the RangeType response contains.
SWG 2022-02-09: Members present suggest to go forward with properties.
We will accept the decision in two weeks from now if we do not get any objection or otherwise proceed with a vote.
SWG 2022-02-23: The two weeks have passed and no new objection has been raised, therefore moving this issue to accepted changes to be applied.