[Requests] Comments on OGC simple features

Stephane Garcia Stephane.Garcia at ign.fr
Fri Jul 27 09:22:10 EDT 2018


PART A


1. Evaluator:
Dimitri Sarafinof
Dimitri.sarafinof at ign.fr<mailto:Dimitri.sarafinof at ign.fr>

2. Submission: [OpenGIS Project Document Number, Name]

Geographic information - Features and geometry - Part 1: Feature models (17-087r8)

PART B


1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
General

3. Criticality: [Major, Minor, Editorial, etc.]
General

4. Comments/justifications for changes: [Comments]
This part of the standard is very well explained despite its complexity

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
iii preface

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
The other parts are explained in the next paragraphs, but maybe consider adding a quick word in this paragraph about the place of this part in the standard.

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
1.1

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
"such as  dynamic". Remove the extra space.

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
1.1

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
"which may share sematic structure". Typo

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
1.1

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
"name feature types and properties". Missing a coma

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
1.2

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
"The first 3 parts are a replacement for..." this phrase is important, consider placing it earlier in the document.

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
1.3

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
"common mathematical approached". Typo

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
4.9

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
The definition of Feature class differs from the definition of "Class" in 19103, maybe consider adding a note to explain why, like for the definition of feature association

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
4.11

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
If feature concept is the equivalent of Stereotypes in UML, it should be mentioned and if not, perhaps the difference between the 2 concept can be explained

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
4

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
The word namespace is used several times, maybe consider adding it to the definitions

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
6.1

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
"a list if feature". Typo

1. Requirement: [General, #]
REQ4

2. Implementation Specification Section number: [General, #]
REQ4

3. Criticality: [Major, Minor, Editorial, etc.]
Technical

4. Comments/justifications for changes: [Comments]
Is it within the scope of this standard to describe search queries? If not, consider having this requirement as a note

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
fig1

3. Criticality: [Major, Minor, Editorial, etc.]
Technical

4. Comments/justifications for changes: [Comments]
Maybe the link from feature, role, property should point to the taxonomy class and not to the definition class

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
fig1

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
Is UML the good language to represent taxonomy? As it was said in the beginning of the document, this language is limited and cannot be used for every concept of this standard like dynamic objects. Consider using other representation or no schema at all

1. Requirement: [General, #]
Req22

2. Implementation Specification Section number: [General, #]
Req22

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
This requirement is not clear enough, please consider adding an explicative note

1. Requirement: [General, #]
Rec6

2. Implementation Specification Section number: [General, #]
Rec6

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
Typo. "excepts at it endpoints"

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
6.3

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
The requirement class is named "feature ontology" at the beginning of the document and here just "ontology" consider harmonizing

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
A.3.2

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
This test is rather vague and maybe needs more details (valid against what?)

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
B.1

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
Maybe the explanation on why this standards uses UML schemas despite the fact that they are not dynamic can go earlier in the document (before figure 1 which is an UML schema)

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
Figure B.1

3. Criticality: [Major, Minor, Editorial, etc.]
Technical

4. Comments/justifications for changes: [Comments]
Consider replacing the class Definition by Taxonomy if appropriate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20180727/cd81d411/attachment-0001.html>


More information about the Requests mailing list