prushforth
commented
3 years ago I'm happy to be able to report progress on this issue, thanks to all who commented.
First, the good news is that there is a registry for grid sets that includes the origin, resolutions, tilesize and bounds, as well as the CRS associated to the grid set, based on the TMS specification Annex D.
The not so good news is that there is an emerging 'clarification' of TMS that allows the CRS underlying a grid set to be treated interchangeably in some circumstances. Unfortunately, this clarification goes right to the heart of why grid sets should be standardized as part of the / as though they are CRS: because of the resulting axis order (and other) confusion that will certainly result from such interchangeability.
Thanks everybody for discussion of this idea at today's meeting of the IG. Background email discussion thread is here. Please feel free to comment on this issue if you have more to add. Link to 2021-01-07 meeting minutes.
Summary
The Spatial Data on the Web Best Practice 12 recommends providing 'convenience APIs' for application consumers.
The context of use for our discussion is the Web; having a set of recommended scales associated to a CRS by its definition would allow all downstream 'applications' of that CRS to 'inherit' the recommended scale set. (This may be a too-liberal interpretation of what constitutes an 'API', but it might be convenient - TBD).
Such applications could include not only Web maps, Web services/APIs, and Web applications such as, for example augmented reality, but also data collection activities, which might be usefully informed of the recommended set of scales that the data will be primarily used at and so calibrate their activities to collect or create data at appropriate resolutions and with scale-appropriate data models.