I was reviewing the 1D_regular example, comparing the various versions, noticed subtle shifts that slowly obfuscate the (admittedly silly) meaning of the original example.
- 40_1D_regular.xml: this seems to be the original source. Here the RangeType has swe:field name="adventskalendertuerchen" (Advent Calendar Doors), the range of the example coverage provides the series of numbers to be displayed on the doors (silly, but makes some sort of sense), while the range is comprised of the 31 days of December 2015
- 40_1D_regular.json: Similar, but unequal. The UoM is still "d" to represent the day number for the door, but the field name has gotten lost.
- 1D_regular.json: a new and de-proved version of the online JSON example, Domain and Range are still the same as in the original example, but now we have "definition": "http://opengis.net/def/property/OGC/0/Radiance" and "uom": { "code": "W.m-2.sr-1.nm-1" }, and the example loses all meaning (providing the values 1-31 as the radiance for the 31 days of December 2015, ah...?)
Would it maybe make sense to start at the beginning, first define a set of examples to be provided as a textual description paired with the content bits in a spreadsheet, then provide these examples in various encodings? Such an approach would surely help both us in creating consistent examples, as well as the poor reader trying to interpret them!
I was reviewing the 1D_regular example, comparing the various versions, noticed subtle shifts that slowly obfuscate the (admittedly silly) meaning of the original example.
Would it maybe make sense to start at the beginning, first define a set of examples to be provided as a textual description paired with the content bits in a spreadsheet, then provide these examples in various encodings? Such an approach would surely help both us in creating consistent examples, as well as the poor reader trying to interpret them!