Points of Interest Core

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 a geographical construct, a physically fixed point, typically on the surface of the Earth (relative to WGS-84), though locations can be relative to another coordinate system. 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.
OGC has suggested the following changes to the definition of location: FYI, Point of Interest is defined in the OGC Open Location Services 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 [[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.
Points of Interest: Unlike the term location, the term POI is a human construct. POIs describe information about locations such as name, category, unique identifier, or civic address.
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 also have the same attribute set as POIs, although with differing interpretations based on scale; for example, the address of a Place or its URI would 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.
Primitive: The term primitive refers to the basic components of a POI. For example, a POI could be a collection of location and category primitives.
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 core POI data model includes four primitives:

location: information describing where the POI is located. This could be as specific geographic location described by latitude-longitude coordinates, or if that is not possible, an address, or the location could be undetermined pending more or better information.
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. The possibilities are endless. Categories allow a POI to be classified in all these ways.
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 [[ICALENDAR]].
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.

These primitives combine to define a POI, and are described in more detail below.

POI

POI is the object that serves as the container for all the primitives that define and describe the POI.

Contains

Name	Required	Details	Type
id	required	A unique identifier for this location. Can be a URI fragment. Refer to xml:base [[XMLBASE]] for more info	URI
label	recommended	A human-readable name. Multiple names are used for synonyms and multiple languages. One name is considered the "primary" name for each language.	String
updated	recommended	Time this POI information was last changed. Refer to atom:updated	ISO8601
startTime	optional	The time at which this POI came into existence	ISO8601
endTime	optional	The time at which this POI ceased to exist	ISO8601
location	required	see	location
category	optional	see	category
metadata	optional	see	metadata

Coordinate Reference Systems

In all of the primitives that specify geodetic coordinates, an srsName is included in order to indicate the coordinate reference system (CRS) being used. The srsName value is a URN [[RFC3406]] indicating the CRS used and is urn:ogc:def:crs:EPSG::4326 by default. This default is the URN for the World Geodetic System 84 (WGS84) in 2 dimensions, latitude and longitude. Other CRS URNs are allowed. 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):

urn:ogc:def:crs:EPSG::4326: 2 dimensional WGS 84, latitude, and longitude
urn:ogc:def:crs:EPSG::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 URN 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.
Why do we use srsName and not crsname? Is 'name' a misnomer? Perhaps just 'srs' or 'crs' is sufficient.
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?

Implementations MUST specify the CRS using the "srsName" attribute on the outermost geometry element. The CRS MUST NOT be respecified or changed for any sub-elements.

Should we be more specific that it's just on geometry elements that disallows sub-elements? e.g. you could have <pois> with no CRS specified, but a POI could specify 3d WGS84. I think this text means simply disallowing a line to have multiple CRSes.

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

Location Primitive

The location primitive provides a rich and flexible description of the location of a POI. A location is a required part 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.

The Point location type 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 bounding box, it is good practice to include a center point.

The center location type has been dropped

Location Types

Name	Required	Type
point	optional	GML Point
navigation point	optional	GML Point
line	optional	GML LineString
polygon	optional	GML Polygon
box	optional	GML Envelope
address	optional	civic address
relationship	optional
undetermined	optional	text

Point

A Point contains a single coordinate set, the value of which is influenced by the CRS as described in .

Contains

Name	Required	Details
srsName	optional	See
pos	required	Contains the coordinate set

Navigation Point

A Navigation Point is a point that is the logical destination for routing. For example, this may be a reference to the entrance of parking lot POI. It's format is the same as a Point. Therefore, it contains a single coordinate set the value of which is influenced by the CRS as described in .

Contains

Name	Required	Details
srsName	optional	See
pos	required	Contains the coordinate set

LineString

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

LineStrings contain two or more coordinate sets, the values of which are influenced by the CRS as described in . The coordinate sets are delimited by white-space.

The white-space mention sounds very serialization-y. Also need reference for what a white-space actually is, which is also serialization-y stuff.

Contains

Name	Required	Details
srsName	optional	See
posList	required	Contains the coordinate pairs

Polygon

A Polygon describes the boundary of something.

Polygons contain four or more coordinate sets, the values of which are influenced by the CRS as described in . The coordinate sets are delimited by white-space. The last coordinate pair must be identical to the first.

Again, white-space mention sounds like a serialization detail.

Contains

Name	Required	Details
srsName	optional	See
exterior	required	specifies the outer boundary of the shape
interior	optional	used to specify one or more a holes in the shape
LinearRing	required	contained by exterior and interior
posList	required	Contains the coordinate pairs

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.

Envelope

An Envelope is used to represent a square area. An Envelop contains exactly two coordinate sets which represent two non-adjacent corners of the box. Coordinate sets are separated from each other by a space. The first coordinate set ("lower corner") must be a point further west and south of the second coordinate pair ("upper corner") and the box is always interpreted as not containing the 180 (or -180) degree longitude line other than on its boundary and not containing the North or South pole other than on its boundary. A box is generally used to roughly demarcate an area within which other data lie.

Again, white-space mention sounds like a serialization detail.

This is very WGS-84 specific. West/south, lat/long. Needs rewrite?

I added text about box, as it seems like a more relatable term, and the non-adjacent corners thing, needs cleanup

Contains

Name	Required	Details
srsName	optional	See
lowerCorner	required	contains a coordinate set
upperCorner	required	contains a coordinate set

Address

Note:Support for addresses has been dropped for this WD, but may return in future revisions, and thus remains here in the data model.

from Carl: For civic locations, not sure what you want to do. Perhaps follow what KML does? KML uses the OASIS CIQ/xAL standard as the basis for encoding addresses. Works pretty well in most all countries. From the KML documentation:
<address>
A string value representing an unstructured address written as a standard street, city, state address, and/or as a postal code. You can use the <address> tag to specify the location of a point instead of using latitude and longitude coordinates. (However, if a <Point> is provided, it takes precedence over the <address>.)
<xal:AddressDetails>
A structured address, formatted as xAL, or eXtensible Address Language, an international standard for address formatting. <xal:AddressDetails> is used by KML for geocoding in Google Maps only. For details, see the Google Maps API documentation. Currently, Google Earth does not use this element; use <address> instead. Be sure to include the namespace for this element in any KML file that uses it: xmlns:xal="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0"

An Address is a civic address, such as a mailing address or a street address.

Contains

Name	Required	Details
Country	required	ISO country code (ISO 3166-1 alpha-3 country code)
Language	required	xml:lang Language Code
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? It's been suggested to use xmllang, but do we need to specify this in the data model? Probably, as we do want interchangeability between formats.

The IETF Location Object model and encoding (LO) is an internet standard and has also been vetted and approved by NENA for use in the NG 911 deployment in the US. The LO has both a civic (address) and a geodetic (coordinate) component.

Undetermined

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.

This section used to also include: "It is narrative text. It may be null.", not sure what this meant, so removed.

Relationship

The relationship geo-reference establishes 1-to-1 or 1-to-many relationships between POIs.

This section is getting some expansion from OGC

A relationship may be one of the following:

equals: The two objects have the same boundary and interior. The test for equivalence may be limited to the resolution of the coordinate system or the accuracy of the data.
disjoint: needs definition
intersects: needs definition
crosses: needs definition
overlaps: needs definition
within: A POI which is entirely contained within another POI, e.g. a POI describing a store may state that it is contained within a shopping mall
contains: A POI which entirely contains another POI, e.g. a POI describing a mall may state that it contains POIs for each store that is within the mall
touches: A POI which is physically adjacent to another POI, 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

Label primitive

POIs may have zero or more human readable labels. Labels SHOULD indicate what language the label is in. Multiple labels may be used to indicate synonyms, the first label encountered per language is considered the primary label for that language.

ID primitive

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.

Category Primitive

A POI MAY have one or more Category primitives. Category is adopted from Atom's category object, 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.

Contains

Name	Required	Details
term	required	a name or code describing the thing, e.g. bank
label	optional	a human-readable name describing the term
scheme	optional	the authoritative source for the term

Link Primitive

A POI MAY have one or more Link primitives. Link is adopted from Atom's link object, and works in the same way. 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. 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 elsewhere, 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.

Contains

Name	Required	Details
href	required	contains the link's URI
rel	optional	the link's relation type, by default "alternate". This value describes the meaning of the link. Implementations MUST consider the link relation type equivalent to the same name registered within the IANA Registry of Link Relations, and thus to the URI that would be obtained by appending the value of the rel attribute to the string "http://www.iana.org/assignments/relation/". See The Atom Syndication Format for more details.
type	optional	an advisory media type -- a hint about the MIME type of the representation
hreflang	optional	language of the resource pointed to by href
title	optional	human-readable information about the link
length	optional	a hint about the content length of the resource pointed to by href

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

Relation Name	Description
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

Metadata

Carl Reed Todo. We haven't decided how this would work, and why this wouldn't just be covered by our extensibility story. Please see: ISSUE-18.

Time primitive

POI MAY have one or more time primitives that represent an individual point in time, a span of time, or a recurring time or time span.

XML Syntax

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.

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
boolean	has the ·value space· required to support the mathematical concept of binary-valued logic: {true, false}
decimal	a subset of the real numbers, which can be represented by decimal numerals
float	patterned after the IEEE single-precision 32-bit floating point type [[IEEE 754-1985]].
double	patterned after the IEEE double-precision 64-bit floating point type [[IEEE 754-1985]].
duration	represents 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
time	represents 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)
gYearMonth	represents a specific gregorian month in a specific gregorian year.
gYear	represents a gregorian calendar year
gMonthDay	a gregorian date that recurs, specifically a day of the year such as the third of May
gDay	a gregorian day that recurs, specifically a day of the month such as the 5th of the month
gMonth	gregorian 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 identifie

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

`<pois>` element

The root element for an POI in XML syntax is the pois element. The <pois> element MUST contain one or more <poi> elements.

Attributes

Name	Required	Type	Default value	Details
xml:base	optional	URI? @@not anyURI as fragments are not allowed	URI of the document, or URI used to retrieve document or as defined by application context	specifies the base URI of these POIs, if different than the base URI of the document, see XML Base [[XMLBASE]] and RFC 3986 [[IRI]]
xml:lang	optional	language identifiers as defined by [[BCP47]]	??	specifies the language of the POIs, see XML Language Identification section [[XML11]]

should collections of POIs have an id?

`<poi>` element

The <poi> element encompasses all information about a single POI. The <poi> element MUST contain one or more <location> elements, and MAY contain one or more <label> and <category> elements.

Attributes

Name	Required	Type	Default value	Details
id	optional	@@ ID as defined in [[XML11]]	none	specifies an ID for a POI
xml:lang	optional	language identifiers as defined by [[BCP47]]	xml:lang value of the encapsulating <pois> element	specifies the language of this POI, see XML Language Identification section [[XML11]]

Is there an official geode tagging scheme, e.g. "wgs84", or "etrs89"? Apparently yes: http://portal.opengeospatial.org/files/?artifact_id=24045
Now tracked as issue: ISSUE-21.
How does this effect the altitude attribute?

`<location>` element

The <location> element contains one or more geo-references elements (see below), and has no attributes or character data.

Geo-reference elements

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.

`<point>` element

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

Attributes

Name	Required	Type	Default value	Details
crs	optional	anyURI	@@	A URI as defined in OGC @@ update to latest, Raj says they now use URIs instead of URNs [[OGC-07-092r1]]@@ of the geodetic system to which the latitude and longitude and altitude are relative
longitude	required	number	None
latitude	required	number	None
altitude	optional	number	?? sea level relative to system?

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

`<address>` element

Representing addresses is a tricky business, see Geolocation WG and IETF geopriv.
As such address will be moved to TBD in this draft. This issue is now tracked as ISSUE-40

Should there be a way to assign languages to addresses or parts of addresses?

`<navigation-point>` element

The <navigation-point> element has no character data and the same attributes as the <point>.

`<polygon>` element

The <polygon> element MUST contain three or more coordinates. The first and last coordinates must be the same.

I changed quite a bit here from what Raj and I discussed. I noticed Raj said the polygon is a gml:Polygon, but that isn't the same as a GeoRSS GML, which restricts it to one gml:exterior. Specifying all of the additional GML (gml:exterior, gml:LinearRing, gml:posList, seemed very verbose. I also added coordinate labels and defaults.

The contents of the <polygon> element are comma separated coordinates, the number of which is dependent upon the value of the coordinate-labels attribute. Each set of coordinates are whitespace separated.

The coordinate-labels contains a whitespace separated list of labels for each of the parts of the coordinates specified within the <polygon> element. The number of parts of a coordinate is equal to the number of coordinate-labels. If whitespace is encountered before all values have been specified, the result is determined by the values of the coordinate-defaults attribute, which contains a space separated list of defaults, one per coordinate-labels. If the number of coordinate-labels does not match the number of coordinate-defaults, the document is @@invalid. If a coordinate-labels attribute is specified, a coordinate-defaults attribute MUST be specified as well.

The contents of the <polygon> element should be equivalent to a gml:posList contained within a gml:LinearRing, within a gml:exterior within a gml:AbstractSurfaceType.

Attributes

Name	Required	Type	Default value	Details
crs	optional	URI	@@Whatever WGS-84 is in OGC URI syntax	?? see crs in point element for discussion
coordinate-labels	optional	NMTOKENS	"latitude longitude altitude"	see above
coordinate-defaults	optional	NMTOKENS	"0 0 0"	see above

`<object>` element

This geo-reference hasn't been written yet

Attributes

Name	Required	Type	Default value

`<undetermined>` element

The <undetermined> element has no character data and no attributes.

`<relative>` element

The <relative> element has no character data.

Attributes

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	decimal	None	?? radians? degrees?
relative-height	optional	integer	None

`<map>` element

Map georeference type has been dropped from the FPWD until it is better understood, so the map element has been dropped as well.

`<relationship>` element

The <relationship> element contains no character data.

Attributes

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>` element

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

id representation

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>` element

The <category> element is a child of the <poi> element. It is used to identify a category scheme and a category within that scheme, as well as one or more labels for the category.

The <category> element MUST contain one or more <label> elements, and zero or more <association> elements.

See ISSUE-24.
I adjusted the Atom category element, to support multiple human readable labels via label sub elements and I try to give some meaning to the term attribute when there is no scheme.

Attributes

Name	Required	Type	Default value	Details
scheme	optional	URI	None	URI that identifies the categorization scheme, does not need to be dereferencable
term	required	string	None	The name of the category, in the context of the scheme, or when scheme is missing, it is relevant only as an opaque string to identify the category.

Meta-data

TBD. See ISSUE-18.

`<time>` element

We discussed at F2F2 basing this on other standards' time representations.
This section now represents times as defined in XML Schema Datatypes.
This is ISSUE-26.

Attributes

Name	Required	Type	Default value	Details
scheme	optional	URI	None	URI that identifies the categorization scheme, does not need to be dereferencable
term	required	string	None	The name of the category, in the context of the scheme, or when scheme is missing, it is relevant only as an opaque string to identify the category.

XML Example

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 Schema

This is a very rough RELAX NG schema for the XML syntax. It is not guaranteed to work or be in sync with the rest of the document for now.

Introduction

Terminology

POI Data Model

POI

Contains

Coordinate Reference Systems

Location Primitive

Location Types

Point

Contains

Navigation Point

Contains

LineString

Contains

Polygon

Contains

Envelope

Contains

Address

Contains

Undetermined

Relationship

Label primitive

ID primitive

Category Primitive

Contains

Link Primitive

Contains

Metadata

Time primitive

XML Syntax

XML Notation

<pois> element

Attributes

<poi> element

Attributes

<location> element

Geo-reference elements

<point> element

Attributes

<address> element

<navigation-point> element

<polygon> element

Attributes

<object> element

Attributes

<undetermined> element

<relative> element

Attributes

<map> element

<relationship> element

Attributes

<label> element

id representation

<category> element

Attributes

Meta-data

<time> element

Attributes

XML Example

XML Schema

Use Cases

Acknowledgements

`<pois>` element

`<poi>` element

`<location>` element

`<point>` element

`<address>` element

`<navigation-point>` element

`<polygon>` element

`<object>` element

`<undetermined>` element

`<relative>` element

`<map>` element

`<relationship>` element

`<label>` element

`<category>` element

`<time>` element