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

Re: moving POI [was re: comments from OGC]

From: Raj Singh <rsingh@opengeospatial.org>
Date: Tue, 17 May 2011 09:22:17 -0400
Cc: Thomas Wrobel <darkflame@gmail.com>, public-poiwg W3C <public-poiwg@w3.org>
Message-Id: <1F6628C6-A03E-4316-AAFF-839E5A13CB6C@opengeospatial.org>
To: cperey@perey.com
A few years ago we went through this same exercise with GeoRSS. Some proposals were made about how to handle POIs with multiple locations and those are summarized here:
http://www.georss.org/multiple_locations

Basically, there were 4 possibilities (for an Atom encoding):
1. just list multiple geometries and let the spec narrative define the semantics of what that means.
2. put each geometry in its own atom:entry and let an atom:link define the semantics of the relationship
3. similar to #2, but use the Atom Threading extension
4. group all geometries into a collection element

---
Raj
The OGC: Making location count...
http://www.opengeospatial.org/contact


On May 17, at 1:20 AM, Christine Perey wrote:

> Hi, 
> 
> When the charter of this group was developed, there was an ambiguity regarding fixed-location POI and those POI that are, in essence, everything else in the physical world. 
> 
> I strongly recommend that if the POI spec is to be important and valuable for everyone, the language needs to either NOT be specific about location being fixed [an inferior solution in my opinion] or specifically reflect support for both:
> 
> (1) fixed POI (POI which are fixed and not changing in geo-spatial coordinates over time) and 
> 
> (2) those POI that are not fixed in geo-spatial terms (cannot be distinguished uniquely by their location in geo-spatial coordinates at any point in time).
> 
> Please refer to numerous past meeting minutes and mailing list posts by Rob Manson, Dan Brickley, Alex Hill and others (myself [1]) regarding different ways to capture the spirit of points which are NOT also places, such as "objects" "things" (including people) and non-fixed points of interest. 
> 
> Regards,
> Christine
> 
> Spime Wrangler
> 
> 
> cperey@perey.com
> 
> mobile +41 79 436 6869
> VoIP +1 (617) 848-8159
> Skype Christine_Perey
> 
> [1] 
> http://lists.w3.org/Archives/Public/public-poiwg/2011Jan/0022.html
>  
> 
> 
> On 5/12/11 11:52 AM, Thomas Wrobel wrote:
>>> "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 Tuesday, 17 May 2011 13:22:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 17 May 2011 13:22:44 GMT