Copyright © 2011 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document was published by the Points of Interest Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-poiwg@w3.org (subscribe, archives). All feedback is welcome.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
In general terms, a "point of interest" is a location about which information is available. A POI can be as simple as a set of coordinates and an identifier, or more complex such as a three dimensional model of a building with names in various languages, information about open and closed hours, and a civic address. POI data has many uses including augmented reality browsers, location-based social networking games, geocaching, mapping, and navigation systems.
POI data has traditionally been exchanged in proprietary formats via various transports. This specification defines a flexible, lightweight, extensible POI data model, and one normative syntax for the data model. This will enable content publishers to effectively describe and efficiently serve and exchange POI data. In addition to the data model and format, this specification includes best practices for how to organize and serve POIs on the Web.
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.
The term points of interest is used in a broad sense in this specification to refer to a loosely coupled and inter-related set of terms: locations, POIs and places.
This section is primarily based on the wiki home page definition of POI.
The following primitives can be combined to represent a POI.
Geo-references are used a lot and were difficult to introduce just in the middle of the location primitive, so it got a promotion, even though it only appears in the location primitive.
A geo-reference is a reference to a location. A geo-reference can represent location in a variety of ways, such as the geospatial coordinates for the center of the POI, a civic address, an area (simple bounding box, or a polygon, or a 3d object), relative to a particular map or other geo-reference or undetermined. Geo-references are used in the location primitive.
A geo-reference is of one of the following types:
The Center geo-reference locates the center point of the POI. This type is largely used for display purposes.
Name | Required | Details |
---|---|---|
Coordinates | required | |
System | optional | If not specified WGS 84 is assumed |
Longitude | required | |
Latitude | required | |
Altitude | optional | Defines the height in meters above or below sea level |
An Address geo-reference is a civic address, such as a mailing address or a street address.
Name | Required | Details |
---|---|---|
Country | required | ISO country code (ISO 3166-1 alpha-3 country code) |
Language | required | ISO Language Code (3-alpha MARC language) |
Street | optional | Can contain a variable mix of house number prefix, suffix, street base name and or street type |
Floor | optional | +/- number |
Suite | optional | |
Region | optional | Repeating: can contain a variable mix of administrative regions, neighborhood, city, state, etc. |
Postal-code | optional |
This is our first reference to language tags, should we use ISO 3166-1 or BCP 47/IETF RFC 5646?
This section needs reworking. Within the XML syntax there's a notion of a list of points, as well as a point type that is reused. In the Wiki draft Routes and Areas both have point lists, we should extract the point list concept out so it can be shared.
Optional. Represents routes and traces.
An Area geo-reference represents a line-bounded area. The area is described by an ordered list of coordinates, where the first and last are the same.
I changed this one a bit, instead of introducing Points, I just made it have Coordinates, and mention that it is an ordered list of them where the first and last are the same. I figure the ordering can occur however such things happen in desired syntax (XML could be as they appear in document order or with an 'order' attribute, JSON may represent it as an array,etc)
Name | Required | Details |
---|---|---|
Coordinates | required | An ordered list of Coordinates, minimum of three, first and last must be the same. |
This geo-reference hasn't been written yet
Represents a 3D object, building, etc.
Name | Required | Details |
---|
An Undetermined geo-reference represents a location that as of yet is undetermined. This can be used to describe a Place prior to the final location being resolved.
There are no members for an Undetermined geo-reference.
I made relative a member of geo-reference rather than a sub-member of the map geo-reference, as it seems useful outside of the map scope
A Relative geo-reference is described in terms of distance from and bearing to another location.
Name | Required | Details |
---|---|---|
Relative-Location-Object | required | ID or location object (ID) this relative reference refers to |
Distance-From | required | |
Bearing-To | required | |
Relative height | optional |
The Map geo-reference allows points to be associated to maps.
Name | Required | Details |
---|---|---|
Supplier | required | The supplier of the map |
Version | required | The version of the map |
Map-Object-ID | required | A unique identifier for the map |
Side | optional | side of street, left / right / end |
Spot | optional | % distance from the Map object’s reference end-point |
Relative | optional | repeating. For representing a relative reference as opposed to an absolute geo-spatial location |
Reference-type | required | One of the geo-references, excluding Map |
The location primitive provides a rich and flexible description of the location of a POI. A location is a required part of a POI.
Name | Required | Details |
---|---|---|
Identifier | required | A unique identifier for this location. |
Geo-reference | required | A reference to the actual location |
I didn't follow the definition of a location identifier, so details were removed
The relationship primitive establishes 1-to-1 or 1-to-many relationships between POIs.
A relationship may be one of the following:
Need more relationship types
Should the details of the various relationship types themselves be in this section? Assuming yes for now
todo
todo
todo
Dropped per our discussion at f2f
POIs may have zero or more label primitives which represent a human readable label.
At F2F2 we decided to rename the name primitive to "label", and to allow labels to be marked as primary for each language represented.
POI must have an "id" primitive. It unambiguously identifies a POI within a particular implementation.
At F2F2 we discussed using URI fragments as IDs, as in XML. Using XML Base we could build a full URI that could then be used to identify the entire POI.
POI can have a "categorization" primitive, with one or more category identifiers.
Todo
Todo. Not sure how this would work, and why this wouldn't just be covered by our extensibility story
POI can have one or more time primitives that represent an individual point in time, a span of time, or a recurring time or time span.
We discussed at F2F2 basing this on other standards' time representations
This whole section is new stuff, unreviewed by the working group. Even more so than the rest of this document, this section is a straw man proposal, so please treat it as such!
This section describes an XML syntax to represent the data model.
Borrowed from MathML.
Notation | Meaning |
---|---|
decimal-digit | a decimal digit from the range U+0030 to U+0039 |
unsigned-integer | a string of decimal-digits, representing a non-negative integer |
integer | an optional "-" (U+002D), followed by a string of decimal digits, and representing an integer |
number | an optional prefix of "-" (U+002D), followed by an unsigned number, representing a terminating decimal number (a type of rational number) |
character | a single non-whitespace character |
string | an arbitrary, nonempty and finite, string of characters |
id | an identifier, unique within the document; must satisfy the NAME syntax of the XML recommendation [XML] |
idref | an identifier referring to another element within the document; must satisfy the NAME syntax of the XML recommendation [XML] |
URI | a Uniform Resource Identifier [RFC3986]. Note that the attribute value is typed in the schema as anyURI which allows any sequence of XML characters. Systems needing to use this string as a URI must encode the bytes of the UTF-8 encoding of any characters not allowed in URI using %HH encoding where HH are the byte value in hexadecimal. This ensures that such an attribute value may be interpreted as an IRI, or more generally a LEIRI, see [IRI]. |
We need to figure out: xml id/xml:base, xml:lang, units of measurement
pois
and poi
elementsThe root element for an POI in XML syntax is the pois
element. It contains one or more poi
elements.
poi/pois section is all TBD
Many of the elements described below rely on a coordinates as attributes. In the interest of not repeating the definition, the following attributes are inferred whenever the coordinate attributes
are referenced below.
Name | Required | Type | Default value | Details |
---|---|---|---|---|
system | optional | string | WGS84 | The name of the geodetic system to which the latitude and longitude are relative |
longitude | required | number | None | |
latitude | required | number | None | |
altitude | optional | number | ?? sea level relative to system? |
Is there an official geode tagging scheme, e.g. "wgs84", or "etrs89"?
<point>
elementThe <point>
element is used in many different geo-reference types below. It represents a single set of coordinates, and can be ordered relative to other <point>
elements within the parent element via the order
attribute.
The <point>
element has no character data.
The <point>
element uses the coordinate attributes
, and an order
attribute.
Name | Required | Type | Default value | Details |
---|---|---|---|---|
order | optional | unsigned-number | None | Applies only when a list of points is needed. Within the parent element containing the point list, there must be one <point> with the order attribute set to '0', other <point> element's order attribute must be unique and contiguous integers. Each point element within a point list must have the order attribute set. |
Do we want to use an order attribute? Document order? A single attribute with a list of comma separated coordinates?
<location>
elementThe <location>
element contains one or more geo-references elements (see below), and has no attributes or character data.
The following elements are the XML mapping for the geo-references outlined in the data model. Geo-references are used only with in the <location>
element.
<center>
elementThe <center>
element has no character data, and only the coordinate attributes
.
<address>
elementShould there be a way to assign languages to addresses or parts of addresses?
Representing addresses is a tricky business, see Geolocation WG and IETF geopriv.
The <address>
element may contain one or more <region>
elements.
Name | Required | Type | Default value | Details |
---|---|---|---|---|
country | required | string | None | ISO country code (ISO 3166-1 alpha-3 country code) |
lang | required | string | defaults to the language of the XML document | |
street | optional | string | None | Can contain a variable mix of house number prefix, suffix, street base name and or street type |
floor | optional | string | None | +/- number |
suite | optional | string | None | |
postal-code | optional | string | None |
<region>
elementThe <region>
element has no attributes and contains character data that...??
<area>
elementThe <area>
element must contain three or more <point>
elements. The first and last points in an area point list must have the same latitude, longitude and altitude. The area element has no attributes.
<object>
elementThis geo-reference hasn't been written yet
Name | Required | Type | Default value |
---|
<undetermined>
elementThe <undetermined>
element has no character data and no attributes.
<relative>
elementThe <relative>
element has no character data.
Name | Required | Type | Default value | Details |
---|---|---|---|---|
location-id | required | idref (not really, more of a xsd:anyURI as it can be external too) | None | The fragment identifier or URI of the object to which this location is relative. |
distance-from | required | integer | None | The distance this object is from the object referred to in the location-id attribute |
bearing-to | required | integer | None | ?? radians? degrees? |
relative-height | optional | integer | None |
<map>
element The <map>
element contains no character data and may contain one or more <relative>
elements.
Name | Required | Type | Default value | Details | |
---|---|---|---|---|---|
supplier | required | string | None | ||
version | required | string | None | ||
map-ref | required | URI | None | ||
side | optional | string | None | ||
spot | optional | string | None | ||
reference-type | required | string | None | Must be one of: center, address, navigation-point, area, or object |
<relationship>
element The <relationship>
element contains no character data.
Name | Required | Type | Default value | Details |
---|---|---|---|---|
type | required | string | None | must be one of: "contained-within","adjacent-to", or "contains" |
relative-to | required | URI | None |
<label>
elementTodo. At the f2f we agreed it would be label instead of name, and that multiples can exist, and one per language can be marked as primary
At F2F2 we discussed using URI fragments as IDs, as in XML. Using XML Base we could build a full URI that could then be used to identify the entire POI.
<category>
elementTodo
<time>
elementWe discussed at F2F2 basing this on other standards' time representations
This example was just something I generated while thinking through the XML syntax, it hasn't been updated to be in sync with what is in the document, so it may differ.
<?xml version="1.0" encoding="UTF-8"?> <pois> <poi id="StataCenter" xml:lang="en-US" > <label primary="true" xml:lang="en-US">Stata Center</label> <label primary="true" xml:lang="es">Stata Centro</label> <label>Ray and Maria Stata Center</label> <label>Building 32</label> <label>Gates Tower</label> <label>Dreyfoos Tower</label> <location id="location1"> <point latitude="42.360890561289295" longitude="-71.09139204025269"/> <point id="mainpoint" latitude="27.174799" longitude="78.042111" altitude="10m"/> <center latitude="27.174799" longitude="78.042111" radius="10m"/> <address language="en-US" country="USA" street="32 Vassar St." floor="5" suite="19" postalcode="02139"> <region>Cambridge</region> <region>Boston</region> <region>Massachusetts</region> </address> <route> <point order="0" latitude="42.360890561289295" longitude="-71.09139204025269"/> <point order="1" latitude="42.361176" longitude="-71.09018"/> <point order="2" latitude="42.36272976137689" longitude="-71.09049081802368"/> <point order="3" latitude="42.36318955298668" longitude="-71.09677791595459"/> <point order="4" latitude="42.363617631805496" longitude="-71.10156297683716"/> </route> <area> <point order="0" latitude="42.360890561289295" longitude="-71.09139204025269"/> <point order="1" latitude="42.361176" longitude="-71.09018"/> <point order="2" latitude="42.36272976137689" longitude="-71.09049081802368"/> <point order="3" latitude="42.36318955298668" longitude="-71.09677791595459"/> <point order="4" latitude="42.363617631805496" longitude="-71.10156297683716"/> <point order="5" latitude="42.360890561289295" longitude="-71.09139204025269"/> </area> <undetermined/> <map supplier="TeleTEQ" version="9" object-id="foobar" side="left" spot="2%"/> <relative location-id="mainpoint" distance-from="10m" bearing-to="20" relative-height="10m"/> </location> <category source="http://www.census.gov/cgi-bin/sssd/naics/naicsrch?search=2007%20NAICS%20Search&code=611310"> <name xml:lang="en-US">Colleges, Universities, and Professional Schools</name> </identification> <association type="child-of" reference="http://www.census.gov/cgi-bin/sssd/naics/naicsrch?search=2007%20NAICS%20Search&code=6113"/> </category> </poi> <poi id="w3c"> <label primary="true">World Wide Web Consortium</label> <label>W3C</label> <label>W3</label> <location> <address language="en-US" country="USA" street="32 Vassar St." floor="5" postalcode="02139"> <region>Cambridge</region> <region>Boston</region> <region>Massachusetts</region> </address> </location> <relation type="contained-by" id="#StataCenter"/> <category source="http://www.census.gov/cgi-bin/sssd/naics/naicsrch?search=2007%20NAICS%20Search&code=813920"> <name xml:lang="en-US">Standards review committees, professional</name> <name xml:lang="es">Normas de los comités de revisión, profesional</name> </identification> <association type="child-of" reference="http://www.census.gov/cgi-bin/sssd/naics/naicsrch?search=2007%20NAICS%20Search&code=8139"/> </category> </poi> </pois>
No normative references.
No informative references.