This document describes a data model and XML syntax for representing information about points of interest (POI) on the World Wide Web.

Introduction

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 navigation systems, mapping, geocaching, location-based social networking games, and augmented reality browsers.

POI data has traditionally been exchanged in proprietary formats by various transport mechanisms. 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.

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 possible POI use cases, therefore, the format is extensible, and it is expected that the data model will be mapped to other formats, such as JSON, GML, RDF, GeoRSS, or HTML.

Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [[RFC2119]].

Terminology

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.

Location
The term location is used to refer to an identifiable geographic place [[ISO19112]]. 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. Multiple POIs MAY share the same location. When a POI physically moves it is understood to have acquired a new location.
Points of Interest
Unlike the term location, the term POI is a human construct. POIs typically describe a location 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. For the purposes of this document, the term POI does not exclude the labeling, identification, and tracking of persons and other physical objects that have no permanent location.
Places
A place is also a human construct which typically has a coarse level of spatial granularity. Places are generally larger scale administrative constructs, either informally or formally defined. Countries, states, counties, districts, neighborhoods and postal codes or telephone area codes are all places. Places are also informally or colloquially defined, such as the Home Counties in the United Kingdom and the Bay Area in the United States.
Places have spatial relationships; with parents, children, adjacencies and contained by semantics. Places have the same attribute set as POIs, although often with differing interpretations based on scale; for example, the address of a Place or its URI might refer to the address of the administrative or governing body of the place.
A place typically contains multiple POIs and can also be coterminous with a POI. In the former case, a place, such as a city or a neighborhood, will contain multiple POIs. In the latter case, a place and a POI will occupy the same position and extent, such as in the case of Yellowstone National Park, which is both a Place and a POI. For the purposes of this document no distinction will be made between a place and a POI.
Coordinate
The term coordinate refers to one of a sequence of n numbers designating the position of a point in n-dimensional space [[ISO19111]].
Coordinate Reference System
The term coordinate reference system refers to a coordinate system that is related to an object by a datum [[ISO19111]].
Coordinate System
The term coordinate system refers to a set of mathematical rules for specifying how coordinates are to be assigned to points [[ISO19111]].
Datum
The term datum refers to a parameter or set of parameters that define the position of the origin, the scale, and the orientation of a coordinate system [[ISO19111]].
Geolocation
The term geolocation refers to the identification of the real world geographic location of an object.
Point
The term point refers to a 0-dimensional geometric primitive, representing a position [[ISO19107]].
Position
The term position refers to a data type that describes a point or geometry potentially occupied by an object or person [[ISO19133]].
Route
The term route refers to a sequence of links and / or partial links that describe a path, usually between two positions, within a network [[ISO19133]].
Coordinate Set
The term coordinate set refers to the individual parts of a coordinate. This is often a simple coordinate pair of latitude and longitude values, but based on the coordinate system used, MAY be other values, see .

POI Data Model

The Point of Interest data model consists of a POI entity and a POIS grouping entity. Each POI has a number of properties for capturing descriptive information along with a Location entity describing its location. In order to maximize the flexibility with which POI, POIS and their sub-entities can be described, each inherits its properties from a single common entity. In practical terms, this allows properties such as update time, authorship, links and other categorizations to be described at multiple levels of granularity within the data model.

More formally, the core data model consists of the POIType entity derived and having child entities derived from an abstract POIBaseType entity. This common POIBaseType allows the authorship, modification, and source of POIs to be attributed at the POI level, at the child entity level, and at a group level through the POIS grouping entity. Child entities are constructed from primtive datatypes, POIBaseType entities or POITermType entities having the additional properties:

  1. term: a machine readable character string to designate any number of discrete choices
  2. scheme: a URL pointing to the schema enumurating the discrete choices in term

Both the POI and POIS entity can contain any number of the following child entities:

  1. label: a human readable label for the POI that can be discriminated with a term property (e.g. primary, collogiual, etc.).
  2. description: a human readable description of the POI that can be discrimintated with a language property.
  3. category: like all things, there are many ways to categorize a POI. It could have a primary use, such as restaurant or museum; it could have a popularity rating; it could have a security classification.
  4. time: a POI exists within a certain context. Time is one of those contexts. The POI MAY have a known time when it came into being, and can therefore have a start date. The POI might no longer exist at a known point in time (in the future or in the past), and will therefore have an end date. There can be even more complex cases, where a POI exists on a regularly scheduled sequence of times. This specification handles that case also by allowing one to specify the time period using the iCalendar standard [[RFC5545]].
  5. link: adopted from the Atom link object [[RFC4087]], a link is a generic way to define a relationship from a POI to another POI, or from a POI to any other web resource.
  6. metadata: this is the place to attach formal metadata to the POI via reference or inline. It is anticipated that some people will use this for Dublin Core or ISO 19115 metadata.

The POI entity MUST contain a single Location entity having at least one Undertermined entity, and Address entity or a geometry entity containing a GML_CE_Geometry entity.

UML diagram of POI core data model

The entities of the core data model are described in more detail below.

POIBaseType

POIBaseType is the common entity from which the majority of POI entities are derived. It provides properties related to id, source, authorship, licensing, and modification times for creation, deletion and updating. This base type allows the POI entity, POIS grouping entity and most child entities to carry distinct information about their provinence, source and history.

Properties
Name Count Details Type
id [0..1] A unique identifier for this location. Can be a URI fragment. Refer to xml:base [[XMLBASE]] for more info string
href [0..1] An absolute reference to the POI content URI
value [0..1] The POI information content CDATA
base [0..1] XML base when id is not absolute. Refer to xml:base [[XMLBASE]] for more info URI
type [0..1] MIME type [RFC2046] string
lang [0..1] XML Language type [RFC3066] string
updated [0..1] Time this POI information was last changed [[ISO8601]] also refer to atom:updated [[RFC4087]] dateTime
created [0..1] Time at which this POI information was created dateTime
deleted [0..1] Time at which this POI information was deleted dateTime
author [0..1] Author of this POI information see location
license [0..1] License restrictions on this POI information see category

The id property is highly RECOMMENDED. Using a unique URL or a resolvable combination of id and base URI is also RECOMMENDED.

The href property MAY serve as an absolute reference to retrieve the POI information when the id and base do not combine to form a resolvable URL.

The value property is the RECOMMENDED location for arbitrary strings (e.g. label, description, etc.). Many entities derived from POIBaseType may not require this property (e.g. link, license, geometry entities).

The updated, created and deleted pro perties are for capturing the modification history of the POI information itself. Any information about the existence of the POI itself as a human concept should use the POIType time entity described below.

POITermType

The POITermType entity is an abstract entity derived from POIBaseType and adds properties for the management of categorical descriptions. The category, link, label, author, license and time entities in addition to the geometry elements point, line and polygon entities are all instances of POITermType.

Properties
Name Count Details Type
term [0..1] A machine-readable character string to designate any number of discrete choices URI
scheme [0..1] An absolute reference to the schema enumurating the dicrete choices in term URI

It is RECOMMENDED to utilize the value property inherited from POIBaseType when describing human readable categorical descriptions.

author

The author entity is of type POITermType and specifies a single author. The value property specifies the actual author and is determined by the type property (MIME type). When the mime type property is undetermined or text/plain the content of the value property is assumed to be free text. When the mime type property is text/vcard the value content is expected in VCard format [[RFC6350]].

Some Recommented Terms
Name Details
primary Primary author
secondary Secondary author
contributer A contributing author
editor Editor
publisher Publisher

Multiple authors can be specified by nesting author properties, and their authorship role MAY be discriminated with the term property (e.g. primary, publisher, editor, etc.).

license

The license entity is of type POITermType and specifies a single license. The language the license is in MAY be indicated using the lang property. Multiple licenses MAY be discriminated with the term property (e.g. common, opensource, etc.). The first license encountered per language is considered the primary license for that language.

POIType

The POIType entity is an abstract entity derived from POIBaseType and adds entities for describing, labeling, categorizing and indicating the time span of a POI or group of POIs. The entity also incudes child entities for linking to other POIs, external web resources or metadata.

Contains
Name Count Details Type
label [0..*] A human-readable name. Multiple names are used for synonyms and multiple languages POITermType
description [0..*] A human-readable description that can be discrimintated with the language attribute POIBaseType
category [0..*] A categorical classification of the POI. POITermType
time [0..*] A fixed time or sequence of times using iCalendar when the mime type is text/calendar POITermType
link [0..*] A link to another POI or web resource. POITermType
metadata [0..1] see Metadata

label

The label entity is of type POITermType and specifies any number of human readable labels. The language of label MAY be indicated using the lang property. Multiple labels MAY be discriminated with the term property (e.g. primary, colloquial, etc.). The first label encountered per language is considered the primary label for that language.

It is RECOMMENDED to use the term property to discriminate between different categories of label entities.

Some Recommented Terms
Name Details
primary The primary label
note An annotation label

description

The label entity is of type POITermType and specifies any number of human readable descriptions. The language the description is in MAY be indicated using the lang property. The first description encountered per language is considered the primary description for that language.

category

The category entity is of type POITermType and makes associations with any number of categories. Category is adopted from the atom:category object [[RFC4087]], and works in much the same way. A category should specify the type of POI, such as city, restaurant, etc. Multiple categories are allowed to accommodate the fact that POIs may be more than one thing. For example, a casino might be a gambling hall, a restaurant, and a concert venue. A grocery store may also be a bank and a pharmacy.

The category property classifies the POI using keywords. The category's value property is the keyword, or tag. The term is the classification scheme to which the value belongs. To emulate a "folksonomy" or "free tagging", the term should be "free". This tagging system MAY be more formally structured using the scheme property to specify a dictionary of terms or a web resource containing definitions of the terms and values. The href property MAY be used to provide a resolvable link to a more comprehensive definition of the category.

time

The time entity is of type POITermType and specifies any number of times applicable to a POIType entity (i.e. an individual point in time, a span of time, or a recurring time or time span).

A POI exists within a certain context. Time is one of those contexts. The POI may have a known time when it came into being, and can therefore have a start date. The POI might no longer exist at a known point in time (in the future or in the past), and will therefore have an end date. There can be even more complex cases, where a POI exists on a regularly scheduled sequence of times. The data model handles that case by allowing one to specify the time period using the iCalendar standard [[RFC5545]].

It is RECOMMENDED to use the term property to discriminate between different time entity categories.

Some Recommended Terms
Name Details
start Time when the POI came into being
end Time when the POI ceased to exist
instant A single time when an event happened
open A recuring time when a POI is open

When the mime type attribute is undetermined or text/plain the content of the value property is assumed to be in the dateTime format [[ISO8601]]. When the mime type attribute is text/calendar the value content is expected in iCalendar format.

link

The link entity is of type POITermType and adopted from the atom:link object [[RFC4087]] which works in the same way. A link is a generic way to define a relationship between the POI and other Web-accessible resources. Links are a powerful way to describe a host of relationships. One could argue that just as Web pages obtain most of their value by the links between them, a POI's value is directly related to the number of links between it and others. Links in POIs are perhaps even more important than links in Web pages or Atom feeds, as POIs are inherently place-based objects with natural relationships in space and time that should be expressed. Those spatial relationships are mostly covered by the Relationship primitive described below, which is in many ways a specialization of the generic Link. But there are many more semi-spatial and non-spatial relationships that can be expressed using Link.

This specification proposes a number of best practices for defining links. Key relations from the IANA registry are listed below in italics. Those relations in bold are defined only in this specification.

Relations
Name Details
alternate a identical POI. Often used as a permalink
canonical the preferred version of a set of POIs with highly similar content. For example, there could be many different perceptions of a neighborhood boundary POI, but the city's neighborhood map could be the canonical version of this POI.
copyright a copyright statement that applys to the link's context
describedby more information about this POI
edit a resource that can be used to edit the POI's context
enclosure a related resource that is potentially large and might require special handling
icon
latest-version points to a resource containing the latest version
license a license for this POI
related a related resource
search a resource that can be used to search through the link's context and related resources
parent a parent POI, often the enclosing geographic entity, or the entity this POI in under the domain of (such as a field office-corporate headquarters relationship)
child a child POI, often a geography entity enclosed or under the domain of this POI
historic links to a POI or other web resource that describes this place at a previous point in time
future links to a POI or other web resource that describes this place at a later point in time

metadata

Dublin Core or [[ISO19115]] metadata.

There is a WG question on whether this adequately addresses concerns about extensibility. See ISSUE-18.

POIS

The POIS entity is of type POIType and can have one or more children entities of type POI.

POI

The POI entity is of type POIType and adds the Location entity for describing the location of the POI.

Location

The Location entity is of type POIBaseType and provides a flexible description of the location of a POI. A Location can be represented in a variety of ways, such as the geodetic coordinates for the center of the POI, civic address, line, bounding box, polygon, or undetermined. A location is a REQUIRED part of a POI and has child entities describing geometry, address or the undetermined entity.

Contains
Name Count Details Type
point [0..*] A single coordinate GML_CE_Geometry
line [0..*] Two or more coordinates GML_CE_Geometry
polygon [0..*] Three or more coordinates GML_CE_Geometry
address [0..*] A civic address POIBaseType
relationship [0..*] A geo-spatial relationship to one or more POI Relationship
undetermined [0..1] Indicating the location is undertermined string

If a Location neither includes a geometry entity nor an address entity then it MUST include the undetermined entity.

Do we want to allow no child elements to indicate that dynamic data should be retrieved using the href property?

GML_CE_Geometry

The GML_CE_Geometry is the base entity from which all geometry entities are derived. It combines a coordinate system description with a set of coordinates.

Properties
Name Count Details Type
srsName [0..1] Coordinate reference system string
PosList 1 Contains coordinate set string

Coordinate Reference Systems

In all of the entities that specify geodetic coordinates, an srsName property is included in order to indicate the coordinate reference system (CRS) being used. The srsName value is a URI [[RFC3986]] indicating the CRS used and is http://www.opengis.net/def/crs/EPSG/0/4326 by default. This default is the URI for the World Geodetic System 84 (WGS84) in 2 dimensions, latitude and longitude. Other CRS URNs are allowed. In particular, the URI http://www.opengis.net/def/crs/EPSG/0/4979 indicates WGS84 in 3 dimensions, latitude, longitude and elevation in meters above sea level. The CRS used influences the interpretation of the coordinate set.

The default CRS refers to WGS84 geographic longitude and latitude expressed in decimal degrees, namely EPSG 4326, without the degrees symbol, "°". The values of latitude and longitude are bounded by ±90° and ±180° respectively. Positive latitudes are north of the equator, negative latitudes are south of the equator. Positive longitudes are east of the Prime Meridian, negative longitudes are west of the Prime Meridian. Latitude and longitude are expressed in that sequence, namely latitude before longitude.

Implementations are required to support the following CRS based on WGS 84 NIMA.TR8350.2-3e [[NIMA-TR8350-2]]. These are identified using the European Petroleum Survey Group (EPSG) Geodetic Parameter Dataset, as formalized by the Open Geospatial Consortium (OGC):

• http://www.opengis.net/def/crs/EPSG/0/4326: 2 dimensional WGS 84, latitude, and longitude
• http://www.opengis.net/def/crs/EPSG/0/4979: 3 dimensional WGS 84, latitude, longitude, altitude

The most recent version of the EPSG Geodetic Parameter Dataset should be used. A CRS must be specified using the above URI notation only, implementations do not need to support user-defined CRSs.

Are CRSes going to always be identified by URNs? There's discussion on the confusion in this thread. Raj mentioned OGC may be moving to URIs. The URN namespace ID ogc is registered with IANA.
Need a link to where OGC formalized this stuff.
Need reference for EPSG Geodetic Parameter Dataset, found this, but it seems to imply you need .NET to get updates, is this the right place?

This specification does not assign responsibilities for coordinate transformations from and to other Coordinate Reference Systems.

Note: The term coordinate set as used throughout this document refers to coordinates as influenced by the rules laid out above

Point

The Point entity is derived from POITermType and adds a single Point entity of type GML_CE_Geometry. It describes a single coordinate set, the interpretation of which is influenced by the CRS attribute.

Contains
Name Count Details Type
Point 1 A single coordinate defined in a particular CRS GML_CE_Geometry

It is RECOMMENDED to use the term property to discriminate between different Point entity categories.

Some Recommented Terms
Name Details
center The centroid of the Location
navigation point Generic navigation point
entrance Navigation poin to the entrance

The Point entity locates the centroid of the POI and is the most common way of specifying a location. For most places, such as cities, businesses, tourist sites, or events, a center location can be useful for many types of software applications where additional detail is unnecessary, such as driving directions or computing rough distances. Therefore, even if the POI is also specified with a polygon or a line, it is good practice to include a center point.

Line

The Line entity is derived from POITermType and adds a single LineString entity of type GML_CE_Geometry. It describes a list of two or more coordinate sets, the interpretation of which is influenced by the CRS attribute.

Contains
Name Count Details Type
LineString 1 A coordinate set defined in a particular CRS GML_CE_Geometry

A Line entity can be used to describe a linear feature, such as a road, a bike route, a river, etc.

Polygon

The Polygon entity is derived from POITermType and adds a single SimplePolygon entity of type GML_CE_Geometry. It describes a list of three or more coordinate sets, the interpretation of which is influenced by the CRS attribute. The last coordinate does not have to repeat the first coordinate in this simplified encoding, so only three control points are REQUIRED to specify a simple polygon.

Contains
Name Count Details Type
SimplePolygon 1 A coordinate set defined in a particular CRS GML_CE_Geometry

A Polygon entity describes the boundary of something. There is a WG question on whether we should support more complex topology than a simple polgyon, e.g. should we support holes? See ISSUE-43.

Address

The Address entity is of type POIBaseType and describes a civic address such as a mailing address or a street address. It's value is determined by the type property, and should be either vCard (text/directory) or free text (text/plain).

The data model and descriptions are inconsistent. Need to determine whether multiple addresses are allowed.

Undertermined

An Undetermined entity represents a location that is as of yet undetermined. This can be used to describe a POI prior to the final location being resolved. The Undetermined entity has no properties.

Relationship

This section is getting some expansion from OGC

The Relationship entity is derived from POITermType and establishes 1-to-1 or 1-to-many relationships between POIs. Each Relationship entity MUST be assigned one of 8 term properties that describe the geo-spatial relationship to the POI indicated by the targetPOI property.

[[ISO13249-3]] (SQL/MM Spatial) supports the general purpose relates operator from [[ISO19107]], which tests if two geometries (a and b) are related by testing the dimension of the intersections of their boundaries, interiors and exteriors. Points have a dimension of zero, curves one and surfaces two.

SQL/MM also supports the 19107 operator equals, which tests if two geometries are spatially equal. More formally, their symmetric difference MUST be empty. SQL/MM then adds seven semantic operators to test the relationship between geometries a and b. These relationships are expressed in terms of the boundary, interior and exterior intersections to avoid ambiguities.

Required Terms
Name Details
equals A equals B tests if the geometries are spatially equal. More formally, their symmetric difference MUST be empty. The test for equivalence may be limited to the resolution of the coordinate system or the accuracy of the data.
disjoint A disjoint B tests if A and B have NO points in common.
intersects A intersects B tests if A and B have ANY points in common.
crosses A crosses B if their interiors intersect with a dimension less that the larger of the dimension of A or B and the intersection of the interior of a with the exterior of B is not null (so for two lines, the intersection has to be at a finite number of points). Surfaces cannot cross anything. Points cannot be crossed by anything.
overlaps A overlaps B tests if part of their respective interiors intersect, and if this intersection is the same dimension as the interiors of the original geometries. (This last bit rules out crosses). Some of their interior MUST intersect with the exterior of the other one and vice versa (i.e., one cannot be within the other). This bit rules out within and contains. Overlap only applies if the two geometries are of the same dimension.
within A within B if their intersection equals A. e.g. a POI describing a store may state that it is contained within a shopping mall.
contains A contains B is equivalent to B within A. e.g. a POI describing a mall may state that it contains POIs for each store that is within the mall.
touches A touches B means one's boundary intersects with the other's interior or boundary. Interiors cannot intersect. Points cannot touch. e.g. a POI representing a store within a mall may state that it is next door to another POI which represents the store next door.

Diagram of the 8 allowed term attributes of the relationship element

XML Syntax

This section describes an XML syntax to represent the POI data model.

XML Notation

The following data types are from XML Schema, Part 2: Datatypes [[XMLSCHEMA11-2]]. The meanings are provided here as a convenience, for more complete information refer to the XML Schema, Part 2: Datatypes Recommendation.

Notation Meaning
booleanhas the ·value space· required to support the mathematical concept of binary-valued logic: {true, false}
decimala subset of the real numbers, which can be represented by decimal numerals
floatpatterned after the IEEE single-precision 32-bit floating point type [[IEEE 754-1985]].
doublepatterned after the IEEE double-precision 64-bit floating point type [[IEEE 754-1985]].
durationrepresents a duration of time.
dateTime may be viewed as objects with integer-valued year, month, day, hour and minute properties, a decimal-valued second property, and a boolean timezoned property. Each such object also has one decimal-valued method or computed property, timeOnTimeline, whose value is always a decimal number; the values are dimensioned in seconds, the integer 0 is 0001-01-01T00:00:00 and the value of timeOnTimeline for other dateTime values is computed using the Gregorian algorithm as modified for leap-seconds
timerepresents an instant of time that recurs every day
date consists of top-open intervals of exactly one day in length on the timelines of dateTime, beginning on the beginning moment of each day (in each timezone), i.e. '00:00:00', up to but not including '24:00:00' (which is identical with '00:00:00' of the next day)
gYearMonthrepresents a specific gregorian month in a specific gregorian year.
gYearrepresents a gregorian calendar year
gMonthDaya gregorian date that recurs, specifically a day of the year such as the third of May
gDaya gregorian day that recurs, specifically a day of the month such as the 5th of the month
gMonthgregorian month that recurs every year
anyURI represents a Uniform Resource Identifier Reference (URI). An anyURI value can be absolute or relative, and may have an optional fragment identifier

The terms base URI and relative URI are used in this specification as they are defined in [[RFC3986]].

We need to figure out: xml id/xml:base, xml:lang, units of measurement

POIBaseType common attributes

The majority of POI elements share the a coomon set of attributes defined by the POIBaseType data type. This list includes the <pois>, <pois>, <label>, <description>, <catergory>, <time>, <link>, <author> and <license> elements along with the geometry specific elements, <location>, <point>, <line>, <polygon>, <address> and <relationship>. Implementors may consider using an abstract base class when implementing those elements sharing the POIBaseType common attributes.

Attributes
Name Required Type Default value Valid Values Description
id false anyURI     A unique identifier for this location. Can be a URI fragment. Refer to xml:base [XMLBASE] for more info
href false anyURI a combination of xml:base, the document name and element id fragment   An absolute reference to the POIS element when an id is not given
xml:base false string URI of the document, or URI used to retrieve document or as defined by application context URI? @@not anyURI as fragments are not allowed specifies the base URI of the POI group, if different than the base URI of the document, see XML Base [[XMLBASE]] and RFC 3986 [[IRI]]
type false string   any valid MIME type as defined by [[RFC2046]] MIME type [[RFC2046]]
xml:lang false string ?? language identifiers as defined by [[BCP47]] specifies the language of the POI element, see XML Language Identification section [[XML11]]
updated false dateTime     Time this POI element was last changed [[ISO8601]] also refer to atom:updated [[RFC4087]]
created false dateTime     Time at which this POI element was created
deleted false dateTime     Time at which this POI element was deleted

POITermType common attributes

Several POI elements share the set of attributes defined by the POITermType data type. This includes the <label>, <catergory>, <time>, <link>, <author> and <license> elements along with the geometry specific elements, <point>, <line>, <polygon>, <address> and <relationship>. The POITermType common set of attributes includes those of the POIBaseType common attributes. Refer to the POIBaseType common attributes for a list of those attributes. Implementors may consider using an abstract base class when implementing those elements sharing the POITermType common attributes.

Attributes
Name Required Type Default value Valid Values Description
term false anyURI     A machine-readable character string to designate any number of discrete choices
scheme false anyURI     An absolute reference to the schema enumurating the dicrete choices in term

<pois> element

The top-level wrapper element for a group of individual POI elements. The <pois> element MUST contain one or more <poi> elements.

The <pois> element includes those attributes in the POIBaseType common attributes set. Refer to POIBaseType common attributes for a list of those attributes. Implementors may consider using an abstract base class when implementing this element.

children

  • <label> A label describing the poi group. Occurs zero or more times. See
  • <description> A description of the poi group. Occurs zero or more times. See
  • <category> A category of the poi group. Occurs zero or more times. See
  • <time> A time associated with the poi group. Occurs zero or more times. See
  • <link> A link to a web resource. Occurs zero or more times. See
  • <metadata> A link to a metadata. Occurs zero or one times. See
  • <author> Authorship attribution of the poi group. Occurs zero or one times. See
  • <license> License information of the poi group. Occurs zero or one times. See
  • <poi> A point of interest. Occurs one or more times. See

<poi> element

The wrapper element for individual POI elements. The <poi> element MUST contain one <location> element.

The <poi> element includes those attributes in the POIBaseType common attributes set. Refer to POIBaseType common attributes for a list of those attributes. Implementors may consider using an abstract base class when implementing this element.

children

  • <label> A label describing the poi element. Occurs zero or more times. See
  • <description> A description of the poi element. Occurs zero or more times. See
  • <category> A category of the poi element. Occurs zero or more times. See
  • <time> A time associated with the poi element. Occurs zero or more times. See
  • <link> A link to a web resource. Occurs zero or more times. See
  • <metadata> A link to a metadata. Occurs zero or one times. See
  • <author> Authorship attribution of the poi element. Occurs zero or one times. See
  • <license> License information of the poi element. Occurs zero or one times. See
  • <location> The location of the poi element. Occurs one or more times. See

<author> element

The label element specifies a single authorship for the parent element.

The <author> element includes those attributes in the POITermType common attributes set. Refer to POITermType common attributes for a list of those attributes. Implementors may consider using an abstract base class when implementing this element.

The element value specifies the actual author and is determined by the type attribute (MIME type). When the mime type attribute is undetermined or text/plain the content of the value is assumed to be free text. When the mime type property is text/vcard the value content is expected in VCard format [[RFC6350]].

Some Recommented Terms
Name Details
primary Primary author
secondary Secondary author
contributer A contributing author
editor Editor
publisher Publisher

Multiple authors can be specified by nesting author properties, and their authorship role MAY be discriminated with the term property (e.g. primary, publisher, editor, etc.).

<license> element

The label element specifies a single lincense for the parent element.

The language of the license may be indicated using the lang property. Multiple licenses may be discriminated with the term property (e.g. common, opensource, etc.). The first license encountered per language is considered the primary license for that language.

The <label> element includes those attributes in the POITermType common attributes set. Refer to POITermType common attributes for a list of those attributes. Implementors may consider using an abstract base class when implementing this element.

The option to have multiple licenses contradicts the data model described above.

<label> element

The label element specifies any number of human readable labels.

The <label> element includes those attributes in the POITermType common attributes set. Refer to POITermType common attributes for a list of those attributes. Implementors may consider using an abstract base class when implementing this element.

The language of label MAY be indicated using the lang property. Multiple labels MAY be discriminated with the term property (e.g. primary, colloquial, etc.). The first label encountered per language is considered the primary label for that language.

It is RECOMMENDED to use the term property to discriminate between different categories of label entities.

Some Recommented Terms
Name Details
primary The primary label
note An annotation label

children

  • <value> The label content. Occurs zero or one times. See
  • <author> Authorship attribution of the element. Occurs zero or one times. See
  • <license> License information of the element. Occurs zero or one times. See

<value> element

An element to hold parent element CDATA content.

Elements sharing the set of POIBaseType common attributes can also have child elements such as <author> and <license>. This can result in elements that are of mixed content type and inlcude both CDATA content and child elements. The <value> element allows for elements written in a complex type to alternately encapsulate their CDATA content within a child <value> element.

The following is a label element and content with no child elements

The following is a <label> element with children and content in a <value> element

<description> element

The label element specifies any number of human readable descriptions.

The <description> element includes those attributes in the POIBaseType common attributes set. Refer to POIBaseType common attributes for a list of those attributes. Implementors may consider using an abstract base class when implementing this element.

The language of description MAY be indicated using the lang property. The first description encountered per language is considered the primary label for that language.

children

  • <value> The label content. Occurs zero or one times. See
  • <author> Authorship attribution of the element. Occurs zero or one times. See
  • <license> License information of the element. Occurs zero or one times. See

<category> element

The category element makes associations with any number of categories.

The <category> element includes those attributes in the POITermType common attributes set. Refer to POITermType common attributes for a list of those attributes. Implementors may consider using an abstract base class when implementing this element.

The language of the category MAY be indicated using the lang property. The first category encountered per language is considered the primary category for that language.

The category element classifies the POI using keywords. The term atribute is the classification scheme to which the value belongs. The schema that includes the term MAY be more formally structured using the schema attribute to specify a dictionary of terms or a web resource containing definitions of the terms and values. The href atrribute MAY be used to provide a resolvable link to a more comprehensive definition of the category.

children

  • <value> The label content. Occurs zero or one times. See
  • <author> Authorship attribution of the element. Occurs zero or one times. See
  • <license> License information of the element. Occurs zero or one times. See

See ISSUE-24.

<time> element

The time element specifies any number of applicable times.

The <time> element includes those attributes in the POITermType common attributes set. Refer to POITermType common attributes for a list of those attributes. Implementors may consider using an abstract base class when implementing this element.

It is RECOMMENDED to use the term property to discriminate between different time entity categories.

Some Recommended Terms
Name Details
start Time when the <poi> or <pois> group came into being
end Time when the <poi> or <pois> group ceased to exist
instant A single time when an event happened
open A recuring time when a <poi> or <pois> group is open

When the mime type attribute is undetermined or text/plain the content of the value is assumed to be in the dateTime format [[ISO8601]]. When the mime type attribute is text/calendar the value content is expected in iCalendar format.

children

  • <value> The label content. Occurs zero or one times. See
  • <author> Authorship attribution of the element. Occurs zero or one times. See
  • <license> License information of the element. Occurs zero or one times. See

See ISSUE-26.

<metadata> element

Dublin Core or [ISO19115] metadata.

See ISSUE-18.

<location> element

The wrapper element for the location of a <poi> element. The <location> element MUST contain either a single <undetermined> element, an <address> element or one of the geometry elements, <point>, <line>, <polygon> or <relationship>.

The <location> element includes those attributes in the POIBaseType common attributes set. Refer to POIBaseType common attributes for a list of those attributes. Implementors may consider using an abstract base class when implementing this element.

children

  • <undetermined> An element representing an undertermined location. Occurs zero or one times. See
  • <address> A civic address. Occurs zero or one times. See
  • <point> A point. Occurs zero or more times. See
  • <line> A line. Occurs zero or more times. See
  • <polygon> A polygon. Occurs zero or more times. See
  • <relationship> A geometric relationship to another poi element. Occurs zero or more times. See
  • <author> Authorship attribution of the element. Occurs zero or more times. See
  • <license> License information of the element. Occurs zero or more times. See

<address> element

A civic address such as a mailing address or a street address.

The value content is interpreted by the type property, and should be either vCard (text/directory) or free text (text/plain).

The language of address MAY be indicated using the lang property. The first address encountered per language is considered the primary address for that language.

children

  • <value> The label content. Occurs zero or one times. See
  • <author> Authorship attribution of the element. Occurs zero or one times. See
  • <license> License information of the element. Occurs zero or one times. See

See ISSUE-40

<undetermined> element

Represents a location that is as of yet undetermined. The <undetermined> element has no properties.

<point> element

Any number of individual points. The <point> element MUST contain one <Point> element.

The <point> element includes those attributes in the POITermType common attributes set. Refer to POITermType common attributes for a list of those attributes. Implementors may consider using an abstract base class when implementing this element.

It is RECOMMENDED to use the term property to discriminate between different categories of <point> elements.

Some Recommented Terms
Name Details
center The centroid of the location
navigation point Generic navigation point
entrance Navigation poin to the entrance

children

  • <Point> A single Point element using the GML_CE_Geometry schema. Occurs one time. See
  • <author> Authorship attribution of the element. Occurs zero or one times. See
  • <license> License information of the element. Occurs zero or one times. See

<Point> element

Describes a single coordinate set in GML Compact Encoding (GML_CE_Geometry), the interpretation of which is influenced by the srsName attribute.

Attributes
Name Required Type Default value Valid Values Description
srsName false string http://www.opengis.net/def/crs/EPSG/0/4326   Coordinate reference system
PosList true string     Space separated coordinate sets separated by comma

The PosList attribute MAY contain sets of 2 or 3 coordinates. When PosList contains sets of 3 coordinates and coordinate 3 units are meters, the srsName MUST be http://www.opengis.net/def/crs/EPSG/0/4979.

Do we want to use an order attribute? Document order? A single attribute with a list of comma separated coordinates?
Now tracked as: ISSUE-19: how should we represent points? and a related issue: ISSUE-36: do we want to rely on document order?.

<line> element

Any number of individual lines. The <line> element MUST contain one <LineString> element.

The <line> element includes those attributes in the POITermType common attributes set. Refer to POITermType common attributes for a list of those attributes. Implementors may consider using an abstract base class when implementing this element.

It is RECOMMENDED to use the term property to discriminate between different categories of <line> elements.

children

  • <LineString> A single line string element using the GML_CE_Geometry schema. Occurs one time. See
  • <author> Authorship attribution of the element. Occurs zero or one times. See
  • <license> License information of the element. Occurs zero or one times. See

<LineString> element

Describes a line using two or more coordinate sets in GML Compact Encoding (GML_CE_Geometry), the interpretation of which is influenced by the srsName attribute.

Attributes
Name Required Type Default value Valid Values Description
srsName false string http://www.opengis.net/def/crs/EPSG/0/4326   Coordinate reference system
PosList true string     Space separated coordinate sets separated by comma

The PosList attribute MAY contain sets of 2 or 3 coordinates. When PosList contains sets of 3 coordinates and coordinate 3 units are meters, the srsName MUST be http://www.opengis.net/def/crs/EPSG/0/4979.

<polygon> element

Any number of polygonal areas. The <polygon> element MUST contain one <SimplePolygon> element.

The <polygon> element includes those attributes in the POITermType common attributes set. Refer to POITermType common attributes for a list of those attributes. Implementors may consider using an abstract base class when implementing this element.

It is RECOMMENDED to use the term property to discriminate between different categories of <line> elements.

children

  • <SimplePolygon> A single simple polygon element using the GML_CE_Geometry schema. Occurs one time. See
  • <author> Authorship attribution of the element. Occurs zero or one times. See
  • <license> License information of the element. Occurs zero or one times. See

<SimplePolygon> element

Describes a polygon using three or more coordinate sets in GML Compact Encoding (GML_CE_Geometry), the interpretation of which is influenced by the srsName attribute. The last coordinate does not have to repeat the first coordinate in this simplified encoding, so only three control points are REQUIRED to specify a simple polygon.

Attributes
Name Required Type Default value Valid Values Description
srsName false string http://www.opengis.net/def/crs/EPSG/0/4326   Coordinate reference system
PosList true string     Space separated coordinate sets separated by comma

The PosList attribute MAY contain sets of 2 or 3 coordinates. When PosList contains sets of 3 coordinates and coordinate 3 units are meters, the srsName MUST be http://www.opengis.net/def/crs/EPSG/0/4979.

There is a question on whether we should support more complex topology than a simple polgyon, e.g. should we support holes? See ISSUE-43.

<relationship> element

Establishes 1-to-1 or 1-to-many relationships between <poi> or <pois> elements.

The <relationship> element includes those attributes in the POITermType common attributes set. Refer to POITermType common attributes for a list of those attributes. Implementors may consider using an abstract base class when implementing this element.

Attributes
Name Required Type Default value Valid Values Description
targetPOI true string     target <poi> or <pois> element of the relationship

Each <relationship> element MUST be assigned one of 8 term values that describe the geo-spatial relationship to the <poi> or <pois> element indicated by the targetPOI property.

Required Terms
Name Details
equals A equals B tests if the geometries are spatially equal. More formally, their symmetric difference MUST be empty.
disjoint A disjoint B tests if A and B have NO points in common.
intersects A intersects B tests if A and B have ANY points in common.
crosses A crosses B if their interiors intersect with a dimension less that the larger of the dimension of A or B and the intersection of the interior of a with the exterior of B is not null.
overlaps A overlaps B tests if part of their respective interiors intersect, and if this intersection is the same dimension as the interiors of the original geometries.
within A within B if their intersection equals A. e.g. a POI describing a store may state that it is contained within a shopping mall.
contains A contains B is equivalent to B within A. e.g. a POI describing a mall may state that it contains POIs for each store that is within the mall.
touches A touches B means one's boundary intersects with the other's interior or boundary.

children

  • <author> Authorship attribution of the element. Occurs zero or one times. See
  • <license> License information of the element. Occurs zero or one times. See

Need to resolve if allowing pois elements satisfies the 1-to-many intentions of this element.

XML Example

This example does not exercise the complete schema and may need revision.

XML Schema

This is informational only. A separate document will eventually provide access to the schema and schema definition.

Schema of POI core data model

Use Cases

Acknowledgements