Before going for release v.1 (#20) I would suggest to do a review of the entire convention to tidy up the casual phrasing of certain terms and to weed out some other issues. A few examples:
- The convention should start out by defining what a CRS is, including a reference to an authoritative source. I do not think that we should assume that users do know the details and the convention starts off rather shakily with "This convention defines properties that encode datum and coordinate reference system (CRS) information for geospatial data." A CRS includes a reference frame (a more generic term for, and preferred over, a datum) and the datum part is not mentioned elsewhere in the convention. Later on: "A Coordinate Reference System (CRS) is the data reference system (sometimes called a 'projection') used by the asset data" - none of this is properly phrased for a Zarr convention.
- There are terms like "projection code" and "projection authority" that are too casual for a convention document. More formal equivalents, as used by OGC, are "CRS identifier" and "registry" (or "registrar"). It would be good to explain these terms on first use and then use them consistently.
- The "AUTH:CODE" string comes straight out of GDAL. GDAL splits the string into two parts and looks these up in proj.db. There is no regular expression which is quite possibly due to the fact that both terms can be pretty much anything between double quotes (
<quoted Latin text> in the WKT standard). The regular expression in the convention is therefore too restrictive, to the point that the provided example "IAU_2015:30100" would fail.
- The three fields have type
"string | null". Including the field with value null is not adding anything so I would propose to remove that option.
- The clause "At least one of
proj:code, proj:wkt2, or proj:projjson MUST be provided." is repeated after every field. These are superfluous because the restriction is already made at the top where the fields are first defined.
- Terms like "asset" and "client" could be improved or better defined.
Before going for release v.1 (#20) I would suggest to do a review of the entire convention to tidy up the casual phrasing of certain terms and to weed out some other issues. A few examples:
<quoted Latin text>in the WKT standard). The regular expression in the convention is therefore too restrictive, to the point that the provided example "IAU_2015:30100" would fail."string | null". Including the field with valuenullis not adding anything so I would propose to remove that option.proj:code,proj:wkt2, orproj:projjsonMUST be provided." is repeated after every field. These are superfluous because the restriction is already made at the top where the fields are first defined.