moving POI [was re: comments from OGC]

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.
>>>>
>