[Requests] 17-083 OGC Tile Matrix Set Feedback

Scott Simmons ssimmons at opengeospatial.org
Tue Jul 3 16:23:32 EDT 2018


Thank you for the comments, Matthew. I will forward these to the editor for consideration.

Best Regards,
Scott

Scott Simmons
Executive Director, Standards Program
Open Geospatial Consortium (OGC)
tel +1 970 682 1922
mob +1 970 214 9467
ssimmons at opengeospatial.org <mailto:ssimmons at opengeospatial.org>

The OGC: Making Location Count…
www.opengeospatial.org <http://www.opengeospatial.org/>

> On Jul 3, 2018, at 11:03 AM, Cechini, Matthew F. (GSFC-423.0)[Science Systems & Applications, Inc.] via Requests <requests at lists.opengeospatial.org> wrote:
> 
> Comments in the attached word document are referenced below:
>  
>  
> PART A
>  
> 1. Evaluator: Matthew Cechini (matthew.f.cechini at nasa.gov <mailto:matthew.f.cechini at nasa.gov>)
>  
> 2. Submission: OGC Tile Matrix Set Standard Candidate (17-083)
>  
>  
> PART B
>  
> 1. Requirement: 1
>  
> 2. Implementation Specification Section number: 7.1
>  
> 3. Criticality: Minor
>  
> 4. Comments/justifications for changes:
>                 Is there a registry to help figure out how to resolve the well-known scale set URIs into actual data?
>  
>  
>  
> 1. Requirement: 1
>  
> 2. Implementation Specification Section number: 7.1
>  
> 3. Criticality: Minor
>  
> 4. Comments/justifications for changes:
>                 Is this really where the data is expected to be represented, as in the bounding box would correspond to a TileMatrixSetLimits class associated with this TileMatrixSet?   Also, since multiple layers may reuse this TileMatrixSet, it may be difficult to address different coverages.  Were we to specify a “MBR surrounding the TileMatrixSet, that would presumably be an MBR surrounding all TileMatrix elements.  In our situation, our first two TileMatrices cover more than the +/-180,+/-90 geographic area.  It would be odd to see the actual MBR in the Capabilities. I would vote to remove this item.  There are other, more contextual, places where this bounding box information is found.
>  
>  
> 1. Requirement: 1
>  
> 2. Implementation Specification Section number: 7.1
>  
> 3. Criticality: Editorial
>  
> 4. Comments/justifications for changes: Should footnote reference the TMS within a GetCapabilities response or server?
>  
>  
>  
> 1. Requirement: 2
>  
> 2. Implementation Specification Section number: 7.1
>  
> 3. Criticality: Minor
>  
> 4. Comments/justifications for changes: It’s not clear how this requirement is realized within this spec.
>  
>  
>  
>  
> 1. Requirement: 2
>  
> 2. Implementation Specification Section number: 7.1
>  
> 3. Criticality: Editorial
>  
> 4. Comments/justifications for changes: I’m not sure what you mean by “structured.”
>  
>  
>  
>  
> 1. Requirement: 3
>  
> 2. Implementation Specification Section number: 7.2
>  
> 3. Criticality: Major
>  
> 4. Comments/justifications for changes:  If a TileMatrix within the associated TileMatrixSet is not included in this list… does that mean it is not valid?  For example if a TMS has TileMatrices with Identifiers 0-10 and this TileMatrixSetLimits only includes 0-5… what is to be inferred regarding 6-10?  This should probably be addressed to avoid ambiguity.
>  
>  
>  
> 1. Requirement: 3
>  
> 2. Implementation Specification Section number: 7.2
>  
> 3. Criticality: Minor
>  
> 4. Comments/justifications for changes: Footnote A in Table 4 states that the tileMatrix element is an “identifier to a tileMatrix”. Does that mean that the value here is always the same as a TileMatrix::identifier?  And if so, should this be ows:CodeType to match?  Or is this a URI pointing to an identifier somewhere?  If the latter, an example somewhere would be helpful.
>  
>  
>  
>  
> 1. Requirement: 5
>  
> 2. Implementation Specification Section number: 7.3
>  
> 3. Criticality: Minor
>  
> 4. Comments/justifications for changes:  Is there any enforcement on format for these external documents? If a client doesn’t know how to parse these referenced documents, then that could be frustrating.
>  
>  
>  
>  
>  
> 1. Requirement: 4/5
>  
> 2. Implementation Specification Section number: Annex X
>  
> 3. Criticality: Major
>  
> 4. Comments/justifications for changes:  Examples of the TileMatrixSet2D and TileMatrixSetLink2D classes should be provided in an Annex to facilitate understanding of the requirements.
>  
>  
> .................................................................
> Matthew Cechini
> Contractor, Science Systems and Applications, Inc.
> NASA GIBS Systems/Software Engineer
> 410.205.6272
> <17-083_OGC_Tile_Matrix_Set_Standard_for_RFC_mfc.docx>_______________________________________________
> Requests mailing list
> Requests at lists.opengeospatial.org <mailto:Requests at lists.opengeospatial.org>
> https://lists.opengeospatial.org/mailman/listinfo/requests <https://lists.opengeospatial.org/mailman/listinfo/requests>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20180703/3dd04b63/attachment-0001.html>


More information about the Requests mailing list