From: Christine Perey <cperey@perey.com>

Date: Tue, 17 May 2011 07:20:18 +0200

Message-ID: <4DD20592.3050105@perey.com>

To: Thomas Wrobel <darkflame@gmail.com>

CC: public-poiwg W3C <public-poiwg@w3.org>

Date: Tue, 17 May 2011 07:20:18 +0200

Message-ID: <4DD20592.3050105@perey.com>

To: Thomas Wrobel <darkflame@gmail.com>

CC: public-poiwg W3C <public-poiwg@w3.org>

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 05:20:48 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 20:05:22 UTC
*