CARVIEW |
Points of Interest Core
W3C Working Draft 12 May 2011
- This version:
- https://www.w3.org/TR/2011/WD-poi-core-20110512/
- Latest published version:
- https://www.w3.org/TR/poi-core/
- Previous version:
- none
- Editor:
- Matt Womer
Copyright © 2011 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Abstract
This document describes a data model and XML syntax for representing information about points of interest (POI) on the World Wide Web.Status of This Document
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This document was published by the Points of Interest Working Group as a First Public Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-poiwg@w3.org (subscribe, archives). All feedback is welcome.
As a First Public Working Draft, this document is intended to encourage discussion and should not be considered complete. Within the document there are Editor's notes formatted thusly:
This is an example of an Editor's Note
These notes reflect areas that need particular attention, an issue raised about in the POI tracker or may not have been written at all. Feedback on these areas is particularly appreciated.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Table of Contents
- 1. Introduction
- 2. Terminology
- 3. POI Data Model
- 4. XML Syntax
- A. Use Cases
- B. Acknowledgements
- C. References
1. 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 augmented reality browsers, location-based social networking games, geocaching, mapping, and navigation systems.
POI data has traditionally been exchanged in proprietary formats via various transports. This specification defines a flexible, lightweight, extensible POI data model, and one normative syntax for the data model. This will enable content publishers to effectively describe and efficiently serve and exchange POI data. In addition to the data model and format, this specification includes best practices for how to organize and serve POIs on the Web.
To achieve these goals, this document describes a generic data model and one normative format. This format is based on XML and is likely insufficient to cover all POI use cases, therefore, it is expected that the data model will be mapped to other formats, such as JSON, GML, RDF, GeoRSS, or HTML.
This section will be fleshed out in more detail for the next draft
2. 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 . 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 .
- Coordinate Reference System
- The term coordinate reference system refers to a coordinate system that is related to an object by a datum .
- Coordinate System
- The term coordinate system refers to a set of mathematical rules for specifying how coordinates are to be assigned to points .
- 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 .
- 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 .
- Position
- The term position refers to a data type that describes a point or geometry potentially occupied by an object or person .
- 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 .
3. POI Data Model
The following primitives can be combined to represent a POI.
This section will have a graphic representing the data model for next draft
3.1 Geo-reference
Geo-references are used a lot and were difficult to introduce just in the middle of the location primitive, so it got a promotion, even though it only appears in the location primitive.
A geo-reference is a reference to a location. A geo-reference can represent location in a variety of ways, such as the geospatial coordinates for the center of the POI, a civic address, an area (simple bounding box, or a polygon, or a 3d object), relative to a particular map or other geo-reference or undetermined. Geo-references are used in the location primitive.
A geo-reference is of one of the following types:
3.1.1 Center
The Center geo-reference locates the center point of the POI. This type is largely used for display purposes.
Contains
Name | Required | Details |
---|---|---|
Coordinates | required | |
System | optional | If not specified WGS 84 is assumed |
Longitude | required | |
Latitude | required | |
Altitude | optional | Defines the height in meters above or below sea level |
OGC has recommended the term geolocation instead of georeference:
Georeference – While geo-reference is a valid term, geo-reference typically indicates that a geometry or an image has coordinate reference system metadata. The suggested term is geolocation as this term is used extensively in other standards work, including the work of the W3C.
3.1.2 Navigation Point
A Navigation Point geo-reference is to a point that is the logical destination for routing. For example, this may be a reference to the entrance of parking lot POI.
Contains
Name | Required | Details |
---|---|---|
Coordinates | required |
3.1.3 Address
Note:Support for addresses in the XML syntax has been dropped for the FPWD, but reminds here in the data model.
An Address geo-reference 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.
3.1.4 Route
This section needs reworking. Within the XML syntax there's a notion of a list of points, as well as a point type that is reused. In the Wiki draft Routes and Areas both have point lists, we should extract the point list concept out so it can be shared.
Optional. Represents routes and traces.
Contains
- Point
- Required. Repeating for a directed linked list of points
- Type
- Required. One of : Start/End/way point
- Coordinates
- Required.
3.1.5 Area
An Area geo-reference represents a line-bounded area. The area is described by an ordered list of coordinates, where the first and last are the same.
I changed this one a bit, instead of introducing Points, I just made it have Coordinates, and mention that it is an ordered list of them where the first and last are the same. I figure the ordering can occur however such things happen in desired syntax (XML could be as they appear in document order or with an 'order' attribute, JSON may represent it as an array,etc)
Contains
Name | Required | Details |
---|---|---|
Coordinates | required | An ordered list of Coordinates, minimum of three, first and last must be the same. |
3.1.6 Object
The following paragraphs are adapted from Christine Perey's email. Parts of this are related to collections of POIs/objects and is thus also related to ISSUE-28. This section needs serious attention.
The Object primitive provides a rich and flexible description of an object, which decouples the description of an object from where it is located.
An Object may have one location at a (temporary-duration undefined) specific point in time but does not have one fixed point over time.
An Object of Interest can be a parent to other Objects each with its own description to allow for the representation of complex objects that are the aggregate of a collection of Objects (a car, boat, or airplane).
It should not be inferred that each of the elements within the object primitive are not spatially synonymous, but do refer to the same object.
Represents a 3D object, building, etc.
Contains
Name | Required | Details |
---|---|---|
TBD |
3.1.7 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.
3.1.8 Relative
I made relative a member of geo-reference rather than a sub-member of the map geo-reference, as it seems useful outside of the map scope
A Relative geo-reference is described in terms of distance from and bearing to another location.
Name | Required | Details |
---|---|---|
Relative-Location-Object | required | ID or location object (ID) this relative reference refers to |
Distance-From | required | |
Bearing-To | required | |
Relative height | optional |
3.1.9 Map
Map georeference type has been dropped from the FPWD until it is better understood.
3.2 Location
The location primitive provides a rich and flexible description of the location of a POI. A location is a required part of a POI.
3.2.1 Contains
Name | Required | Details |
---|---|---|
Identifier | required | A unique identifier for this location. |
Geo-reference | required | A reference to the actual location |
I didn't follow the definition of a location identifier, so details were removed
3.3 Relationship primitive
The relationship primitive establishes 1-to-1 or 1-to-many relationships between POIs.
A relationship may be one of the following:
- contained-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
- adjacent-to
- 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
- ...
Need more relationship types
Should the details of the various relationship types themselves be in this section? Assuming yes for now
3.3.1 contained-within
todo
3.3.2 contains
todo
3.3.3 adjacent-to
todo
3.4 string primitive
Dropped per our discussion at f2f
3.5 Label primitive
POIs may have zero or more label primitives which represent a human readable label.
At F2F2 we decided to rename the name primitive to "label", and to allow labels to be marked as primary for each language represented.
3.6 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.
3.7 Categorization primitive
POI may have a "categorization" primitive, with one or more category identifiers.
Todo
3.8 meta data primitive
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.
3.9 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.
4. 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.
4.1 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 | atterned 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
4.2 <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
The <pois>
element has TBD attributes.
We may not allow for collections of POIs, in which case there will be no pois element.
The pois element could have attributes such as xml:lang and an id, but is there a case for more? What's the right way to represent text-wise that lang and id's can be on all elements?
4.3 <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
see above note in the <pois>
element about lang and id
4.4 Representing coordinates
Many of the elements described below rely on a coordinates as attributes. In the interest of not repeating the definition, the following attributes are inferred whenever the coordinate attributes
are referenced below.
Attributes
Name | Required | Type | Default value | Details |
---|---|---|---|---|
srsname | optional | anyURI | urn:ogc:def:crs:EPSG:6.6:4326 | A URN as defined in OGC Definition identifier URNs in OGC namespace [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? |
Is there an official geode tagging scheme, e.g. "wgs84", or "etrs89"? Apparently yes: https://portal.opengeospatial.org/files/?artifact_id=24045
Now tracked as issue: ISSUE-21.
How does this effect the altitude attribute?
4.4.1 <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
The <point>
element uses the coordinate attributes
, and an order
attribute.
Name | Required | Type | Default value | Details |
---|---|---|---|---|
order | optional | unsigned-number | None | Applies only when a list of points is needed. Within the parent element containing the point list, there must be one <point> with the order attribute set to '0', other <point> element's order attribute must be unique and contiguous integers. Each point element within a point list must have the order attribute set. |
Do we want to use an order attribute? Document order? A single attribute with a list of comma separated coordinates?
Now tracked as: ISSUE-19: how should we represent points? and a related issue: ISSUE-36: do we want to rely on document order?.
4.5 <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.
4.5.1 <center>
element
The <center>
element has no character data, and only the coordinate attributes
.
4.5.2 <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?
4.5.3 <navigation-point>
element
The <navigation-point>
element has no character data and only the coordinate attributes
.
4.5.4 <area>
element
The <area>
element must contain three or more <point>
elements. The first and last points in an area point list must have the same latitude, longitude and altitude. The area element has no attributes.
4.5.5 <object>
element
This geo-reference hasn't been written yet
Attributes
Name | Required | Type | Default value |
---|---|---|---|
TBD |
4.5.6 <undetermined>
element
The <undetermined>
element has no character data and no attributes.
4.5.7 <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 |
4.5.8 <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.
4.6 <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 |
4.7 <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
4.8 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.
4.9 <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. |
4.10 Meta-data
TBD. See ISSUE-18.
4.11 <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. |
4.12 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 version="1.0" encoding="UTF-8"?> <pois> <poi id="StataCenter" xml:lang="en-US" > <label primary="true" xml:lang="en-US">Stata Center</label> <label primary="true" xml:lang="es">Stata Centro</label> <label>Ray and Maria Stata Center</label> <label>Building 32</label> <label>Gates Tower</label> <label>Dreyfoos Tower</label> <location id="location1"> <point latitude="42.360890561289295" longitude="-71.09139204025269"/> <point id="mainpoint" latitude="27.174799" longitude="78.042111" altitude="10m"/> <center latitude="27.174799" longitude="78.042111"/> <route> <point order="0" latitude="42.360890561289295" longitude="-71.09139204025269"/> <point order="1" latitude="42.361176" longitude="-71.09018"/> <point order="2" latitude="42.36272976137689" longitude="-71.09049081802368"/> <point order="3" latitude="42.36318955298668" longitude="-71.09677791595459"/> <point order="4" latitude="42.363617631805496" longitude="-71.10156297683716"/> </route> <area> <point order="0" latitude="42.360890561289295" longitude="-71.09139204025269"/> <point order="1" latitude="42.361176" longitude="-71.09018"/> <point order="2" latitude="42.36272976137689" longitude="-71.09049081802368"/> <point order="3" latitude="42.36318955298668" longitude="-71.09677791595459"/> <point order="4" latitude="42.363617631805496" longitude="-71.10156297683716"/> <point order="5" latitude="42.360890561289295" longitude="-71.09139204025269"/> </area> <undetermined/> <relative location-id="mainpoint" distance-from="10m" bearing-to="20" relative-height="10m"/> </location> <category scheme="https://www.census.gov/cgi-bin/sssd/naics/naicsrch?search=2007%20NAICS%20Search&code=611310"> <name xml:lang="en-US">Colleges, Universities, and Professional Schools</name> <association type="child-of" reference="https://www.census.gov/cgi-bin/sssd/naics/naicsrch?search=2007%20NAICS%20Search&code=6113"/> </category> </poi> <poi id="w3c"> <label primary="true">World Wide Web Consortium</label> <label>W3C</label> <label>W3</label> <location> </location> <relation type="contained-by" id="#StataCenter"/> <!-- category using a scheme --> <category scheme="https://www.census.gov/cgi-bin/sssd/naics/naicsrch?search=2007%20NAICS%20Search&code=813920" term="NAICS/611310"> <label xml:lang="en-US">Standards review committees, professional</label> <label xml:lang="es">Normas de los comités de revisión, profesional</label> <association type="child-of" reference="https://www.census.gov/cgi-bin/sssd/naics/naicsrch?search=2007%20NAICS%20Search&code=8139"/> </category> <!-- category, no scheme --> <category term="WebStandardsOrg"> <label xml:lang="en-US">Web Standards Organization</label> </category> </poi> </pois>
4.13 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.
start = element pois { poi* } poi = element poi { id?, lang?, label+, location, relation?, category*, association } center = element center { system?, latitude, longitude, } address = element address { attribute country { ISO-3166-ALPHA-3 }, attribute floor { text }, attribute language { MARC-ALPHA-3 }, attribute postalcode { text }, attribute street { text }, attribute suite { text }?, element region { text }+ } area = element area { point+ } # minimum of 3; first and last must be the same. object = element object { empty } # TBD undetermined = element undetermined { empty } relative = element relative { attribute location-id { xsd:NCName }, attribute bearing-to { BEARING }, attribute distance-from { DISTANCE }, attribute relative-height { HEIGHT_IN_METERS }? } label = element label { attribute primary { xsd:boolean }?, lang?, text } route = element route { point+ } location = element location { id?, (point | center | address | route | area | undetermined | map | relative)+ } association = element association { attribute reference { xsd:anyURI }, attribute type { xsd:NCName } } relation = element relation { id?, attribute relative-to { xsd:IDREF }, attribute type { "contained-within" | "adjacent-to" | "contains" } } category = element category { attribute source { xsd:anyURI }, label+ } point = element point { id?, attribute altitude { HEIGHT_IN_METERS }?, latitude, longitude, attribute order { xsd:nonNegativeInteger }? } # common types HEIGHT_IN_METERS = xsd:decimal DISTANCE = xsd:string { pattern = "[\+]?(\d+(\.\d{1,2})?)(m|km|mi|ft)?" } BEARING = xsd:decimal { minInclusive="0" maxExclusive="360" } ISO-3166-ALPHA-3 = xsd:string { pattern = "[A-Z][A-Z][A-Z]" } MARC-ALPHA-3 = xsd:string { pattern = "[A-Z][A-Z][A-Z]" } PERCENTAGE = xsd:integer { minInclusive="0" maxInclusive="100" } # common attributes id = attribute id { xsd:ID } lang = attribute xml:lang { xsd:language } latitude = attribute latitude { xsd:decimal { minInclusive="-90" maxInclusive="90" } } longitude = attribute longitude { xsd:decimal { minInclusive="-180" maxInclusive="180" } } system = attribute system { "WGS84" | text }
A. Use Cases
This section reflects the contents of the page on the POI wiki at the time of publication.
Please discuss any proposed edits on the public-poiwg mailing list before editing the wiki directly.
Use Cases
Please put here any and all use cases that are relevant to the WG discussions. In time we should pick a standard format for describing them but for now just upload the original files, preferably with an accompanying description.
Check in services
- TBD
AR Use Cases
Three Use Cases for AR Standards Discussion
This file captures contributions of the participants of International AR Standards Meeting conducted Oct 11-12 in Seoul. Added to this wiki page Oct 26, 2010
This file describes use case where all manner of historical content is related to relevant locations and viewed through a mobile AR browser. Added to this wiki page on Oct 28, 2010
Generic Points of Interest Use Cases
Search
- What is there to do here?
- Persona: End-User
- Elements: Geo-spatial proximity, POIs+Locations, Categories, Tags, Time, Events
- Where is a 4 star Italian restaurant near me that is still open?
- Persona: End-User
- Elements: Geo-spatial proximity, POIs+Locations, Categories, Tags, Time, Events
- Where can I find a new battery for my phone?
- Persona: End-User
- Elements: Geo-spatial proximity, POIs+Locations, Brand associations, inventory
- What movies are playing now near me?
- Persona: End-User
- Elements: Geo-spatial proximity, POIs+Locations, Categories, Time, Event
- Where is the cheapest available parking near the theater?
- Persona: End-User
- Elements: Geo-spatial proximity, POIs+Locations, Categories, Historical pricing info
- What shoes stores are in this mall?
- Persona: End-User
- Elements: Geo-spatial proximity, POIs+Locations, Categories, Local group associations
- How much is the entrance fee for the museum?
- Persona: End-User
- Elements: Geo-spatial proximity, POIs+Locations, Categories, Pricing info
Location-Based Advertising
- What special offers are around here?
- Persona: End-User
- Elements: Geo-spatial proximity, POIs+Locations, Location-based Advertising, Offer System
- What are the specials at nearby restaurants?
- Persona: End-User
- Elements: Geo-spatial proximity, POIs+Locations, Location-based Advertising, Offer System
- Let me know of any shoe sales I might pass as I walk around the city shopping.
- Persona: End-User, Interconnected systems
- Elements: Geo-spatial proximity, POIs+Locations, Location-based Advertising, Offer System
Destination Selection
- Take me to this café…
- Persona: End-User
- Elements: POI attribute search, location, route calc
- Take me to the place with this phone number…
- Persona: End-User
- Elements: POI attribute search, location, route calc
- Take me on a scenic wine tour
- Persona: End-User
- Elements: POI group associations, POIs, tags, route calc
- Take me to the office of my next appointment
- Persona: End-User
- Elements: Calendar, Contacts, locations, route calc
- If I want to go to Macy's in this mall at what entrance should I park?
- Persona: End-User
- Elements: POI group associations, location, location associations, route calc
B2B
- Associate together these similar business by categories and associations
- Persona: Interconnected systems
- Elements: POI group associations, POIs, categories, tags
- Convert these POI listings descriptions to 12 major languages
- Persona: Interconnected systems
- Elements: POIs, translation service
- Share this specific set of Yellow Pages with this business partner
- Persona: Interconnected systems
- Elements: POIs, source identification, tags, fullfillment services, distribution services
- Sweep these web sites and normalize the data to a standard exchange format
- Persona: Interconnected systems
- Elements: web scraping, standard format, language/tag processing service
- Accurately geolocate these places of business
- Persona: Interconnected systems
- Elements: locations, geocoding service, map
Informational
- What is the history of this building?
- Persona: End-User
- Elements: Geo-spatial proximity, Building cartography, POIs+Locations, Historical data
- What is the name of this neighborhood?
- Persona: End-User, Interconnected systems
- Elements: Geo-spatial proximity, area cartography, Named areas
- Tell me about this house…
- Persona: End-User, Interconnected systems
- Elements: Geo-spatial proximity, Building cartography, POIs+Locations, Real estate data
- What kind of businesses are in this building?
- Persona: End-User, Interconnected systems
- Elements: Geo-spatial proximity, Building cartography, POIs+Locations, Building to POI associations
- Take me on a tour...
- Persona: End-User
- Elements: Geo-spatial proximity, POI group associations, POIs, tags, route calc
- I want to leave a trail of my experiences for others to find and enjoy
- Persona: End-User
- Elements: Geo-spatial proximity, POIs+Locations, route calc, social data servcies
Augmented Reality
- Guide
- A system which leads the user through a process involving real world
- Create
- A system with which the user attaches/contributes a digital content “object” to or in the real world
- Play
- A system which supports bi-directional interaction between users and the real world
B. Acknowledgements
C. References
C.1 Normative references
No normative references.
C.2 Informative references
No informative references.