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

On 17 May 2011 07:20, Christine Perey <cperey@perey.com> 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.

Regarding decision record papertrail --

"RESOLUTION: There are lots of ways of identifying relevant POI
descriptions, including GPS, QR Codes, image recognition (of specific
things, of types of thing, of places, people, RFIDs). W3C POI data
should be easily associated via various such techniques, and not be
rigidly tied to any particular association mechanism."

.... from Day 2 of Amsterdam F2F,
http://www.w3.org/2010/POI/wiki/Face_to_Face_Meetings/March_2011
http://www.w3.org/2011/03/30-poiwg-minutes.html

While it could be more explicit, this quite strongly suggests we are
working on describing things that might be mobile (hence mention of
QR codes, RFID, people, ...).

If the first public Working Draft doesn't address all these needs, I
can live with that. But I think the decision was sound, and I hope
supported by those who couldn't be at the f2f.

cheers,

Dan


> [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:47:17 UTC