[Requests] Public consultation on DGGS standard

Groom Richard richard_g58uk at yahoo.co.uk
Sun Jan 31 09:07:10 EST 2016


 PART A1. Evaluator:Richard Groom2. Submission: 15-104r3_OGC_Discrete_Global_Grid_System_DGGS_Core_Standard
PART B1. Requirement: [General, #]2. Implementation Specification Section number: [General, #] 3.63. Criticality: [Major, Minor, Editorial, etc.] 4. Comments/justifications for changes: [Comments] Note 1 on entry refers to vertical dimension - this implies a continuous scale above a datum, but surely a 3D DGGS would have to extend the DGGS into the vertical. Perhaps some explanation is needed.
PART B1. Requirement: [General, #] 
2. Implementation Specification Section number: [General, #] 5.1
3. Criticality: [Major, Minor, Editorial, etc.]
4. Comments/justifications for changes: [Comments] The covering email for this review suggested that DGGS would spell the end of 'legacy' coordinate systems. It is a bit worrying that Section 5 does not address this question thoroughly. I suggest a table comparing DGGS with conventional continuous coordinate systems for navigation, mapping, data analysis etc would clarify where each is most appropriate. The question of scale is not really covered: what do you see as the smallest practical cell size that could be used in a DGGS? Also, is there not a powerful argument to define a standard DGGS to improve interoperability even further?
PART B1. Requirement: [General, #] 2. Implementation Specification Section number: [General, #] 5.43. Criticality: [Major, Minor, Editorial, etc.]4. Comments/justifications for changes: [Comments] Last paragraph: If it is critical for DGGS to be composed of cells that are the same size, there needs to be some explanation as to how this can happen on an ellipsoidal object? It will be necessary to georeference the centre and boundary of each tile, so I think that a link to 'traditional' coordinate reference systems is inevitable. How do you ensure that on such a surface all the tiles are the same size?
PART B1. Requirement: [General, #] 
2. Implementation Specification Section number: [General, #] 5.6
3. Criticality: [Major, Minor, Editorial, etc.]
4. Comments/justifications for changes: [Comments] mapping and analysis of spatial data can take place at any 'scale' down to 0.25m cell size or smaller. Vector representation using cells would face the same problems as representation using raster grids, by degrading the vector geometry.
PART B1. Requirement: [General, #] 
2. Implementation Specification Section number: [General, #] 6.2.4
3. Criticality: [Major, Minor, Editorial, etc.]
4. Comments/justifications for changes: [Comments] Whilst tessellation over a sperical globe is straight-forward, it is by no means simple over an ellipsoid.I don't think that this document standardises how this is done and yet I think it should, for interoperability reasons. It seems that cells will have to be of different shape, in which case the geometry of each cell boundary becomes important, particularly if you are trying to assign data defined using latitude and longitude to a DGGS cell. By accepting mathematics that is non-rigorous, there will be the possibility of different interpretations, which will not aid interoperability.
PART B1. Requirement: [General, #] 
2. Implementation Specification Section number: [General, #] 6.2.5 and 6.2.6
3. Criticality: [Major, Minor, Editorial, etc.]
4. Comments/justifications for changes: [Comments] It is not clear how the DGGS is related to the globe. The centroid of the base polygon has to be fixed at a certain point and the orientation has to be defined. For interoperability reasons I think this should be defined within this standard. I wonder if there is a need for a standard document for each DGGS that defines its key features -sufficient to enable it to be constructed. If so, surely this is the document that should specify the requirements - and yet it does not.
PART B1. Requirement: [General, #] 
2. Implementation Specification Section number: [General, #] 6.3.1
3. Criticality: [Major, Minor, Editorial, etc.]
4. Comments/justifications for changes: [Comments] Second paragraph seems to be referring to geodetic datum, in which case perhaps that term should be used.
PART B1. Requirement: [General, #] 13
2. Implementation Specification Section number: [General, #]
3. Criticality: [Major, Minor, Editorial, etc.]
4. Comments/justifications for changes: [Comments] This sounds like a 'black box' approach. Surely it is better to define and publish the DGGS so that anyone can construct it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20160131/a3e32479/attachment-0001.html>


More information about the Requests mailing list