From Points of Interest
Revision as of 10:39, 31 March 2011 by Mdw (Talk | contribs)

Jump to: navigation, search

Heading materials

Current Version link

Latest Version link

Previous Version link

trademarks, etc.

Status of the Document

Table of Contents


This is an editor's draft of the data model for a point of interest as discussed at the first POI WG face to face.

A Point of Interest, for the purposes of this document, is defined as an aggregate of a place, its spatial location, and its descriptive metadata attributes, each of which is detailed below.

Core POI @@doodads@@

A POI is described by the following list of elements:

  1. Location
  2. Name
  3. Relationships
  4. Identifier
  5. Category
  6. Temporal Information
  7. Meta-data
  8. Extensibility


  1. must have 1/a location primitives (is at)
  2. can have "contained within", "contains" 1-to-many relationships
  3. can have "adjacent-to" 1-to-many relationships (may help w/ routes and discoverability)
  4. must have a "name" primitive (human description)
  5. must have an "id" primitive
  6. can have a "categorization" primitive
  7. can have a "meta data" primitive (creation time, authorship, visibility rights, etc)
  8. can have a "time" primitive
  9. must be extensible (method of payment, opening closing hours, 3D content, images, multimedia...)

Location primitive

Goal: Provide a rich and flexible description of a location

De-couple or isolate the description of a Place of Interest from its geospatial location, since many Places can be at the same location, and Places of Interest can change locations.

A Place of Interest can be a parent to other Places Of Interest each with its own location to allow for the representation of complex places that are the aggregate of a collection of Places (campuses, business with multiple entrances, large constructs like parks, etc.).

It should not be inferred that each of the elements within the location primitive are not spatially synonymous, but do refer to the same place.


  • A Place Of Interest must have a location
  • A Place of Interest must have one location.

High Level Attribution:

Place Of Interest
…other descriptive primitives
Location : required
Identification : required
Geo-Reference : required

Supported by :

Change-Reference primitive : optional
<to be defined later, for reuse across other primitives and attributes to describe ownership and change data>
<for example below>
Last Updated On : Date/Time (optional)
Updated By : owner / author (optional)
For Use By : public, private, restrictions (optional)
Current Status : Active, blocked, deleted (optional)
Trustworthiness : degree of certainty the author has in the accuracy of the information in the associated primitive, based on a 5 star (high) to 1 star (low) simple rating

Location Attribution Details

Location : required

Identification : required
ID : required : +Change-Reference : number or string
Name : optional : +Change-Reference : reference or name
Path to ID : optional : +Change-Reference : URL path to the Identification System or Service : Change-Reference
Associations : optional : +Change-Reference : list of other replacement, old or depreciated IDs that belong to this ID  : Change-Reference
Geo-Reference : required
<must include at least one of the location types below>
Center : optional : +Change-Reference : center of the parcel, building area, largely for display
Coordinates : required
System : optional : assumes WGS 84 (optional)
Longitude : required
Latitude : required
Altitude : optional : defines the height in meters above or below sea level
Navigation-Point : optional : +Change-Reference : point that is the logical destination for routing
Coordinates : required : <see above for details>
Address : optional : +Change-Reference : any civil address
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
Route : optional : +Change-Reference : for representing routes and traces
Point : required : repeating for a directed linked list of points
Type : required : one of : Start/End/way point
Coordinates : required : <see above for details>
Area : optional : +Change-Reference : for representing a line-bounded area
Point : required : repeating for a directed linked list of points
Type : required : one of : Start/End/way point
Coordinates : required : <see above for details>
Object : optional : +Change-Reference : for representing a 3D object, building, etc.
Undetermined : optional : +Change-Reference : for representing a location as yet undetermined, such that a Place and its description can exist prior to the final location being resolved
Map : optional: +Change-Reference : for associations to digital, navigable maps
Supplier : required : NAVTEQ, TeleAtlas, Google, OSM, etc.
Version : required : Q1 2011, OSM v3.16, etc.
Map-Object-ID : required
Side : optional : side of street, left / right / end
Spot : % distance from the Map object’s reference end-point
Relative : optional : +Change-Reference : repeating : for representing a relative reference as opposed to an absolute geo-spatial location
Reference-type : required : one of : Center, Navigation-Point, Address, Route, Area, Object, Relative, Map
Relative-Location-Object : required : ID or location object (ID) this relative reference refers to
Distance-From : required
Bearing-To: required
Relative height : optional

Relationship primitive

A POI can have 1-to-many relationships with other POIs of the types "contained-within", "contains", "adjacent-to" and ??...

@@ TBD: how POIs are identified @@ @@ TBD: enforcing bi-directionality of relationships? @@

string primitive

The string primitive is used when any attribute can contain text.

The string primitive is made up of a unicode string and a language identifier.

name primitive

This has been replaced by the label primitive.

label primitive


  • Different labels for different languages (either the whole document can support multiple languages for everything, or we can have a label-only mechanism, TBD)
  • There must be a way to determine which label is the "primary" label

Other Requirements

  • Do we want to specify what the different alt labels are? Legal names? Other modifiers?


POI may have zero or more label primitives that are human labels of the POI.


We talked about having labels, alternative labels, and labels in different languages. See F2F #2 Day 3.

Some examples we spoke about:

<poi xml:lang="en-US">
  <preferredlabel>California Pizza Kitchen</preferredlabel>
  <preferredlabel xml:lang="it">California Pizza Cucina</preferredlabel>
  <preferredlablel xml:lang="ko">캘리포니아 피자 식당</>
  <altlabel xml:lang="it">CPC</altlabel>
<poi xml:lang="en-US">
  <preferredlabel>California Pizza Kitchen</preferredlabel>
  <preferredlabel xml:lang="it">California Pizza Cucina</preferredlabel>
  <altlabel type="abbr">CPK</altlabel>
  <altlabel xml:lang="it" type="abbr">CPC</altlabel>
<poi xml:lang="en-US">
  <preferredlabel>California Pizza Kitchen</preferredlabel>
  <preferredlabel xml:lang="it">California Pizza Cucina</preferredlabel>
  <altlabel foobar:labeltype="http://...">CPK</altlabel>
  <altlabel xml:lang="it" foobar:labeltype="http://...">CPC</altlabel>
<?xml version="1.0" lang="en-US" encoding="UTF-8">
  <label primary="true">California Pizza Kitchen</label>
  <label primary="true" xml:lang="it">California Pizza Cucina</label>
  <label primary="true" xml:lang="ko">캘리포니아 피자 식당</label>
  <label xml:lang="it">CPC</label>

id primitive

POI must have an "id" primitive. It unambiguously identifies a POI within a particular implementation.

More on this thread.

@@ TBD around all of id @@

categorization primitive



Other Requirements

POI can have a "categorization" primitive, with one or more category identifiers.


See this thread for more discussion Karl's document on categories.

@@ TBD: required or not? @@

meta data primitive

POI can have a "meta data" primitive (creation time, authorship, visibility rights, etc)

@@ TBD @@

time primitive


  • Data type for universally representing an individual point in time
  • Data type for representing spans between points in time
  • Names for these attributes

Possible requirements

  • Recurring times
  • Recurring time spans


POI can have one or more "time" primitives


We will attempt to reuse other standards such as GML, KML, OSM, etc.

We will be tracking this as ISSUE-7.

16:21 danbri: proposal re temporal aspects: POI spec should allow for temporal characteristics of the description/record (publication date, 'coverage' / when it's true dates); and also of the payload, including domain specific extensions such as shop opening hours, movie show times, or historical periods for sites of touristic interest.


POI must be extensible (method of payment, opening closing hours, 3D content, images, multimedia...) @@ TBD @@

Appendix: use cases

Appendix: Examples

@@ Non-normative examples used while creating this document @@

	<name id='foobar'>
		<value>The Foo Bar</value>
		<coords id="coords" x="23.234234" y="34234"/>
		<address>1234 Mockingbird Lane</address>
		<mbr x1="23.234234" y1="92.2349" x2="6" y2="-3.1459"/>

	<name id='foobar'>
		<value>The Foo Bar</value>