Change Requests | OGC

(1)

Open Geospatial Consortium Inc.

Date:

2010-04-23

Reference number of this document:

OGC 10-089

Version:

1.0.0

Category: OpenGIS®

_{RFC Responses}

Editor

:

Peter Schut

OpenGIS

®

_{Table Joining Service:}

Comments received for the March 16

th

_{2010 RFC}

Copyright © 2010 Open Geospatial Consortium, Inc. All Rights Reserved.

To obtain additional rights of use, visit

http://www.opengeospatial.org/legal/

.

Warning

This document is not an OGC Standard. It is distributed for review and comment. It

is subject to change without notice and may not be referred to as an OGC Standard.

Recipients of this document are invited to submit, with their comments, notification

of any relevant patent rights of which they are aware and to provide supporting

documentation.

i

Document type:

OpenGIS

®

Standard

Document subtype:

(2)

Background

This document is for reference only. It was produced by GLS SWG following the 30 day

comment period for the TJS Request for Comments which closed April 14

th

₂₀₁₀

(

http://www.opengeospatial.org/standards/requests/62

). The contents of this document

consist of a collated version of all comments sent received via the formal comment

submission process at

[email protected]

. No responses are included in this

version of the document.

Comments Received

Reviewer #1

Comment #1.1

Specification Section number: General

Criticality: Major

Comments/justifications for changes:

Joining two tables on the basis of a common non-spatial attribute/column is not something that should be standardised by OpenGIS. As far as I can see, this is a general (relational) database technique, so there is nothing particularly geographical about it. Such a standard/specification should be the responsibility of the database community.

Note. This comment was subsequently withdrawn and replaced with the following series of comments.

Comment #1.2

Would it be an idea to let the name of the standard reflect the emphasis on joins using geographic identifiers?

Comment #1.3

I miss a reference to ISO 19112:2003 "Geographic information - Spatial referencing by geographic identifiers".

Comment #1.4

(3)

Comment #1.5

I am still not convinced that it is worth the effort to expose data that is "indirectly" geographically referenced in this way. An alternative is to hide this behind other protocols, such as WMS, WCS or WFS.

Comment #1.6

RDBMS is referenced on to two occasions - is this intentional / necessary?

Comment #1.7

6.4.2 Regarding count and measure attributes - is this established terminology? Count would be summations (as examplified in the last paragraph), while measure could be an average or representative value. Would "sum" be better than "count"?

Comment #1.8

Page 12: FrameworkKey - what is meant by "i.e. in the GIS". There is a "d" missing in "use" (should be "used".

Comment #1.9

Page 16: Framework Key - should there be "(s)" after column in the first line?

Comment #1.10

Page 16, table 14: The footnotes a and b have been mixed up.

Comment #1.11

Page 18: Is there a need for both SpatialColumnProportion and SpatialColumnPercentage?

Comment #1.12

Page 18: "geometery" -> "geometry"

Comment #1.13

(4)

page 35: "The DescribeDatasets operation returns an XML document that identifies all of the attribute datasets for which data is available from the service instance." When the Framework URI is included, not all the attribute datasets are returned (according to footnote a in table 45), so this is not entirely accurate.

Comment #1.15

Page 43: Filter column - should the filter encoding standard be referenced / used?

Comment #1.16

"12.3.1 GetData normal response parameters. The normal response to a valid DescribeData..." Should DescribeData be changed to GetData?

Comment #1.17

Page 47, table 57: title seems to be wrong. Should it be: "Table 57 — DescribeJoinAbilities response: FrameworkDescriptions data structure"

Comment #1.18

Page 54, FrameworkKey: also here the "(s)" seems to be missing after field. Note 1 says that the shaded elements are identical to those in table 6 - they should be made identical... :-)

Comment #1.19

Page 62: "completerd" -> "completed"

Comment #1.20

page 64: Missing "in" between "included" and "the" Parameter, name - "Character String type, not empty; with Parameter data structure, see Table 84" - I don't understand this.

(5)

Comment #2.1

Specification Section number: 7.4 GDAS encoding

Criticality: Minor

In table 14, notes "a" and "b" have their descriptions swapped.

Comment #2.2

In table 13, row 2, the multiplicity for the "Attributes" element should probable be "one

(mandatory)". Since this element is essentially a container for a list, it doesn't make sense for this element itself to be a list. I believe the XSD has the multiplicity at "one" as well.

Reviewer #3

Comment #3.1

In table 23, row 1 (Classes parameter): “Use when attribute purpose is Data” - “Data” does not exists as a possible purpose value. Instead, it should be “Attribute”.

Comment #3.2

In table 16, notes “a” and “b”: Where says “a” should say “b” and vice versa.

Comment #3.3

Specification Section number: 12.2.1 GetData request parameters

(6)

Specification Section number: 12.2.2 GetData request KVP encoding

In KVP example: “Request = DescribeData&” - Should be “GetData&” instead.

Comment #3.5

Specification Section number: 12..3.1 GetData normal response parameters

“The normal response to a valid DescribeData…” - Should say “The normal response to a valid GetData” instead.

Comment #3.6

Specification Section number: 15.2.1 JoinData request parameters

In table 71, row 2 (Request parameter): “Value is DescribeKey” - Value should be “JoinData”.

Comment #3.7

Specification Section number: Annex A - A.2.3 DescribeFrameworks operation request

“A.2.3 DescribeFrameworks operation request” - Should say “A.2.3 DescribeDatasets operation request” instead.

“A.2.3 a) Test Purpose: Verify… for a DescribeFrameworks operation request.” - Should say “A.2.3 a) Test Purpose: Verify… for a DescribeDatasets….” instead.

(7)

Comment #3.8

In table 14, note “d”: When more than one column, the names of the each of the columns in the Dataset/Columnset/FrameworkKey could be different from the equivalent columns in the Framework/FrameworkKey names if the order is maintained. Or, there could be a new tag for each column indicating the order. This would be more flexible about the names of the columns.

In table 29, note “a”: “The order of the <V> elements inside each <Row> is important”.

So, it seams that it should be possible to have different column names if the order is always maintained.

Comment #3.9

In table 16, note “a”: Maybe it should be useful to recommend also not to use other special characters (except of “_”).

Comment #3.10

Specification Section number: 14.3.1 DescribeKey normal response parameters

Criticality: Major