- From: Raj Singh <rsingh@opengeospatial.org>
- Date: Tue, 17 May 2011 09:22:17 -0400
- To: cperey@perey.com
- Cc: Thomas Wrobel <darkflame@gmail.com>, public-poiwg W3C <public-poiwg@w3.org>
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 UTC