[Requests] Comments on CIS 1.1 (Coverage Implementation Schema, 09-143r3 [SEC=UNCLASSIFIED]

Peter Baumann p.baumann at jacobs-university.de
Mon Jan 4 07:26:58 EST 2016


Hi Dom,

thanks for your feedback. I would collect all for now and raise a general
discussion on the consolidated list by the end.

-Peter


On 2015-12-24 02:08, Dominic Lowe wrote:
>
> Peter, all,
>
>  
>
> Please find below two comments on the RFC Coverage Implementation Schema 1.1
>
> Unfortunately I haven't had time for a complete review at this time of year (I
> will be out of the office for the next three weeks) and have only had a
> superficial read through but the two issues below stood out as requiring some
> clarification.
>
>  
>
> All the best,
>
>  
>
> Dominic
>
>  
>
>  
>
>  
>
>  
>
> PART A
>
>  
>
>  
>
> 1. Evaluator:
>
>         Dominic Lowe, Australian Bureau of Meteorology, d.lowe at bom.gov.au
>
>  
>
> 2. Submission: 09-143r3, Coverage Implementation schema 1.1
>
>  
>
>  
>
>  
>
> PART B
>
>  
>
>  
>
> 1. Requirement:  #1
>
>   * Section 1.2.3 says: GMLCOV::ReferenceableGrid was only defined as an
>     abstract type (i.e., not instantiatable); in CIS 1.1 it is replaced by the
>     concrete general grid type CIS::Gen­eralGridCoverage which incorporates
>     the functionality foreseen in GMLCOV 1.0 as a subset.
>   * ReferenceableGrid was defined as a concrete type in GML 3.3. Actually
>     three implementations (by Arrray, by Vector, by Transormation). What is
>     the relationship between this and CIS 1.1?
>
>  
>
>  
>
> 2. Implementation Specification Section number:
>
> 1.2.3
>
>  
>
>  
>
> 3. Criticality: [Major, Minor, Editorial, etc.]
>
> Potentially Major
>
>  
>
> 4. Comments/justifications for changes:
>
> Clarification is needed about this relationship moving forward. Is the OGC's
> intention to supersede the GML 3.3 definitions with the CIS definitions?
>
>  
>
>  
>
>  
>
> --------------------------------------------------------------------------------------------------------------------------
>
> 1. Requirement: #2
>
>   * Figure 1 shows the grid-irregular package depends on grid-regular.
>     Logically this dependency doesn't seem to make sense (irregular depending
>     on regular).
>
>  
>
> 2. Implementation Specification Section number:
>
> Figure 1
>
>  
>
>  
>
> 3. Criticality: [Major, Minor, Editorial, etc.]
>
> Unsure of implications.
>
>  
>
> 4. Comments/justifications for changes:
>
> Can the dependencies be refactored somehow? E.g. both grid-regular and
> grid-irregular could depend on a separate package 'grid'.
>
>  
>
>  
>

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: p.baumann at jacobs-university.de
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: baumann at rasdaman.com
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20160104/767adce3/attachment.html>


More information about the Requests mailing list