[Requests] 11-122r1 - OGC BP - Gazetteer Service - Application Profile of the WFS Candidate Implementation Standard

Rosinger, David S (IGS) david.rosinger at IntergraphGovSolutions.com
Tue Jan 3 15:42:37 EST 2012


1. Evaluator:

    David Rosinger
    Intergraph Government Solutions (Hexagon)
    david.rosinger at intergraphgovsolutions.com

2. Submission:

    OGC 11-122r1
    OGC Best Practices Document:
    Gazetteer Service - Application Profile of the Web Feature Service
    Candidate Implementation Standard

==========================================================================

1. Requirement: n/a

   'must' vs. 'shall'

2. Implementation Specification Section number: [All]
3. Criticality: [Editorial]
4. Comments/justifications for changes:

    Use 'shall', not 'must'.

    From OGC 06-121r9 OWS Web Services Common Standard,
    subclause ii. Document terms and definitions:

        "In particular, the word 'shall' (not 'must') is the verb form used
        to indicate a requirement to be strictly followed to conform to
        this specification."

==========================================================================

1. Requirement:

    "Provides methods to traverse parent/child relationships."

2. Implementation Specification Section number: [i. Preface]
3. Criticality: [Editorial]
4. Comments/justifications for changes:

    This reviewer believes it would it be better to say that the data
    model supports the representation of parent/child relationships. In
    particular, 'provides methods' might be inadvertently taken to mean an
    extension to the WFS interface.

==========================================================================

1. Requirement:

    "* Adds extensions based on NGA and USGS requirements including:
       ... Type Domain (Official or Variant) ...

     * Updates the alternativeGeogeographicIdentifier so the domain values
       describe if the alternativeGeographicIdentifier value is an
       official or variant name. Valid values are "official" or
       "variant". This done so the schema can support multiple official
       and variant names. For example, Canada has two official languages
       so there may be two official names, one in English and one in
       French."

2. Implementation Specification Section number: [i. Preface]
3. Criticality: [Editorial]
4. Comments/justifications for changes:

    The 'Type' domain should be considered a candidate for expansion and
    possibly implementation specific (e.g, defined in an organization's
    dictionary). Example from NGA:

        Approved
        Conventional
        Historic
        Historic Native Script
        Native Script
        Provisional
        Provisional Native Script
        Unverified
        Unverified Native Script
        Variant
        Variant Native Script

    Reference:

        http://geonames.nga.mil/ggmagaz/

            (See options under 'Search Criteria'.)

==========================================================================

1. Requirement: n/a

    "This profile implements a complete set of elements from the ISO 19112
    model with updates based on input from OGC WFS-G Change Requests
    08-051 and 08-052, EuroGeoNames, and extensions based on USGS and NGA
    requirements to provide useful, standardized services, integrates
    representations of parent/child relationships, standardizes definition
    of Location Instances and adds transactional interfaces based on
    WFS-T."

2. Implementation Specification Section number: [vi. Future Work]
3. Criticality: [Editorial]
4. Comments/justifications for changes:

    This introductory sentence as written is awkward. Possible revision:

    "This profile implements a complete set of elements from the ISO 19112
    model and includes updates to the previous version based on input from
    OGC WFS-G Change Requests 08-051 and 08-052, EuroGeoNames, USGS, the
    State of Montana and NGA. This updated profile also adds a capability
    for modeling parent/child relationships as defined in ISO 19112 and
    adds transaction capabilities (insert, update, delete) as defined in
    the OGC WFS standard.

    This intent of this profile is to provide a blueprint for creating truly
    useful and interoperable gazetteer web services that are based on a
    common definition for Location Instances."

==========================================================================

1. Requirement: n/a
2. Implementation Specification Section number: [vi. Future Work]
3. Criticality: [Minor/Spelling]
4. Comments/justifications for changes:

    HMTL => HTML

==========================================================================

1. Requirement: n/a
2. Implementation Specification Section number: [vi. Future Work]
3. Criticality: [Editorial]
4. Comments/justifications for changes:

    A future SWG might consider dividing this best practice document into
    two main sections or two distinct documents as follows:

    * Gazetteer GML Application Schema (e.g., 'GazetteerGML'; this would
      be similar in principle to 'CityGML'). This would allow gazetteer
      data to be used in situations that wouldn't necessarily involve a
      WFS.

    * Gazetteer Service - Application Profile of the Web Feature Service.
      This service would adopt 'GazetteerGML' as the data model, and then
      extend and/or constrain the core WFS operations and the use of OGC
      Filter.

==========================================================================

1. Requirement:

    "Services compliant with this standard shall provide Location
    Instances derived from SI_LocationInstance."

2. Implementation Specification Section number: [1 Scope]
3. Criticality: [Editorial]
4. Comments/justifications for changes:

   The organizations that submitted this document actually recommended
   that compliant services serve SI_LocationInstance itself, but not
   derive (extend) from it. This recommendation was made to lower the
   implementation bar for WFS-G clients.

==========================================================================

1. Requirement:

    "As a web feature service, a gazetteer service must be able to service
    transaction requests."

2. Implementation Specification Section number: [1 Scope]
3. Criticality: [Major]
4. Comments/justifications for changes:

    This reviewer believes that transaction support should be stated as
    optional. Making this change here would also be consistent with the
    language in Table 1 (subclause 7.2) and clause 11 which declare that
    transaction support is optional.

==========================================================================

1. Requirement: n/a
2. Implementation Specification Section number: [9.2 Examples]
3. Criticality: [Minor]
4. Comments/justifications for changes:

    In the first two example requests, the namespace for the gazetteer
    schema is shown incorrectly as:

      http://www.isotc211.org/iso19112

    The correct namespace is:

      http://www.isotc211.org/19112

==========================================================================

1. Requirement: n/a
2. Implementation Specification Section number: [10.1 Introduction
                                                (GetFeature operation)]
3. Criticality: [Editorial]
4. Comments/justifications for changes:

    In addition to the behaviors listed in this subclause, this reviewer
    recommends that these behaviors also be considered:

    * [SHOULD|SHALL] support case-insensitive searching
    * [SHOULD|SHALL] support searching with partial matching
    * [SHOULD|SHALL] support searching with and without diacritics

    (Note: Another candidate behavior, point/radius searching, appears in
    vi. Future Work.)

    For the behavior 'get all entries in a gazetteer (empty filter)',
    perhaps the document could advise that a service implementer SHOULD
    consider cutting off the response at some MAXFEATURES threshold. (USGS
    and NGA serve millions of feature instances.)

==========================================================================

1. Requirement: n/a
2. Implementation Specification Section number: [Annexes B, C]
3. Criticality: [Editorial]
4. Comments/justifications for changes:

    Per prior discussion on the SWG mailing list [e.g., 2011-09-22],
    remove the content of the schema files and GML dictionaries from the
    document and include as separate files with the document. Also post
    these schema files to http://bp.schemas.opengis.net/ . Segregate
    informative material in an appropriate subfolder. State that when an
    included file and an online file differ, the online file is
    authoritative.

==========================================================================

1. Requirement: n/a
2. Implementation Specification Section number: [Annexes D.1 and D.2]
3. Criticality: [Editorial]
4. Comments/justifications for changes:

    Consider swapping the order of these annexes since D.1 (Parent-Child
    Navigation) is arguably a more advanced use case than D.2 (Geographic
    Selection). D.2 will certainly be implemented by all WFS-G clients and
    this reviewer believes it is the most broadly applicable use case and
    should be listed first.

==========================================================================

1. Requirement: n/a
2. Implementation Specification Section number: [Annexes E, F and G]
3. Criticality: [Editorial]
4. Comments/justifications for changes:

   Consider moving the content of these tables into GML dictionaries and
   include as separate files with the best practice document. Also post to
   http://bp.schemas.opengis.net/ . State that when an included file and
   an online file differ, the online file is authoritative.

==========================================================================

This email message has been delivered safely and archived online by Mimecast.  For more information please visit http://www.mimecast.com



More information about the Requests mailing list