W3C home > Mailing lists > Public > public-poiwg@w3.org > May 2011

Re: comments from OGC

From: Thomas Wrobel <darkflame@gmail.com>
Date: Thu, 12 May 2011 11:52:20 +0200
Message-ID: <BANLkTinS+x1qsNE6EuKWkhyEvuHHGvg7Qg@mail.gmail.com>
To: sophia parafina <sophia.parafina@gmail.com>
Cc: Matt Womer <mdw@w3.org>, public-poiwg W3C <public-poiwg@w3.org>
>"A location should be persistent over time
> and does not change.[CNR2]"

As this is very limiting, should we rename location in the draft to "position" ?

Theres many use cases where moving POIs are usefull - I'm still very
keen on ones that are specified relative to moving sources of position
identification (such as a image or RFID code). This is very usefull
for AR.

~~~~~~
Reviews of anything, by anyone;
www.rateoholic.co.uk
Please try out my new site and give feedback :)



On 12 May 2011 00:28, sophia parafina <sophia.parafina@gmail.com> wrote:
> 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.
>>>
>>>
>
Received on Thursday, 12 May 2011 10:00:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 12 May 2011 10:00:45 GMT