comments from OGC

Hi all,

I received some comments from the Open Geospatial Consortium that I need to share so that some of the changes you'll see tomorrow to the Core draft make sense.  They were in a Word doc with some note marks, but for the sake of searching and referencing, I've converted it to text.  Unfortunately I could not get the marks into a plain text version, so I've also attached a PDF that has the notes.

Thanks,

-M

1.0 Introduction

Suggest adding GML (Geography Markup Language) and GeoJSON to the following
sentence: ÒTo achieve these goals, this document describes a generic data
model and one normative format. This format is based on XML and is likely
insufficient to cover all POI use cases, therefore, it is expected that the
data model will be mapped to other formats, such as JSON, RDF, or HTML.Ó

2.0 Terminology

First, there are a number of terms that should be added to the Terminology
section. This is because certain terms are used later in the document and
either not defined or defined in later sections.

FYI, Point of Interest is defined in the OGC Open Location Services
[CNR1]standard as:

A location (with a fixed position) where one can find a place, product or
service, typically identified by name rather than by address and
characterized by type, which may be used as a reference point or a target
in a location based service request, e.g., as the destination of a route.

The definition for ÒLocationÓ should be harmonized with ISO standards terms
and definitions. Also, a specified coordinate reference system (WGS 84)
should not be mentioned in a definition. The specification and handling of
CRS should be later in the document. So, the definition of Location
becomes:

Location: Identifiable geographic place [ISO 19112]. Typically a location
is a physically fixed point, typically on the surface of the Earth, though
locations can be relative to other, non-earth centric coordinate reference
systems. Locations can be a single point, a centroid, a minimum bounding
rectangle, or a set of vectors. A location should be persistent over time
and does not change.[CNR2]

Other definitions that should be added:

Coordinate: one of a sequence of n numbers designating the position of a
point in n-dimensional space [ISO 19111][CNR3]

Coordinate Reference System: coordinate system that is related to an object
by a datum [ISO 19111]

Coordinate System: set of mathematical rules for specifying how coordinates
are to be assigned to points [ISO 19111]

Datum: parameter or set of parameters that define the position of the
origin, the scale, and the orientation of a coordinate system [ISO 19111]

Geolocation: The identification of the real world geographic location of an
object.

Point: [CNR4]0-dimensional geometric primitive, representing a position.
[ISO 19107]

Position: data type that describes a point or geometry potentially occupied
by an object or person. [ISO 19133] [CNR5]

Route: sequence of links and / or partial links that describe a path,
usually between two positions, within a network [ISO 19133]

There may be more.

Section 6 provides great detail with examples for each of the operations.

3.0 Data Model

3.1 Georeference Ð While geo-reference is a valid term, geo-reference
typically indicates that a geometry or an image has coordinate reference
system metadata. The suggested term is geolocation as this term is used
extensively in other standards work, including the work of the W3C.

3.1.1 Center

Perhaps this should be called ÒcentroidÓ. Centroid is a well known and well
understood term in the geospatial (and spatial) industries. Further, Center
has other uses in various other standards, such as in HTML 5 center refers
to the center of a text string. This is the typical usage of the term
ÒcenterÓ also in the cartography and mapping industries.

The definition of a centroid is on the
http://www.w3.org/2010/POI/wiki/Terminology. Centroid works for any
geometric figure in 2 or 3 dimensions.

This change does not change the intent of the clause.

BIG SIDEBAR

Instead of ÒSystemÓ we would recommend using Òcoordinate reference systemÓ
or ÒCRS for short. WGS 84 can still be the default.

WGS-84 Ð The spec needs to be clear about a proper reference for WGS-84
(i.e., the parameters). Most everyone now references EPSG 4326. There is an
online EPSG registry. http://www.epsg-registry.org/. Some suggested wording
is:

Geographic locations in PoI are defined using [WGS 84] (World Geodetic
System 1984), equivalent to EPSG (European Petroleum Survey Group) code
4326 (2 dimensions). PoI does not assign responsibilities for coordinate
transformations from and to other Coordinate Reference Systems.

Lat/long: Somewhere in the document, you need to define what is meant by
latitude and longitude. Further, if a coordinate reference system other
than WGS 84 2d or 3d is used, then the coordinates most likely will not be
expressed as lat/long. This is a minor point but something to consider.

Anyway, the following is a definition of latitude and longitude as used in
a number of international standards (ISO, OGC, IETF, OMA, and OASIS are all
very similar). All are based on ISO 6709. 6709 also addresses altitude.
More on that below. The reason for providing a definition is to insure that
ambiguity of encoding variance is minimized.

FYI, the W3C standard WebVideo uses 6709:2008. 6709:2008 includes XML
encoding examples.

Altitude: Need a slight change:

The altitude measure is in meters above mean sea level per the [WGS- 84]
datum.

3.1.3 Address

The ÒAddressÓ element appears somewhat similar to what is specified in
other international standards that are used to encode civic address
information.

Both the IETF and OASIS have defined a civic address encoding/format. The
IETF ÒcivicLocÓ definition was driven by requirements from the 911 and
emergency response community. The OASIS CIQ/xAL format was driven by
business requirements. The following information on address is based on the
IETF work, which is specified as mandatory for the Next Generation 911
architecture and deployment. The IETF work has also been
harmonized/extended to be consistent with a number of international
addressing standards as well as the very recent US Address Data Model
(FGDC).

The original IETF document is RFC 4119 ÒA Presence-based GEOPRIV Location
Object FormatÓ. This document provides the original definition of a
Òlocation objectÓ. There are two forms: civic and geodetic. Geodetic is
coordinates.

This document was significantly enhanced in RFC 5491 ÒGEOPRIV Presence
Information Data Format Location Object (PIDF-LO) Usage Clarification,
Considerations, and Recommendations.Ó (http://tools.ietf.org/html/rfc5491)
and in RFC 5139, ÒRevised Civic Location Format for Presence Information
Data Format Location Object (PIDF-LO)Ó

And finally there is ÒSpecifying Civic Address Extensions in PIDF-LO
(draft-ietf-geopriv-local-civic-01)
http://tools.ietf.org/html/draft-ietf-geopriv-local-civic-01

All of the above is by way of background information. The following is what
should be considered to prevent ambiguity and to be consistent with
international standards best practice. FYI, the following codes are in an
IANA registry (known as CAtypes)

| Label                | Description          | Example             |
+----------------------+----------------------+---------------------+
| country              | The country is       | US                  |
|                      | identified by the    |                     |
|                      | two-letter ISO 3166  |                     |
|                      | code.                |                     |
|                      |                      |                     |
| A1                   | national             | New York            |
|                      | subdivisions (state, |                     |
|                      | region, province,    |                     |
|                      | prefecture)          |                     |
|                      |                      |                     |
| A2                   | county, parish, gun  | King's County       |
|                      | (JP), district (IN)  |                     |
|                      |                      |                     |
| A3                   | city, township, shi  | New York            |
|                      | (JP)                 |                     |
|                      |                      |                     |
| A4                   | city division,       | Manhattan           |
|                      | borough, city        |                     |
|                      | district, ward, chou |                     |
|                      | (JP)                 |                     |
|                      |                      |                     |
| A5                   | neighborhood, block  | Morningside Heights |
|                      |                      |                     |
| A6                   | street               | Broadway            |
|                      |                      |                     |
| PRD                  | Leading street       | N, W                |
|                      | direction            |                     |
|                      |                      |                     |
| POD                  | Trailing street      | SW                  |
|                      | suffix               |                     
|                      |                      |                     |
| STS                  | Street suffix        | Avenue, Platz,      |
|                      |                      | Street              |
|                      |                      |                     |
| HNO                  | House number,        | 123                 |
|                      | numeric part only.   |                     |
|                      |                      |                     |
| HNS                  | House number suffix  | A, 1/2              |
|                      |                      |                     |
| LMK                  | Landmark or vanity   | Low Library         |
|                      | address              |                     |
|                      |                      |                     |
| LOC                  | Additional location  | Room 543            |
|                      | information          |                     |
|                      |                      |                     |
| FLR                  | Floor                | 5                   |
|                      |                      |                     |
| NAM                  | Name (residence,     | Joe's Barbershop    |
|                      | business or office   |                     |
|                      | occupant)            |                     |
|                      |                      |                     |
| PC                   | Postal code          | 10027-0401          |
+----------------------+----------------------+---------------------+

There are more in the other RFCÕs as the list was extended to meet
additional requirements. I am not suggesting that all of these are needed
but that the names and meanings should be the same across standards.

3.1.4 Route

I would suggest changing the definition to:

Route: A sequence of links and / or partial links that describe a path,
usually between two positions, within a network [ISO 19133 and OGC Open
Location Services Interface Standard).

3.1.5 Area

The definition provided in this clause suggests that we are actually
talking about a polygon geometry. The OGC/ISO definition of polygon is:

Polygon: Planar surface defined by 1 exterior boundary and 0 or more
interior boundaries.

This is the abstract definition, which should be up in the Terminology
section. A more ÒimplementationÓ oriented definition would be (paraphrased
from GeoJSON):

A polygon is a closed LineString with 4 or more coordinate positions. The
first and last positions are equivalent (they represent equivalent points).

GeoJSON uses geometry as defined in ISO 19107, which is the source for many
of the definitions I have used in this document. ISO 19107 is also the
abstract geometry model used in OGC Simple Features (see below) and the OGC
Geography Markup Language.

3.1.8 Relative

This topic has cause years of discussion in both the OGC and the IETF WRT
location services. The latest thinking with input from the OGC on this
topic is captured in the draft internet standard ÒRelative Location
RepresentationÓ (draft-ietf-geopriv-relative-location-01)

http://tools.ietf.org/html/draft-ietf-geopriv-relative-location-01

Again, this document probably has way more information than is required in
the PoI spec but sure would be good to be consistent where possible.

Also, in the current document Distance From and Bearing to need to be well
defined. An interesting issue is that bearing and distance are used
different in land systems versus water body navigation!

3.3 Relationship Primitives

These section should perhaps simply reference the OGC/ISO Simple Features
Interface standard, section 6.1.15 Ð Relational Operators.

Relational operators: The relational operators are Boolean methods that are
used to test for the existence of a specified topological spatial
relationship between two geometric objects as they would be represented on
a map. [OGC Simple Features Interface standard and ISO 19125]. There are 9
operators that were originally defined by Max Egenhofer and well document:

EGENHOFER, M.J. AND HERRING, J. A mathematical framework for the definition of topological relationships. Proceedings of the Fourth International Symposium on Spatial Data Handling, Columbus, OH, pp. 803-813

These operators are defined and used consistently in the OGC Simple Features Interface Standard (which is implemented in just about all commercial and open source database products), SQL-MM, GeoSPARQL, WS-Search/CQL and other standards. 

Based on the above operators the following methods are defined on Geometry:
Equals (anotherGeometry: Geometry): Integer Ñ Returns 1 (TRUE) if this geometric object is spatially equal to another Geometry.
Disjoint (another Geometry: Geometry): Integer Ñ Returns 1 (TRUE) if this geometric object is spatially disjoint from anotherGeometry.
Intersects (another Geometry: Geometry): Integer Ñ Returns 1 (TRUE) if this geometric object spatially intersects another Geometry.
Touches (another Geometry: Geometry): Integer Ñ Returns 1 (TRUE) if this geometric object spatially touches another Geometry.
Crosses (another Geometry: Geometry): Integer Ñ Returns 1 (TRUE) if this geometric object spatially crosses another Geometry.
Within (another Geometry: Geometry): Integer Ñ Returns 1 (TRUE) if this geometric object is spatially within another Geometry.
Contains (another rGeometry: Geometry): Integer Ñ Returns 1 (TRUE) if this geometric object spatially contains another Geometry.
Overlaps (Another Geometry: Geometry) Integer Ñ Returns 1 (TRUE) if this geometric object spatially overlaps another Geometry.
Relate (another Geometry: Geometry, intersectionPatternMatrix: String): Integer Ñ Returns 1 (TRUE) if this geometric object is spatially related to another Geometry, by testing for intersections between the interior, boundary and exterior of the two geometric objects.

Section 6 of the OGC SF standard provides great detail with examples and
diagrams for each of the operations.

3.9 Time Primitive

We would encourage the use of the ISO Time standard as the basis for
expressing time in this spec. This is ISO 8601 and is the standard basis
for every time element we are aware of in standards work.
http://en.wikipedia.org/wiki/ISO_8601

4.3 Representing Coordinates

Please see all of our comment above.

4.3.1 Point

Please see comments above.

Etc.

As to examples, perhaps using GML also? 

[CNR1]As agreed to by ESRI, AutoDesk, Intergraph, Webraska, NAVTEK, deCarta, TeleAtlas, Oracle and others. Consistent with the ISO 19133 definition.
[CNR2]I am not sure that this should be in the definition. Also, locations are never truly persistent. AS we saw in the case of the recent Japanese earthquake, the entire country shifted with a maximum shift of 8 feet on the northeast coasr. This screws up the entire geodetic system and hence many applications will need to be recalibrated.
[CNR3]ISO 19111 is actually a joint document between the OGC and ISO. The contents were written by some of the top industry geodesy experts, including folks from the petroleum and defense industries. 
[CNR4]The current draft define ÒpointÓ in section 4.3.1. The definition should be removed from that section.
[CNR5]The current draft uses geo-reference. This is inconsistent with the work in the IETF, NENA, and other standards organizations (including W3C previous work!) as well as many location provisioning communities (such as determining a device location bases on IP latency). http://en.wikipedia.org/wiki/Geolocation has a good overview.