Re: comments from OGC

On May 11, 2011 3:01 PM, "sophia parafina" <sophia.parafina@gmail.com>
wrote:
> +1 on using the Simple Features model
> -1 on GML, my opinion is that it is a needlessly complex model, simple is
> better
> On May 11, 2011 2:46 PM, "Matt Womer" <mdw@w3.org> wrote:
>> 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.
>>
>>