ISO/TC 211
N 2862
Replaces N 2752
2010-01-25
Number of pages: 27
ISO/TC 211
Geographic information/Geomatics
ISO reference number:
19154
Title:
Review summary of project 19154, Standardization
Requirements for Ubiquitous Public Access
Source:
ISO/TC 211/WG 10/PT 19154
Expected action:
For information
Type of document:
Review Summary
Hyperlink:
http://www.isotc211.org/protdoc/211n2862/
ISO/TC 211 Secretariat
Telephone: + 47 67 83 86 71
Telefax:
+ 47 67 83 86 01
Standards Norway
Strandveien 18
P.O. Box 242
NO-1326 Lysaker, Norway
E-mail:
[email protected]
URL:
http://www.isotc211.org/
Review Summary
For Project 19154
Standardization Requirements for
Ubiquitous Public Access
Jan. 13, 2010
Project Team 19154
© ISO 2010 – All rights reserved
1
1 Introduction
With the evolution of geographic information and recent progress of computing technologies, the
environments of geographic information are fundamentally being changed. In particular, the
incorporation of ubiquitous computing technology with geographic information has resulted in a
paradigm shift, making geographic data more publicly accessible and becoming an ever more
important part of our daily lives. For this reason, a working group (WG 10) has been established
within ISO TC211 as a resolution to the Xian Plenary Meeting in 2007, to address the needs of
geographic information environments for Ubiquitous Public Access (UPA).
Project 19154 was created at Copenhagen Meeting in 2008, to clarify the requirements of
standardization for UPA. The scope of this project covers
- survey on technical trends concerning UPA,
- definition of UPA and its scope, and
- requirements of UPA
The report of this project, which is given as a form of review summary, will provide the basis of
further activities of WG 10 within ISO/TC 211. This review summary report is organized as follows.
In clause 2, an investigation of the background of UPA is provided. This background information
will act as the input of the requirements analysis of UPA. In the clause 3, the concepts of UPA are
discussed and the definition of UPA is given. Clause 4 presents a list of requirements of
standardization for UPA. Clause 5 concludes with proposed actions and recommendations.
© ISO 2010 – All rights reserved
2
2 Background
In this clause the background of UPA is examined from two viewpoints:
- evolution of geographic information
- progress of ubiquitous computing technologies
While the first viewpoint is an issue about the internal aspect of geographic information, the second
issue is related with an external environment of computing technologies, which have greatly
influenced on environment of geographic information.
2.1
Evolution of geographic Information
The history of geographic information can be summarized into four generations as shown by Figure 1.
Figure 1 — Evolution of geographic information
Figure 1 shows several stages of the evolution of geographic information including the background of
the fourth generation of geographic information, which is called the UPA of geographic information.
a)
1st generation (paper maps): Geographic information was provided as paper maps during the first
generation. The major concerns of this generation were not only accurate information but also the
visualization of the data on paper maps. Here, geographic information was not limited to
professional users but also accessible to public users.
b) 2nd generation (digital maps): With the progress of computing technologies since the 1980s using
massive storage and database technologies, geographic information was stored and provided in
digital forms during the second generation. While paper maps were the publicly accessible media
of geographic information, the use of digital maps was limited to professional users during the
second generation. Due to the limited expressive power of databases (e.g. relational databases),
the accurate description of geographic features in the real world was one of the major issues of
research focus during the second generation.
© ISO 2010 – All rights reserved
3
c)
3rd generation (web and mobile geographic information): The important progress of computing
environments during the 1990s related to web and mobility technologies had a direct influence on
geographic information. The progress of computing technologies realized a dramatic expansion of
geographic information users. First, web technology provides an efficient infrastructure for the
public access of geographic information. Second, mobility technology services, such as LBS and
car navigation systems, contribute to the expansion of users as well, where the location awareness
is an essential functional requirement of these services.
d) 4th generation (ubiquitous geographic information): Following web and mobile computing
technologies, ubiquitous computing technologies became available from the 2000s with the
progress of smaller hardware, embedded systems, and diverse wireless communication. Like the
proceeding generations, these computing technologies resulted in a new generation of geographic
information, which can be summarized as public access and incorporation with ubiquitous
computing technologies. An important difference between the public access of the third and
fourth generations is that the public access in the fourth generation covers the entire life cycle of
geographic information while that of the third generation was limited to only public consumption.
There are three issues related to the transition between generations, particularly between the third and
fourth generations, that deserve additional examination:.
Objectives of geographic information: Firstly, the objectives of geographic information differ
from generation to generation. In the first generation of geographic information, the major
objectives were to present geographic information to public users via paper maps. However the
users of geographic information in the second generation became limited to professional groups
and the major concern was about how to correctly and accurately construct databases of
geographic features of the real world rather than the presentation of geographic information.
From the third generation, the presentation via web or mobile devices became fundamental
issues and one of the major objectives was to provide geographic information to public users,
which include not only professional groups but also the more naive users of the internet.
However web and mobile environments may be necessary conditions but not sufficient enough
ones for the public access of geographic information. In order to expand the users of geographic
information, the context of users should be considered rather than simply providing a general
form of geographic information to users. For example, the situation and specialty of each user
should be reflected to provide more easy, personalized, and consequently useful information to
user. This is a major objective of the fourth generation.
Participation of users: The second issue relates to the participation of users. Figure 2 depicts the
transition of geographic information from the second to fourth generation in terms of public
participation. While the participation from public users was very limited during the second
generation, there was an explosion of users of geographic information between the second and
third generations. Even though there were a large number of users in the third generation, their
participation was however limited to the consumption of geographic information. The fourth
generation is being extended to the entire cycle of geographic information including the
production, distribution, and consumption.
© ISO 2010 – All rights reserved
4
Figure 2 — Public participation of geographic information
Computing Technology: The third and final issue is related to computing technologies, as they
provide the computing environments of geographic information. As shown in Figure 1,
transitions between the two generations of geographic information were always motivated by
the progress of computing technology. For example, the invention of geographic information
systems in the 1950s and 1960s, and the second was in fact a sort of reflection of the progress
of computing technologies since the 1950s. Web and mobile technologies in the 1990s have
served as the basis of the third generation geographic information. In the 2000s, it is the
ubiquitous computing technology, which serves as the main driving force for the transition to
the fourth generation.
2.2
Progress of ubiquitous computing technologies
As mentioned in subclause 2.1, the rapid progress of computing technologies in the 2000s was a major
influence on the environment of geographic information. In this section, we investigate the
technologies, which influence geographic information and technical backgrounds for the UPA.
2.2.1 Mobility
Mobility is a key part of ubiquitous computing as described by Dr. Mark Weiser in [1]. Weiser
emphasized the nomadic property of ubiquitous computing, which is also referred to as nomadic
computing. Tiny hardware, embedded systems, and wireless communication all made considerable
progress during the 1990s and 2000s, giving users the opportunity to realize the mobility technologies
for ubiquitous computing. Yet mobility implies not only simple tiny portable devices but also locationawareness that provide the current location and detail of neighbouring objects. Location-awareness is
an essential functional requirement of ubiquitous computing in the interaction with neighbouring
objects or devices.
2.2.2 Context-Awareness
Context-awareness is defined as “Any information that can be used to characterize the situation of
entities” [2], and context-awareness is referred to as “the use of context to provide task-relevant
information and/or services to a user” [3].
© ISO 2010 – All rights reserved
5
Ubiquitous computing differs from past computing technologies in that context-awareness is an
essential requirement of ubiquitous computing. Through context-awareness, each user is provided with
proper geographic information depending on her/his situation. It means that services in ubiquitous
computing environment are offered to each user depending on the context. For example, different
types of information on highway conditions are provided to drivers depending on the level of fuel of
the car. When the fuel level is almost empty, the information about nearby gas stations should be
provided with the highest priority. And if a driver took lunch one hour ago, then location information
about restaurants is not useful at the current time.
Context-awareness for geographic information can be classified into three categories;
- location-awareness: the location of user (or device),
- spatial awareness: the location of user and neighbours (including mobile objects), and
- geographic awareness: the location of user and neighbours and neighbours geographic attributes.
Contextual information is gathered from several sources. First, it is collected from sensors. In
particular, dynamic context is collected from sensors. Second, behavioural context information of an
individual user can be archived to a profile or log file. For example, the URL addresses that a user is
visiting can be archived for contextual data. The third source of context information is from other
systems. Traffic information, for example, in a given area can be downloaded from a traffic
information server.
2.2.3 Geo-Sensors
Geo-sensors are an important source of contextual data and provide dynamic context to systems. In
general, geo-sensors can be classified into the following categories;
- Positioning Sensors (e.g. GPS),
- Environmental Context Sensors (e.g. Camera Sensors, Temperature Sensors), and
- ID Sensors (e.g. RFID readers, 2D Bar Code)
A geo-sensor provides the position and time information when and where the data are captured by the
sensor. These sensors are usually equipped with wireless communication functions so that they can
communicate with neighbouring sensors and form a sensor network. We can gather sensor data not
only from an individual sensor but also aggregated values from groups of sensors connected by
wireless communication.
Data from geo-sensors should be processed in real-time, since it is required to promptly react to the
change of context from sensors for many applications. We call such systems data stream management
systems (DSMS) to distinguish them from database management systems (DBMS). The main
functions of DSMS are to process the data stream from sensors in real-time rather than store them into
databases for later analysis and queries.
2.2.4 Massively distributed computing
Compared with the previous distributed computing technologies such as client-server or middleware
architecture, ubiquitous computing provides a massively distributed architecture. For example, a
distributed system is composed of a set of nodes that could be tiny devices like smart dust or motes
[26] of a wireless sensor network. A massively distributed system could also be a serverless
architecture to overcome scalability problems. Typical examples of massively distributed architectures
© ISO 2010 – All rights reserved
6
include peer-to-peer environments, ad-hoc networks (or mobile ad-hoc network), and broadcasting
networks, which are being used by TPEG [4].
2.2.5 Invisible user interface
An interesting aspect of ubiquitous computing technologies is found in the relationship between
machines (or devices) and humans. In the past generations of computing technology, it was 1:n or 1:1.
Which means that a single server is concurrently used by several users (1:n) or a user is served by a
single PC (1:1). However in a ubiquitous computing environment, a single user is served by several
machines or devices around them. First, the user-interface between a device and user is designed
differently in a ubiquitous computing environment, since more than one device is serving a user at the
same time. Second, several devices therefore communicate with each other via wireless
communication, for example, instead of interacting directly with user. Devices tend to be pervasive
and invisible in ubiquitous computing environments.
2.3
Background: Summary
UPA has two important background concepts; the evolution of geographic information as the internal
background and the progress of ubiquitous computing technologies as the external background. Even
though we have investigated these two backgrounds separately, they are related with each other. The
progress of ubiquitous computing technologies serves as a driving force toward UPA as shown in
Figure 3, and UPA is also an important component of ubiquitous computing technology.
Figure 3 — The two backgrounds of UPA
© ISO 2010 – All rights reserved
7
3 Concepts of UPA
In this section, the concepts of UPA based on the survey of clause 2 are introduced. The term
“Ubiquitous Public Access“, consists of the combination of two concepts; ubiquity, and public access.
In order to define the ubiquitous public access, we first investigate these three concepts related to
UPA;
- ubiquity,
- public access,
- the combination of ubiquity and public access
3.1
Ubiquity
Ubiquity (or Omnipresence) is the property of being present everywhere [5]. Ubiquitous geographic
information is defined as geographic information to be supplied in every place at any time for any
device by the report of UBGI ad-hoc group [6]. In this report, the definition of the ubiquity of
geographic information is given as an environment (or infrastructure) to provide geographic
information in every place at any time for any device. In other words, the ubiquity of geographic
information is an infrastructure to realize the ubiquitous geographic information, and ubiquitous
computing is the only technology to achieve this ubiquity.
3.2
Public Access
Public access has several meanings. It may be interpreted as easy access or open access. But the
concept of public access for UPA that we are dealing with in this report comes from public access TV,
which is a form of citizen media created by private non-profit citizens or organizations. One or two
local cable TV channels are reserved to broadcast services for content neutral, first-come first-served,
and free speech policies. It means that the public can make cable TV programs by themselves.
Like public access TV, public access geographic information are also forms of geographic
information services created by public users or organizations. An important aspect of public access
geographic information is that public users are no longer passive consumers of geographic information
but actively participate in the entire life cycle of geographic information from the production,
distribution and sharing of geographic information to the consumption. This can be expressed by a
phrase, “The geographic information of the people, by the people, and for the people”.
A good example of public access geographic information is found at Wikimapia [8], which is a service
operating on similar lines to Wikipedia and allowing public users to provide descriptions of place of
interest to them. OpenStreetMap [9] provides similar services, which is a project that is building a
public-domain street map of the entire world through volunteer effort [7,10]. In this environment,
public users can participate in any phase of the life cycle of geographic information. Furthermore, it
provides a set of open APIs so that any public user can develop their own mash-up services with for
example, OpenStreetMap data.
3.3
Ubiquity and Public Access
As mentioned earlier, the term “Ubiquitous Public Access” is the combination of these two concepts,
ubiquity and public access, which is depicted by Figure 4.
© ISO 2010 – All rights reserved
8
Figure 4 — Cooking and UPA
In Figure 4, UPA is shown as the analogy of cooking a kind of food, where the final outcome of this
cooking is the services of public access geographic information. Cooking is composed of three
components, which are the materials of cooking – the ingredients, the procedures of cooking – the
recipe, and tools for cooking – the cooking utensils. The materials, procedures, and tools of cooking
for public access geographic information refer to the data sources, the procedures for production of
geographic information, and the environments that support the public access geographic information,
respectively. The environments for public access geographic information can be implemented by
means of ubiquitous computing technologies.
As it is possible to prepare food without good cooking tools, public access geographic information
without good environments could also be provided. However, in order to provide better public access
geographic information with good environments, better food may be prepared with good better
cooking tools. In order to prepare tasty food, cooking methods are important, since the food will most
likely not taste food without good and correct recipe. Most recipes give precise instructions on the
cooking tools as well. In practice, it is much preferred to provide the services of public access
geographic information with good computing environments, which are in fact, ubiquitous computing
environments. This means that public participation for geographic information from public production
and sharing to public consumption is better supported on the robust basis of ubiquitous computing
environments as described in Figure 4. With limited environments of ubiquitous computing, limited
services for public access geographic information would, in turn, also be limited. From this reason, the
ubiquitous computing and public access geographic information are strongly related and ubiquitous
computing environments are practically the only way to achieve the public access of geographic
information. It is this essential relationship between the ubiquity and public access, that yields the
following definition of ubiquitous public access;
“A form of geographic information services produced and consumed by public users in any place
at any time for any device.”
© ISO 2010 – All rights reserved
9
4 Requirements of UPA
In this clause, a survey of the scope and requirements of standardization for UPA based on the
concepts examined in the previous clauses is presented.
4.1
Scope
The scope of standardization activities for UPA is depicted by Figure 5.
Figure 5 — Scope of standardizations for UPA
As shown by Figure 5, the scope of UPA standardizations is divided into three categories of standards;
services for public access, management of geographic information for UPA, and incorporation of
ubiquitous computing to UPA.
Standards to allow public accesses to users: The first category of standards for UPA includes the
standards for the services of UPA offered to public users. Even though a number of standards of
TC 211 belong to this category, they are focused on the consumption of geographic information.
UPA services standards not only for public consumption but also public production of
geographic information are needed. For example, standards for open APIs, which are being
provided by several commercial geo-portals and free map services for enhanced public
participation for geographic information services, such as Google Map and Yahoo Map are
needed.
Standards to manage geographic information for public accesses: The standards of the second
category are intended to manage geographic information for UPA. The standards for the
production and management of geographic information belong to this category. Since the
geographic information produced by public users may have problems of accuracy and
consistency, more rigorous specifications and standards for data quality and metadata are
required. Also, in order to integrate multiple sources of geographic information, standards for
global identifiers are needed.
Standards to incorporate ubiquitous technologies into public accesses: The third category of
standards for UPA is to incorporate ubiquitous computing technologies to UPA. First of all, the
© ISO 2010 – All rights reserved
10
context-awareness is an essential function not only of ubiquitous computing but also public
access of geographic information. The spatial awareness, which is a kind of context-awareness,
is particularly important for UPA. Note that the spatial awareness is no longer limited to the
service that UPA provides to users with user-interfaces. Spatial awareness is also useful
functions to any type of devices of pervasive computing. For example, spatial awareness could
be embedded into an air conditioner or an electric lamp without any functions of user-interface.
The massively distributed architecture of ubiquitous computing and its middleware are also
important issues to be considered for the standardization in for UPA.
For reasons of convenience, the scopes of standards are summarized in Figure 6 by the reference
model of geographic information standardization proposed by ISO 19101.
Figure 6 — Requirements for UPA standardizations
4.2
UPA Reference Model
The most basic standard for UPA is the reference model, which provides the framework of the
standardization activities under WG 10, and lists possible standardization items.
4.3
Profiles for UPA
Since most issues related with profiles of geographic information are covered by the ISO 19106
standard, the additional rules and guidelines for UPA are not necessary. However an example of
profile for UPA as an additional normative annex of ISO 19106 can be helpful to apply the profiling
rules and guidelines to UPA.
© ISO 2010 – All rights reserved
11
4.4
Data Models for UPA
In ISO 19107 [12], ISO 19108, and ISO 19109, most of the basic models and schemas for geographic
information are defined. However, additional data models are necessary to reflect the specific
requirements of UPA, which are summarized as follows;
- data models for stream data from sensor data,
- data models for multiple levels of detail, and
- data models to support context-awareness, particularly geographic context-awareness.
4.5
Data Quality and Metadata for UPA
The current standards of TC 211 are commonly defined on the assumption that only professional
organizations, such as national mapping agencies construct geographic information and the possibility
that the public users could participate to the production of geographic information is neglected. Thus,
certain standards should be revised or new standards should be introduced in order to allow public
users to participate in the production of geographic information.
As highlighted in clause 4.1, the geographic information for UPA is constructed from several sources
of data. Thus, the quality control of geographic information for UPA may be different from the current
standards and additional specifications are required. Although the standards for data quality (ISO
19113 and ISO 19114) specify the basic rules and procedures for quality control, more specific
standards should be defined to maintain the quality of data for UPA. For this reason, these standards
(ISO 19113 and ISO 19114) may be reviewed and additional requirements may be appended as
annexes. For example, the quality description of geographic information defined in ISO 19113 may
not be adequate for data produced by public participation. For the same reason, it may be impossible
to apply the quality evaluation procedure to the geographic information produced by public
participation. The standard for metadata (ISO 19115) may also be reviewed and revised to reflect the
requirements of UPA.
4.6
Global Identifier
In order to integrate multiple sources of geographic information and to provide interoperability, the
concept of a global identifier is a crucial requirement. An identifier for UPA can be classified into two
types, feature identifier and location identifier. The location identifier can be defined as an application
schema of geographic identifier (ISO 19112), and two projects are currently in progress within TC
211to provide standards for location identifiers of different purposes. However no standards exist in
TC 211 for feature identifiers. Outside of TC 211 some related standards exist for similar purposes by
other standardization organizations, such as IETF and EPCGlobal. A standard for geographic feature
identifier may be provided in TC 211 through collaboration with these other organizations.
4.7
Incorporation of ubiquitous computing environments
Since ubiquitous computing environments provide different computing infrastructures, different
interfaces and architectures are required to incorporate them into UPA. For example, broadcasting is a
useful communication environment to overcome the scalability problem of UPA, however it differs
from the conventional communication media, such as TCP/IP. While broadcasting is used for the
transmission of geographic information, different type of interfaces and data models may be required
to incorporate broadcasting transmission into UPA. For a similar reason, we may need different
© ISO 2010 – All rights reserved
12
techniques to interface with sensors, which provide streams of geographic data and context in realtime, as mentioned in clause 2.2.3.
4.8
Context awareness for geographic information
As discussed in clause 2.2.2, context-awareness is an essential concept of ubiquitous computing and
different representations of geographic information are required to integrate it to UPA. Geographic
information encoded in GML, for example, cannot efficiently support context-awareness. Additional
features are required to represent contexts and to support different interpretations depending on the
context. They may be described by extensions of GML or simple markup languages such as
microformats [25]. As shown by Figure 7, the same geographic information should be displayed in
different ways depending on the context, which in this case, is the size of display screen.
Figure 7 — Different representations of geographic information upon different contexts
As shown in clause 2.2.5, the functions of ubiquitous computing tend to pervade our surroundings,
instead of being provided in the form of a user-interface. This “pervasive” property of ubiquitous
computing means that the functions of UPA may be embedded into several devices of our daily life,
such as electric lamps, watches, cars, etc. The interfaces and functional specifications of the embedded
functions of UPA are areas, which can be standardized.
4.9
Public consumption
Future standards for UPA must include support for the public consumption of geographic information.
Compared with the conventional public consumption of geographic information, UPA standards for
public consumption should include not only the interfaces such as web feature services (Project
19142), but also more user-oriented supports for ease of use. A promising approach to provide more
user-oriented services of UPA is through the context-awareness examined in clause 4.7. Figure 8
shows an example of this approach using GML with context tags.
In this example, context-sensitive geographic information is encoded in GML with context tags. This
GML document can be interpreted to user-centric geographic information by the function of contextawareness with individual contextual parameters, such as salary, age, and specialty as well as the
context information from sensors such as the speed of car and engine temperature.
© ISO 2010 – All rights reserved
13
Figure 8 — Different representations of geographic information upon different contexts
4.10
Public production
When public users participate in the production of geographic information, guidelines on the
procedures of public production and the specifications of the interfaces will be useful to ensure a basic
level quality for the geographic information. The revised or extended standards that are related with
the data quality, quality evaluation procedures and metadata discussed in clause 4.5, will be an
important foundation to the definition of standards for the guideline and interface specifications.
One example of a service produced by the public is a mash-up. Therefore the standards of open APIs
used in mash-up services are required for the public production of UPA, in addition to the guidelines
and specifications of interfaces for public production. These standards will contribute to the
enhancement of the interoperability of mash-up services.
4.11
Privacy Issue
With ever increasing access to location data related to an individual, we expect that the access to
personal data will be easier and that access and control (authorization) of individual location
information will be more difficult than conventional geographic information services. This privacy
issue needs to be carefully examined and handled before providing UPA services.
Both the Open Mobile Alliance (OMA) and the Internet Engineering Task Force (IETF) have done
considerable work in terms of location and privacy, especially as related to the mobile/location
services world. In 2007, OMA approved and released an excellent reference that provides numerous
use cases document titled, “Privacy Requirements for Mobile Services Approved Version 1.0.1 – 07
Aug 2007”. From this document:
This document defines general privacy requirements within the OMA framework. In an IT
context, personal privacy is about content filtering and other mechanisms to ensure that end
users are not exposed to whatever violates their moral senses, while territorial privacy is
about protecting the user’s property - e.g. the user equipment - from being invaded by
undesired content, such as SMS or email messages. Informational privacy is about data
protection, and the user right to determine how, when and to what extent information about
her is communicated to other parties, and the execution of this right might be based on her
knowledge about what the other party’s intention is.
Also in 2007, the Internet community approved a new internet standard [RFC 4745] titled, “Common
Policy: A Document Format for Expressing Privacy Preferences”. This document defines a framework
for authorization policies controlling access to application-specific data. This framework combines
common location- and presence-specific authorization aspects. An XML schema specifies the
© ISO 2010 – All rights reserved
14
language in which common policy rules are represented. The common policy framework can be
extended to other application domains.
Future Work: These two documents may provide the necessary guidance and technology approach to
insure that individual privacy is properly protected in the ubiquitous information environment. These
need to be evaluated within the context of the GeoRM (Rights Management) activity in TC 211.
Privacy and location have not been addressed from an abstract model perspective in either the OGC or
in TC 211. Work needs to be done.
© ISO 2010 – All rights reserved
15
5 Summary of Related Standards with UPA
The requirements for UPA standards are not only limited to ISO/TC211 but also related to other
standards and standardization efforts. The harmonization with other related standards should be
considered for the standardization of UPA. Table 1 provides a summary of related standards having a
direct link to UPA. This list is not exhaustive but provides most used and implemented standards
within mass market geomatics and consumers communities.
Table 1 – Related Standards with UPA
Standard
Standard description
Origin
Keyhole Mark-up
Language (KML)
OGC KML version
2.2.0
Keyhole Markup Language (KML) is an XML-based language schema for
expressing geographic annotation and visualization on existing or future Webbased, two-dimensional maps and three-dimensional Earth browsers. KML uses a
tag-based structure with nested elements and attributes and is based on the XML
standard. All tags are case-sensitive and must be appear exactly as they are listed
in the KML Reference. The Reference indicates which tags are optional. Within a
given element, tags must appear in the order shown in the Reference.
Open
Geospatial
Consortium Inc.
georss
OGC georss GML
application schema
georss W3C
GeoRSS is an emerging standard for encoding location as part of an Web feed.
(Web feeds are used to describe feeds ("channels") of content, such as news
articles, Audio blogs, video blogs and text blog entries. These web feeds are
rendered by programs such as aggregators and web browsers.) The name
"GeoRSS" is derived from RSS, the most known Web feed and syndication
format.
OGC (georss GML
application schema)
W3C (georss W3C)
In GeoRSS, location content consists of geographical points, lines, and polygons
of interest and related feature descriptions. GeoRSS feeds are designed to be
consumed by geographic software such as map generators. By building these
encodings on a common information model, the GeoRSS collaboration is
promoting interoperability and "upwards-compatibility" across encodings.
At this point, the GeoRSS collaboration has completed work on two primary
encodings that are called GeoRSS Geography Markup Language (GML) and
GeoRSS Simple. GeoRSS GML is a formal Open Geospatial Consortium (OGC)
GML Application Profile, and supports a greater range of features than GeoRSS
Simple, notably coordinate reference systems other than WGS84
latitude/longitude. There is also a W3C GeoRSS serialization, which is older and
partly deprecated but still the most widely used.
GeoRSS can be used to extend both RSS 1.0 and 2.0, as well as Atom, the IETF's
latest standard for feeds.
U-position
WD ISO 19151
A protocol over http to encode logical geographic position. The standard specifies
u-position naming schema and interfaces for operations to handle u-positions.
ISO/TC
211
–
geographic
information
and
Geomatics
Place identifier
architecture
WD 19155
A protocol over http to encode geographic location regardless of the Location
Based Content. The PI concept includes the Location Based Contents (LBC) that
consists of “Place” and “Content”. The standard support community uses SRS
(address, CRS, telephone number, postal code, landmark, personal representation,
etc.). The standard describes five components:
PI architecture – PI reference model
PI application – PI platform interface
PI representation
PI platform – PI platform interface
PI encoding
ISO/TC
211
–
geographic
information
and
Geomatics
© ISO 2010 – All rights reserved
16
Standard
Standard description
Origin
Access Control
and Term of Use
Demonstrates a number of functional capabilities related to rights management
(Terms-of-Use, Authentication, content services) that need to be described and
chained.
OGC Inc.
The Sensor Event Service (SES) provides operations to register sensors at the
service application and let clients subscribe for observations available at the
service. The service performs filtering of sensor data (streams) based upon the
filter criteria defined in these subscriptions. Filters can be applied on single
observations but also on observation streams, potentially aggregating observations
into higher-level information (which itself can be regarded as observation data).
Whenever matches are discovered, a notification is sent to the subscriber, using
asynchronous, push-based communication mechanisms.
OGC Inc.
Encoding Standard for the representation, storage and exchange of virtual 3D city
and landscape models. CityGML is implemented as an application schema of the
Geography Markup Language version 3.1.1 (GML3).
CityGML models both complex and georeferenced 3D vector data along with the
semantics associated with the data. In contrast to other 3D vector formats,
CityGML is based on a rich, general purpose information model in addition to
geometry and appearance information. For specific domain areas, CityGML also
provides an extension mechanism to enrich the data with identifiable features
under preservation of semantic interoperability.
OGC Inc.
This specification is limited to providing a scripting API for retrieving geographic
position information associated with a hosting device. The geographic position
information is provided in terms of World Geodetic System coordinates
[WGS84].
The scope of this specification does not include providing any kind of markup
language nor any definition of URI schemes for building URIs that identify
geographic locations.
Transfer Nodes includes bus stops, train stations, subway stations, ferry terminals
and airports. The nodes denote sites in transports networks where one can change
modes or means of transportation. These nodes are of vital importance to make
multi and inter modal travel planner's work. Thus they are of vital importance to
ITS (Intelligent Transportation Systems).
W3C
- Sensor Planning Service (SPS) - Standard web service interface for requesting
user-driven acquisitions and observations.
- Sensor Alert Service (SAS) - Standard web service interface for publishing and
subscribing to alerts from sensors.
- Web Notification Services (WNS) - Standard web service interface for
asynchronous delivery of messages or alerts from SAS and SPS web services and
other elements of service workflows.
OGC Inc.
The purpose of the OpenSearch-Geo extensions is to provide a standard
mechanism to query a resource based on geographic extents, or location name.
The geospatial results are based on the GeoRSS standards. Therefore,
latitude/longitude order, bounding box parameters, and polygon are all using that
standard.
OpenSearch.org
The Robotic Localization Service (RLS) standard defines specifications for
representing and manipulating advanced location measurement results and related
information both in static and dynamic manner. In order to achieve high precision
or accuracy, modern location data estimation techniques require auxiliary
information such as measurement time or error estimation. Aggregation of
multiple measurement sources is often required for attaining high precision. And
target ID information is required when multiple targets can be measured at once.
Also, supports for mobile entities such as navigation robots are required. RLS
defines a framework for handling these information that are essential for advanced
positioning by extending the existing spatial coordinate standards. Although the
specification is named as 'robotic', this specification can be applied to other fields
that require advanced location estimation, such as ubiquitous sensor networks or
next-generation geographic information systems.
Object Management
Group (OMG)
OGC discussion
Paper
Sensor Event Service
specification
interface
OGC discussion
Paper
City Geography
Mark-up Language
(CityGML)
OGC standard 1.0.0
Geolocation
specification
API
W3C Draft
Specification
Geographic
information and
Geomatics –
transfer Nodes
WD 19147
Sensor Web
Enablement (SWE)
OGC standards
Open Search geo
extension
Draft document
Robotic Localization
Service (RLS)
ISO/TC
211
–
geographic
information
and
Geomatics
In addition to the standards described in Table 1, there is a need to revisit a number of ISO/TC 211
standards e.g. metadata, data quality, Web Map Service interface specification, and others to support
and address requirements for ubiquitous public access. A revision to ISO 19101 geographic
© ISO 2010 – All rights reserved
17
information reference model and the development of a new project related to a framework of UPA are
both required to determine detailed aspects of ISO/TC 211’s existing suite of standards to be revised in
conjunction with those standards provided by other organizations such as the Open Geospatial
Consortium Inc. and W3C.
© ISO 2010 – All rights reserved
18
6 Conclusion and Recommendations
With the recent progress of ubiquitous computing technologies during the present decade and the
evolution of geographic information, the paradigm of geographic information is shifting towards
ubiquitous public access. Working Group 10 was established in 2007 within TC 211, and this project
was launched to clarify the standardization requirements of ubiquitous public access. This project
reviewed the following issues;
- Background of UPA,
- Concepts and Definition of UPA, and
- Standardization Requirements for UPA
As the result, this report is herewith submitted as a review summary on the requirements of
standardization for UPA. Based on the results of this survey on the requirements of standardization for
UPA, the project team recommends the following actions be considered:
-
first, as a subsequent task of this project, a reference model for UPA should be part of the
revision of ISO 19101 (reference model). A framework for UPA may be developed in
Working Group 10.
-
second, as we have studied at Annex A for a use case of UPA, gaps are found between UPA
and the exiting ISO TC 211 standards. In order to reduce these gaps, the requirements
summarized in clause 4 should be reflected through the revision of existing ISO TC 211
standards and new standardization projects need to be initiated within WG 10.
-
third, a set of extensive liaison relationships should be established with other standardization
organizations whose activities are closely related with ubiquitous computing technologies.
© ISO 2010 – All rights reserved
19
Bibliography
[1]
Mark Weiser, Nomadic Issues in Ubiquitous Computing
http://www.ubiq.com/hypertext/weiser/NomadicInteractive/
[2]
Anind K. Dey, Understanding and Using Context, Journal of Personal Ubiquitous Computing
5(1), pages 4-7. 2001
[3]
Gregory D. Adowd and Anind K. Dey, Towards a Better Understanding a Context and
Context-Awareness, Lecture Notes in Computer Science Vol.1707, pages 204-307, 1999
[4]
Official website of TPEG, http://www.tpeg.org
[5]
Stanford Encyclopedia of Phylosophy, http://plato.stanford.edu/entries/omnipresence/
[6]
UBGI Ad-Hoc Group of TC 211, Report from Ad Hoc Group for Ubiquitous Geographic
Information, N2298, 2007
[7]
Michael F. Goodchild, Citizens as sensors: the world of volunteered geography, GeoJournal
69(4), pages 211-221, 2007
[8]
Official website of wikimapia, www.wikimapia.org
[9]
Official website of OpenStreetMap, www.openstreetmap.org
[10]
Michael F. Goodchild, Citizens as sensors: web 2.0 and the volunteering of geographic
information, GeoFocus No. 7, pages 8-10, 2007
[11]
ISO 19101:2005, Geographic Information – Reference model
[12]
ISO 19106:2004, Geographic Information – Profiles
[13]
ISO 19107:2003, Geographic Information – Spatial schema
[14]
ISO 19108:2008/Cor1:2006, Geographic Information – Temporal schema
[15]
ISO 19109:2005, Geographic Information – Rules for application schema
[16]
ISO 19112:2003, Geographic Information – Spatial referencing by geographic identifiers
[17]
ISO 19113:2002, Geographic Information – Quality principles
[18]
ISO 19114:2003/Cor1:2005, Geographic Information – Quality evaluation procedures
[19]
ISO 19115:2003/Cor1:2006, Geographic Information – Metadata
[20]
ISO 19128:2005, Geographic Information – Web map server interfaces
[21]
ISO 19136:2007, Geographic Information –Geographic Markup Language
[22]
ISO /DIS 19142, Geographic Information – Web feature service
© ISO 2010 – All rights reserved
20
[23]
ISO/TC211 N2225, Dynamic position identification scheme for ubiquitous space (u-position)
[24]
ISO/TC211 N2493, Geographic Information – Place Identifier (PI) Architecture
[25]
Official website of Microformats, http://microformat.org
[26]
J.M. Kahn, R.H. Katz and K.S.J. Pister, Mobile Networking for Smart Dust, Proc. ACM/IEEE
International Conf. on Mobile Computing and Networking (MobiCom 99), pages 271-278,
1999
© ISO 2010 – All rights reserved
21
Annex A
A Use-Case of Ubiquitous Public Access - OpenStreetMap
A.1 Introduction:
OpenStreetMap (OSM) is a project launched in 2004 to provide an environment for making maps by
public users other than national mapping agencies or companies. It is considered to be included in the
scope of UPA (Ubiquitous Public Access). In this annex, OpenStreetMap is examined for
understanding the environment of UPA with a use-case that includes the whole lifecycle of geographic
information services from data collection and map production step to application developments.
For this purpose, Annex A is organized as follows. In A.2, the basic concepts and ideas of OSM are
introduced. In A.3 the map production process in the OSM environment is examined. The
management and sharing of OSM data is discussed in A.4. Several applications using OSM will be
given in section 5. Finally in A.6 OSM is examined from a standardization viewpoint.
A.2 OpenStreetMap
With the progress of positioning technologies such as GPS in last decades, the collection of position
data and map production do no longer belong to professional areas. Public users may gather their
position data in reasonable accuracy with ease and share their geographic data via open an web
environment.
[Figure A.1. Growth of OpenStreetMap – source http://wiki.openstreetmap.org ]
OpenStreetMap project founded in July 2004 by Steve Coast of the UK is an example of a mapping
project based on a open source approach. OSM is currently transforming itself into an international
non-profit organization dedicated to encouraging the growth, development and distribution of free
geographic data and to providing geospatial data for anybody to use and share [1]. It means that
© ISO 2010 – All rights reserved
22
geographic data is produced not only by national mapping agencies and companies but also by public
users and shared by any public users in the OSM environment. The user group of OSM is increasing
very rapidly as shown by Figure A.1 and is expected that it will become an important data source of
geographic information in a near future.
A.3 Construction of geographic information in OSM environment
A major characteristic of OSM is the public production of geographic information and it is the reason
that OSM is considered as a crowd-sourcing [4] type of project. The construction process of
geographic information in OSM environment, which is composed of five steps, is illustrated in Figure
A.2 [5], and is very similar with the peer construction concept of creating entries in Wikipedia.
[Figure A.2 - 5 steps to add to OpenStreetMap]
Step 1 (Collecting data) – The most common way of gathering data for OSM is by using GPS.
However it is possible to create maps from other data sources, for example Yahoo! Imagery, Landsat
and NPE(New Popular Edition) maps [8] are available to the OSM project for data extraction.
Step 2 (Uploading data) – JOSM (Java OpenStreetMap) Editor is a user environment for making
maps for the OSM project, with the data having been uploaded from GPS.
Step 3 (Creating/Editing maps) – From the points uploaded from GPS, users can create or edit the
following geometric elements;
- Nodes: used to mark specific locations (such as a post box) or for drawing segments between two
locations,.
- Ways: An ordered list of nodes, displayed as connected by line segments. They are used to
describe roads, paths, etc.
- Closed Ways: Closed ways are ways which are a complete closed loop. They are used to describe
areas like parks, lakes or islands.
Step 4 (Adding details, and tagging) – Once a geometric element is completed, tags are inserted to
enable the features to be rendered on the map. Tags are key-value pairs. There are many tags, some far
more common than others. When using JOSM, tagging is accomplished by adding key-value pairs to
the Properties/Memberships panel.
Step 5 (Rendering) – In order to generate rendered images from the uploaded and edited maps, the
OSM project provides three different tools;
© ISO 2010 – All rights reserved
23
- Kosmos : Kosmos is a lightweight OSM map rendering platform primarily designed to be used by
OSM users on their own computers to render maps. This is probably the easiest of the three
rendering methods.
- Osmarender: is a renderer based on Extensible Stylesheet Transformation (XSLT) that is able to
create Scalable Vector Graphics (SVG), which can directly be viewed with some web browsers or
converted to bitmaps.
- Mapnik: is a very fast renderer written in C++ that generates bitmap images.
Although several tools for making maps are provided, the mechanisms supporting quality assurance
and metadata are oversimplified in OSM. In principle, quality assurance in OSM is left up to
collaborative work managed by OpenStreetBug. As shown in Figure A.3, user comments on maps of
OSM.
[Figure A.3 - An example of OpenStreetBugs – source http://openstreetbugs.appspot.com/]
Some additional software is also provided to assure and improve the quality of OSM maps such as:
- Keep Right (Quality Assurance tool)
- WayCheck: way connection and crossings
- Osmdiff: tool for discovering differences between two OSM maps, and
- OSM Mapper: to examine the last version.
Although the user may add property on elements and write free wiki explanations regarding OSM data,
no formal metadata is defined in the OSM project.
A.4 Maintaining and sharing OSM data
OSM map data are stored and maintained by a simple technical infrastructure, which is are a group of
centralized databases holding the live data implemented in MySQL. The database schema is also
designed to support wiki behaviours such as versioning, rollbacks, and logs [2]. Using the databases
containing all the geographic data and attributes that OSM contributors have collected, the mapping
output from the OSM data is presented on the OSM website through a Google Maps-like interface.
The tiles on the OSM website are rendered by Mapnik, which was described above as open source
© ISO 2010 – All rights reserved
24
library and C++ application program for generating map images. Since the rendering process is
computationally expensive, a distributed approach, called Tiles@Home, has been also developed.
Access and sharing of OSM databases are provided by a set of RESTful APIs for enabling users to add,
update, read, and delete geographic features. These APIs accept inputs and output data in OSM XML,
which is a dedicated data transfer format for OSM. Unlike GML, OSM XML contains basic and
simple geometric types and a tagging schema. This functionality enables any community to define and
update the schema by proposing new tagging schemas [6].
A.5 Applications of OSM data
Several applications have been developed by using OSM data. The scope of applications covers a wide
spectrum of areas such as
- Opentouchmap: a web interface optimized for touch screen mobile devices like iPhone
- AndNav2: an interface for Android
- GMap.NET: .net control for displaying OSM, and
- Rostock 3D: a 3D virtual city model (CityGML LOD 1) for Rostock in Germany.
A.6 Discussion
The OSM project provides a good experience of public participation of geographic information
production and consumption and is gaining a large popularity through user groups. OSM may be
considered as a typical example of UPA because of these criteria. However several weak points or
issues of OSM exist and are examined from the viewpoint of standardization. Those points are as
follows:
- Quality control and metadata: as previously mentioned in A.3, no rigorous quality control and
metadata are included in OSM map construction procedure. Even though it may not be as
complete as the standards of ISO/TC211 – ISO 19113, ISO 19114, ISO 19115, and ISO 19138,
we need a minimum set of standards for the quality control and metadata documentation of OSM
data.
- Privacy and intellectual proprietary issues: due to the property of open source and free access of
OSM, it may be more difficult to control the privacy of personal information and to protect the
intellectual proprietary of data. It is required to enforce or make the standards to control privacy
data and protect intellectual proprietary of data without reducing the merits of OSM.
- Data models: OSM employs a geometric model consisting of nodes, lines, and areas, which is
much simpler than ISO 19107 and ISO 19137. It may be necessary to define a very light profile
of ISO 19107 to cover such requirements.
- OSM provides a set of RESTful APIs to public users similar to other open APIs like Google
Map or Yahoo Map. A standard for open APIs will be also useful.
References
[1] OpenStreetMap Official Homepage, http://www.openstreetmap.org
[2] Mordechai Haklay and Patric Weber, “OpenStreetMap: User-Generated Street Maps”, IEEE
Pervasive Computing, October-December, 2008, pp.12-18
© ISO 2010 – All rights reserved
25
[3] Chris Perkins and Martin Dodge, “The potential user-generated cartography: a case study of the
OpenStreetMap project and Mapchester mapping party”, North West Geography, Vol.8 No.1,
2008, pp.19-32
[4] Jeff Howe, “The Rise of Crowdsourcing”, Wired, Issue 14.06, June, 2006,
http://www.wired.com/wired/archive/14.06/crowds.html
[5] OpenStreetMap Beginners Guide 1.3 Official Homepage,
http://wiki.openstreetmap.org/wiki/Beginners%27_Guide
[6] OpenStreetMap API v0.6, http://wiki.openstreetmap.org/wiki/API_v0.6#Changesets_2
[7] Rostock 3D, http://wiki.openstreetmap.org/wiki/OSM-3D#Rostock_3D
[8] New Popular Edition Map Official Home Page, http://www.npemap.org.uk/
© ISO 2010 – All rights reserved
26