Core/Draft

Heading materials

Current Version link

Latest Version link

Previous Version link

trademarks, etc.

Intro

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.

Restrictions:

• 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.

TBD

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 con contain text.

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

name primitive

POI must have a "name" primitive that is a human description of the name of the POI. It is a specialization of the string primitive.

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

Requirements

@@

Other Requirements

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

Notes

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

Requirements

• 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

Details

POI can have one or more "time" primitives

Notes

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. http://www.w3.org/2011/03/29-poiwg-irc#T14-23-21

Extensibility

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

Appendix: Examples

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

<poi>
	<name id='foobar'>
		<lang>en/us</lang>
		<value>The Foo Bar</value>
	</name>
	<location>
		<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"/>
	</location>
</poi>

<poi>
	<name id='foobar'>
		<lang>en/us</lang>
		<value>The Foo Bar</value>
	</name>
	<location>

	</location>
</poi>