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

[Mike Botts]

1. Evaluator:

   Dr. Mike Botts
   Botts Innovative Research Inc
   mike.botts at botts-inc.net 
   
2. Submission:

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

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

1. Requirement: Improve support for time in Gazetteer Services

Requirement summary - Require valid time ranges for all features inserted into the
gazetteer (i.e. "this county boundary was valid from 1805 to 1849"), provide an easy 
mechanism for including time in a feature request (i.e. the "give me the county 
boundary for Cherokee County, GA in 1835)", and provide examples in the 
documentation. [NOTE: I'm not saying use natural language in the request but
simply require the equivalent of a temporal-based form in insertFeature and getFeature 
requests.]

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

 Most features on the Earth are temporal in nature: political boundaries change, buildings
are constructed and torn down, streets are modified, relocated, or renamed, and many
temporary and dynamic objects appear, move, and are removed. The timeframes for
change in features that should be supported in a gazetteer can be days, years, centuries,
or for geological features, millions of years.

This dynamic nature of features should be reflected and better supported in our profile for
Gazetteer services. The provider of features and the services for accessing these features
should not assume that the potential users are only interested in features that exist today.
Various communities such as city planners, genealogist, resource managers, historians, and 
geologists, just to name a few, depend on knowledge of the presence, location, and state of
features at various times in the past, as well as perhaps the current location and state.

The proposed profile perhaps provides support for temporal aspects of features within the 
model and perhaps in the WFS filter mechanism, but it does not require or even encourage
the inclusion of a valid time for features as part of the insertion or request services. It is OK 
perhaps for the service to assume that a etFeature request with no time constraint implies
current time or "now" as the default time, but all features in the gazetteer should have valid 
time constraints.

Without adequate support and requirements for time in the profile model and services, the 
 profile for gazetteer services will fail to meet the needs of those communities that rely on 
temporal knowledge of the presence, location, and state of features.

Without requiring temporal constraints during insertion of feature into the gazetteer service,
many data providers will fail to understand the importance of time-tagging their features and
will not provide valid time constraints for their features.
==========================================================================



*****************************************
Dr. Mike Botts
Botts Innovative Research, Inc.

http://www.botts-inc.com
mike.botts at botts-inc.net
256-652-0165
*****************************************



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20120104/d3d72207/attachment-0001.htm>