emotion system – analysis of technical...

Deliverable No.: D 5

eMOTION System – Analysis of Technical Standards

April 2007

Final 1.0

Project funded by the European Community under the Sixth Framework Programme for Research and Technological Development.

Deliverable D 5 Analysis of Technical Standards

© eMOTION Consortium of 131

Project ref. no.: TREN/06/FP6TR/S07.57248/019939 EMOTION

Project title: eMOTION – Europe-wide multi-Modal On-trip Traffic InformatiON

Deliverable title: Analysis of Technical Standards

Deliverable number: D 5

Deliverable status: Public

Number of pages: 136

Author(s): Reinhard Erstling (interactive instruments – editor) Stefan Olk (interactive instruments – editor) Alexio Picco (Azienda Mobilità e Infrastrutture) Marko Jandrisits (ASFINAG) Norbert Hainitz (ATTC - Arsenal) Walter Schneider (ATTC - Arsenal) Rainer Rehberger (ATTC / CNS-Solutions & Support GmbH) Carmen Riedler (ATTC - Kapsch) Karl Schedler (micKS) Andreas Kochs (Momatec) Harald Doderer (OneStepAhead) Nihat Küçük (OneStepAhead) Michele Masnata (Softeco) Linde Vande Velde (Tele Atlas) Marco Annoni (Telecom Italia) Tomas Starek (Telematix Services) Grant MacKinnon (Transport Simulation Systems)

Status Version Date Change Note ID

Draft 0.1 22.01.2007 First Internal Release

Draft 0.2 11.02.2007 Work assignments, structuring instructions for content standards

Draft 0.3 12.03.2007 Integration of contributions by mmt, TA,



TMX, OSA, ii.

Draft 0.4 20.03.2007 Further integration of contributions by OSA, TA, mmt, Softeco, TSS, ATTC, AMI, GdC, TMX. Structuring by micKS.

Draft 0.5 24.04.2007 Further work by II, TMX, Softeco, ATTC, micKS. Changes due to Ghent WP3-PM1.

Draft 0.6 02.05.2007 Further work by TSS (new: 2.4.5, 2.8.6; upd: 2.2.4) TI (new: 5.2, 5.3) AMI (note to 2.7.4) TMX (upd 2.4.2, 2.9.3) mmt (upd: 2.4.1, 2.5.1, 2.5.2, 2.6.1, 2.7.1, 2.10.4; new: 2.6.5, 4.2.2) II (upd. 3.2.4)

Also: Former subsection 2.8.6 is divided into 2.2.5, 2.9.6 and 2.12.4 - see remarks there.

Draft 0.7 07.05.2007 Further work by ATTC (new (Arsenal): 2.2.3, 2.8.2, 2.8.10; upd (Kapsch): 2.6.3; upd (Arsenal): 2.8.4); mmt (change responsibility of 2.5.2, 2.6.4); micKS (upd. 2.10.1, 2.10.2; new: 2.10.3); ii (new: 2.3.1); TMX (upd 2.6.2, 2.7.2, 2.7.3, 2.8.9; new stub 4.7.1); Softeco (upd. 2.2.2, 2.8.1, 2.8.11) Also: Former subsections 2.8.3, 2.8.4 and 2.14.1 are deleted, subsection 2.2.4 is divided in 2.2.4 and 2.12.5 (NaPTAN/NPTG);

Draft 0.8 27.05.2007 Further work by

ATTC (new stub 4.2.3, upd 2.6.3); TI (upd. 3.2.3, 3.2.5, 5.2, 5.3, new 5.4, 5.5); Softeco (upd. 2.2.2, 2.8.1, 2.12.6); TMX (upd.2.4.2, 2.6.2, 2.7.3, 2.8.7, 2.9.3); ii (new: 4.2.1, 4.11.1, 4.14.1, 4.15.1, 4.16); TSS (upd. 2.2.4, 2.2.5, 2.4.5, 2.9.6,



2.12.4; new: 2.8.3, 2.8.5)

Also: deleted former subsections 2.7.4, 2.8.7, 2.8.8, 2.15

Draft 0.9 04.06.2007 Further work by

Softeco (upd. 2.2.2, 2.8.1, 2.12.3; new 5.6)

ASFINAG (upd. 2.5.2)

mmt (upd. 2.4.1, 2.5.1, 2.6.1, 2.6.5, 4.2.2; new: 2.5.3, 2.6.6, 2.7.5, 4.5.2, 6.3, 6.4, 6.7)

TSS (upd. 2.2.4, 2.2.5, 2.4.5, 2.8.3, 2.8.5, 2.9.6, 2.12.4, 2.12.5, 2.12.6, 4.5.1, 6.6)

TMX (upd. 2.4.2, 2.6.4 (dropped), 2.8.7, new 4.7.1)

ii (upd. 2.4.6, 4.5.3, 4.5.4; new 4.7.2)

ATTC (new 2.2.7, 2.8.9, 2.12.7, 6.2, 6.6)

micKS (upd. 2.10.1, 2.10.2, 2.10.3, 2.10.4, 6.5)

TA (upd. 2.2.1, new 6.1, 6.8, 6.9)

Draft 1.0 08.07.2007 Reorganisation: creation of Appendix 1, restructuring main document;

Additions in Appendix 1:

ii (new 1, 2.1.3, 2.1.4, 4.2, 4.3.2, 4.4.1, 4.4.2, 4.6, 4.6.1, 4.8, 4.8.1, 4.8.2, 4.9, 4.9.1, 4.12, 4.12.1, 4.12.2, 4.12.3, 4.13, 4.13.1, 4.14, 4.15)

ATTC (new: 4.2.3; upd. 2.8.2)

Softeco (new 5.1)

TSS (new: 2.4.7)

micKS (upd 2.10, 6.5)

Final Draft 1.1 20.07.2007 Completion of chapter “Literature” in main document. Insertion of standardised literature references from all over the text. Complete “List of Abbreviations”.

Final Draft 1.2 31.08.2007 Additions and corrections after review by



TSS. Incorporation of comments from Roger Slevin DfT Transport Direct.

Addition of two standards: ISO19115 metadata and W3C SOAP.

Final Draft 2.0 07.04.2008 MMT: review of all chapters; II: resolved editorial issues

THE INFORMATION IN THIS DOCUMENT IS PROVIDED AS IS AND NO GUARANTEE OR WARRANTY IS GIVEN THAT

THE INFORMATION IS FIT FOR ANY PURPOSE. THE USER THEREOF USES THE INFORMATION AT ITS SOLE RISK

AND LIABILITY. FURTHERMORE, DATA, CONCLUSIONS OR RECOMMENDATIONS IN THIS DOCUMENT ARE PROVIDED

ON THE BASIS THAT SUCH INFORMATION IS SUBSEQUENTLY, AND PRIOR TO USE, VERIFIED BY THE

PARTY WISHING TO USE THAT INFORMATION.

List of Abbreviations

ADT Abstract Data Types

Alert-C Advice and Problem Location for European Road Traffic, version C

API Application Programming Interface

ASR Automatic Speech Recognition

ATOC Association of Train Operating Companies

BUFR Binary Universal Form for the Representation of meteorological data

CALYPSO Contact And Contactless Telematics platform Yielding a Citizen Pass integrating urban Services and financial Operations

CAT Catalogue Interface standard

CD Committee Draft



CEN European Committee for Standardization

COURIER Cross-border Organisation & User Requirements for Information Exchange Review

CREX Character form for the Representation and EXchange of data

CRS Coordinate Reference System

CSV Comma Separated Values

CSW Catalogue Services for the Web

DANAE Dynamic and Distributed Adaptation of scalable multimedia content in a context-Aware Environment

DATEX2 (version 2 of European standard for traffic and travel) data exchange (between traffic control and information centres as well as other actors of the traffic and travel information sector)

DDA Disability Discrimination Act

DELFI Nationwide Electronic Time Table Information - German: Durchgängige Elektronische Fahrplaninformation

DfT UK Department for Transport

DNS Domain Name System

DRM Digital Rights Management

DSML Directory Services Markup Language

ebXML Electronic Business using eXtensible Markup Language

EC European Commission

EDGE Enhanced Data Rates for GSM Evolution

EDI Electronic Data Interchange

EFCD Enhanced Floating Car Data

eMOTION Europe-wide multi-Modal On-trip Traffic InformatiON

EPC European Payments Council

eps Electronic Payment System

FCD Floating Car Data

FTP File Transfer Protocol

GDF Geographic Data Files

GDS Global Distribution Systems

GeoDRM Geospatial Digital Rights Management

GML Geography Markup Language



GPRS General Packet Radio Service

GPS Global Positioning System

GSM Global System for Mobile Communications

GST Global System for Telematics

Halogen Highways Agency Logging Environment

HAPMS Highways Agency Pavement Management System

HTML Hypertext Markup Language

HTTP Hyper Text Transfer Protocol

HTTPS Hyper Text Transfer Protocol Secure

IATA International Air Transport Association

ICARE Integration of Contactless technologies into public transport environment

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

IFOPT Identification of Fixed Objects in Public Transport

IM@GINE IT Intelligent Mobility AGents, Advanced Positioning and Mapping Technologies INtEgration Interoperable MulTimodal, location-based services

IMAP Internet Message Access Protocol or Interactive Mail Access Protocol

IMS IP Multimedia Subsystem

INFOTEN Multi-modal Information and Traffic Management Systems on Trans-European Networks

INSPIRE Infrastructure for Spatial Information in the European Community

InteGRail Intelligent Integration of Railway systems

INTERCEPT Intermodal Concepts in European Passenger Transport

INTRO Intelligent roads

IP Internet Protocol

IPA International Phonetic Alphabet

ISO International Organization for Standardization

ITS Intelligent Transport Systems

ITSO Interoperable smart card ticketing

J2ME Java Platform, Mobile Edition



JTDB Journey Time Database

LAN Local Area Network

LDAP Lightweight Directory Access Protocol

LoS Level of Service

MAN Metropolitan Area Network

NaPTAN National Public Transport Access Node Database

NPTG National Public Transport Gazetteer

OASIS Organization for the Advancement of Structured Information Standards

OGC Open Geospatial Consortium

OpenLS OpenGIS® Location Service

OSI Open Systems Interconnection

OTA OpenTravel Alliance

OTAP Open Travel Data Access Protocol

OTC Open Tourism Consortium

PCC Project Coordination Committee

PDA Personal digital assistants

PLS Pronunciation Lexicon Specification

POI Point of Interest

POIX Point Of Interest eXchange Language Specification

POP Post Office Protocol

PT Public Transport

RDS Radio Data System

REACT Realizing Enhanced Safety and Efficiency in European Road Transport

RJIS Rail Journey Information System

RM-ODP Reference Model for Open, Distributed Processing

RTIG Real Time Information Group

SAML Security Assertion Markup Language

SAMPA Speech Assessment Methods Phonetic Alphabet

SDEP Street events Data Exchange Protocol

SDI Spatial Data Infrastructure

SEPA Single Euro Payments Area



SIRI Service Interface for Real Time Information

SLD Styled Layer Descriptor

SMIL Synchronized Multimedia Integration Language

SMS Short Message Service

SMTP Simple Mail Transfer Protocol

SNMP Simple Network Management Protocol

SOAP Simple Object Access Protocol

SQL Structured Query Language

SRW Scheduled Road Works

SSH Secure Shell

SSL Secure Sockets Layer

SSML Speech Synthesis Markup Language

SyncML Synchronisation Markup Language

TAP Transferred Account Procedure

TC Technical Committee

TCC Technical Coordination Committee

TCP Transmission Control Protocol

TIC Traffic Information Center

TIH Travel Information Highway

TLS German: 'Technische Lieferbedingungen für Streckenstationen'

Technical delivery conditions for Roadside Controllers

TLS Transport Layer Security

TourML Tourism Markup Language

TPEG Transport Protocol Experts Group

TRIDENT TRansport Intermodality Data sharing and Exchange NeTworks

TTI Travel Technology Initiative

TTS Text-To-Speech

TourXML Tourism Markup Language

TPEG Transport Protocol Experts Group

TMC Traffic Message Channel

UDDI Universal Description, Discovery, and Integration

UDP User Datagram Protocol



UML Unified Modeling Language

UMTS Universal Mobile Telecommunications System

URL Uniform Resource Locator

UTMC Urban Traffic Management and Control

VIH Video Information Highway

W3C World Wide Web Consortium

WAI Web Accessibility Initiative

WAP Wireless Application Protocol

WCS Web Coverage Service

WCTS Web Coordinate Transformation Service

WFS Web Feature Service

WiMAX Worldwide interoperability for Microwave Access

WMO World Meterological Organization

WMS Web Map Service

WNS Web Notification Service

WP Work Package

WPL Work Package Leader

WPOS Web Pricing and Ordering Services

WS-BPEL Web Services Business Process Execution Language

WSDL Web Service Description Language

WSN Web Services Notification

XACML eXtensible Access Control Markup Language

XML Extensible Markup Language



Table of Content

1. EXECUTIVE SUMMARY ................................................................................................16

1.1 OBJECTIVES ..............................................................................................................16

1.2 METHODOLOGY .........................................................................................................17

1.3 MAIN RESULTS ..........................................................................................................19

1.4 DELIVERABLE OVERVIEW ...........................................................................................21

1.5 APPENDIX 1 OVERVIEW..............................................................................................26 2. STANDARDISATION BODIES.......................................................................................37

2.1 INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO) / TC 204......................37

2.2 INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO) / TC 211......................37

2.3 EUROPEAN COMMITTEE FOR STANDARDIZATION (CEN) ..............................................37

2.4 WORLD WIDE WEB CONSORTIUM (W3C)....................................................................38

2.5 ORGANIZATION FOR THE ADVANCEMENT OF STRUCTURED INFORMATION STANDARDS

(OASIS) ..............................................................................................................................38

2.6 OPEN GEOSPATIAL CONSORTIUM (OGC) ...................................................................38 3. DOMAIN SPECIFIC STANDARDS.................................................................................39

3.1 PRIVATE TRAFFIC INFORMATION.................................................................................39 3.1.1 DATEX........................................................................................................................... 39 3.1.2 DATEX 2........................................................................................................................ 39 3.1.3 EuroRoadS - Road Network Information Model............................................................ 40 3.1.4 Global System for Telematics: Enhanced Floating Car Data (GST: EFCD)................. 41 3.1.5 Highways Agency Pavement Management System (HAPMS) ..................................... 41 3.1.6 Intelligent roads (INTRO)............................................................................................... 42 3.1.7 ISO 14819: Radio Data System - Traffic Message Channel (RDS-TMC) .................... 42 3.1.8 ISO 18234 / ISO 24530: Transport Protocol Experts Group (TPEG) Standards .......... 43 3.1.9 Integrated Transport Network Layer (ITN) .................................................................... 44 3.1.10 Journey Time Database (JTDB).................................................................................... 45 3.1.11 Code of Practice for Traffic Control and Information Systems (MCH1869) .................. 45 3.1.12 Open Travel data Access Protocol (OTAP) .................................................................. 45 3.1.13 Realizing Enhanced Safety and Efficiency in European Road Transport (REACT) ..... 46 3.1.14 Safety Standards For In-Vehicle Information Systems ................................................. 46 3.1.15 Street events Data Exchange Protocol (SDEP) ............................................................ 46 3.1.16 Scheduled Road Works (SRW)..................................................................................... 46 3.1.17 Traffic Info Centre XML-based Data Model (TICXML ) ................................................. 47



3.1.18 Travel Information Highway (TIH) ................................................................................. 47 3.1.19 TrafficML........................................................................................................................ 48 3.1.20 XML Schemas for Exchange of Transportation Data (TransXML)................................ 48 3.1.21 TRansport Intermodality Data sharing and Exchange NeTwork (TRIDENT)................ 48 3.1.22 UTMC Standard - TS004: Car Park Monitor MIB.......................................................... 49 3.1.23 Video Information Highway (VIH) .................................................................................. 49

3.2 PUBLIC TRANSPORTATION INFORMATION....................................................................50 3.2.1 EU-Spirit ........................................................................................................................ 50 3.2.2 FareXChange ................................................................................................................ 50 3.2.3 International Air Transport Association (IATA) Standards ............................................ 50 3.2.4 Identification of Fixed Objects in Public Transport (IFOPT) .......................................... 51 3.2.5 Intelligent Integration of Railway systems (InteGRail)................................................... 52 3.2.6 National Public Transport Access Node Database / National Public Transport Gazetteer (NaPTAN / NPTG) ........................................................................................................ 52 3.2.7 PlusBus.......................................................................................................................... 53 3.2.8 PubTrans ....................................................................................................................... 53 3.2.9 Rail Journey Information System (RJIS) ....................................................................... 53 3.2.10 Railway Markup Language (RailML®) .......................................................................... 54 3.2.11 Real Time Information Group: Bus Management Standards - RTIGT021.................... 54 3.2.12 Real Time Interest Group XML (RTIG-XML)................................................................. 55 3.2.13 Service Interface for Real Time Information (SIRI) ....................................................... 55 3.2.14 ENV 12896: Transmodel ............................................................................................... 56 3.2.15 Transport Exchange (TransXChange) .......................................................................... 57 3.2.16 Rail Data Transmission and Data Processing (UIC) ..................................................... 57 3.2.17 Verband Deutscher Verkehrsunternehmen - VDV-Schnittstelleninitiative (Interface Initiative) 58

3.3 WEATHER DATA ........................................................................................................58 3.3.1 Binary Universal Form for the Representation of meteorological data (BUFR) / Character form for the Representation and EXchange of data (CREX) ....................................... 58 3.3.2 TLS Standard - Environmental Data (FG3) ................................................................... 59 3.3.3 UK National Air Quality Standards/Strategy.................................................................. 60

3.4 LOCATION BASED SERVICES ......................................................................................60 3.4.1 Directory Services Standards (DSML) .......................................................................... 60 3.4.2 OGC Web Feature Service (WFS): Gazetteer Service Profile...................................... 61 3.4.3 HIGHWAY...................................................................................................................... 62 3.4.4 Multi-modal Information and Traffic Management Systems on Trans-European Networks (INFOTEN) .................................................................................................................... 62



3.4.5 ISO 19133: Location-based services - Tracking and navigation................................... 63 3.4.6 ISO 19134: Location-based services - Multimodal routing and navigation................... 64 3.4.7 OpenGIS® Location Service (OpenLS) ........................................................................ 64 3.4.8 Point Of Interest eXchange Language Specification (POIX) ........................................ 66 3.4.9 Tourism Markup Language (TourML)............................................................................ 66

3.5 ROUTING/NAVIGATION AND PUBLIC TRANSPORT JOURNEY PLANNING..........................67 3.5.1 Association of Transport Coordinating Officers-Common Interface File (ATCO-CIF) .. 67 3.5.2 Nationwide Electronic Time Table Information - Durchgängige Elektronische Fahrplaninformation (DELFI)......................................................................................................... 68 3.5.3 Ferry XML...................................................................................................................... 68 3.5.4 Global Distribution Systems (GDS) ............................................................................... 69 3.5.5 IM@GINE IT .................................................................................................................. 69 3.5.6 Intermodal Concepts in European Passenger Transport (INTERCEPT)...................... 70 3.5.7 ISO 14825: Geographic Data Files (GDF) .................................................................... 70 3.5.8 ISO 17572-3: AGORA-C ............................................................................................... 71 3.5.9 JourneyWeb .................................................................................................................. 72 3.5.10 OGC Web Coordinate Transformation Service (WCTS)............................................... 73 3.5.11 OpenTravel Alliance (OTA) Standard............................................................................ 74

4. DOMAIN INDEPENDENT STANDARDS .......................................................................76

4.1 SPATIAL DATA INFRASTRUCTURE ...............................................................................76 4.1.1 Geography Markup Language (GML) ........................................................................... 76 4.1.2 OGC Web Coverage Service (WCS) ............................................................................ 77 4.1.3 OGC Web Feature Service (WFS) ................................................................................ 77 4.1.4 OGC Web Map Service (WMS)..................................................................................... 78 4.1.5 OGC Web Map Service (WMS) with Styled Layer Descriptor (SLD) ............................ 79 4.1.6 OGC Web Notification Service (WNS) .......................................................................... 80 4.1.7 OASIS Web Services Notification (WSN)...................................................................... 80

4.2 REGISTRY .................................................................................................................81 4.2.1 ISO 19115: Geographic information – Metadata........................................................... 81 4.2.2 OGC Catalogue Services Specifications....................................................................... 82 4.2.3 OGC Catalogue Services - ebRIM Profile of CSW ....................................................... 82 4.2.4 OGC Catalogue Services - ISO19115/ISO19119 Profile of CSW ................................ 83 4.2.5 OASIS ebXML Registry Services and Protocols........................................................... 84

4.3 AUTHENTICATION, AUTHORISATION, DRM ..................................................................84 4.3.1 Contact And Contactless Telematics platform Yielding a Citizen Pass integrating urban Services and financial Operations (CALYPSO) ............................................................................ 84 4.3.2 Global System for Telematics: Certification (GST: CERTECS) .................................... 85



4.3.3 OGC Geospatial Digital Rights Management Reference Modell (GeoDRM RM) ......... 85 4.3.4 OASIS Security Assertion Markup Language (SAML) .................................................. 86 4.3.5 OASIS eXtensible Access Control Markup Language (XACML) / GeoXACML............ 86

4.4 ECOMMERCE .............................................................................................................87 4.4.1 Electronic Payment System (eps) ................................................................................. 87 4.4.2 Global System for Telematics: Security (GST: SEC) .................................................... 88 4.4.3 Global System for Telematics: Service Payment (GST: S-PAY) .................................. 88 4.4.4 Integration of Contactless technologies into public transport environment (ICARE ) ... 88 4.4.5 Interoperable smart card ticketing (ITSO) ..................................................................... 89 4.4.6 Single Euro Payments Area (SEPA) ............................................................................. 89 4.4.7 Transferred Account Procedure (TAP / TAP3).............................................................. 90 4.4.8 OGC Web Pricing and Ordering Service (WPOS) ........................................................ 90

4.5 COMMUNICATION STANDARDS....................................................................................91 4.5.1 ANEMONE..................................................................................................................... 91 4.5.2 Continuous air interface, long and medium range (CALM)........................................... 91 4.5.3 Global System for Telematics: Open Systems (GST: OS)............................................ 91 4.5.4 Hand-Held Devices and User Terminals....................................................................... 92 4.5.5 IP Multimedia Subsystem (IMS) .................................................................................... 93 4.5.6 Internet Communication Standards............................................................................... 95 4.5.7 Pronunciation Lexicon Specification (PLS) ................................................................... 98 4.5.8 Public Wireless Networks - GSM/GPRS/EDGE/UMTS................................................. 99 4.5.9 Speech Assessment Methods Phonetic Alphabet (SAMPA / X-SAMPA) ................... 100 4.5.10 Synchronized Multimedia Integration Language (SMIL) ............................................. 100 4.5.11 Speech Synthesis Markup Language specification (SSML) ....................................... 101 4.5.12 Voice Extensible Markup Language (VoiceXML)........................................................ 101 4.5.13 Worldwide Interoperability for Microwave Access (WiMAX) ....................................... 102 4.5.14 Wireless Communication Protocols............................................................................. 103

4.6 OTHER STANDARDS.................................................................................................103 4.6.1 Dynamic and Distributed Adaptation of scalable multimedia content in a context-Aware Environment (DANAE)................................................................................................................. 103 4.6.2 Disability Discrimination Act (DDA) ............................................................................. 104 4.6.3 European ITS Framework Architecture / Framework Architecture Made for Europe (EITSFA / FRAME) ...................................................................................................................... 105 4.6.4 Highways Agency Logging Environment (Halogen).................................................... 105 4.6.5 INFOPOLIS 2............................................................................................................... 105 4.6.6 Simple Network Management Protocol (SNMP) ......................................................... 105 4.6.7 SYSTRANLinks ........................................................................................................... 106



4.6.8 OASIS Translation Web Service (Trans-WS) ............................................................. 106 4.6.9 Transit Communications Interface Profiles (TCIP)...................................................... 107 4.6.10 Web Accessibility Initiative (WAI) ................................................................................ 107 4.6.11 OASIS Web Services Business Process Execution Language (WS-BPEL)............... 107

5. ANALYSIS OF AVAILABLE CONTENT ......................................................................109

5.1 ROAD NETWORK DATA ............................................................................................109

5.2 PUBLIC TRANSPORT NETWORK DATA .......................................................................110

5.3 TRAFFIC FLOW DATA ...............................................................................................112

5.4 TRAFFIC MESSAGES ................................................................................................113

5.5 WEATHER DATA ......................................................................................................115

5.6 PUBLIC TRANSPORT.................................................................................................121

5.7 PARKING .................................................................................................................123

5.8 POI AND OTHER ADDITIONAL DATA ...........................................................................124

5.9 MAP DATA...............................................................................................................126 6. LITERATURE ...............................................................................................................129

List of Tables

Table 1 - NGN standards related to IMS ................................................................................94



1. Executive Summary

This eMOTION deliverable (D5) documents the results of the analysis part of Work Package 3 (WP3). The deliverable consists of this document (Main Document) and an appendix (Appendix 1).

1.1 Objectives

WP3 as a whole is concerned with the Technical Standard Specification, which deals with all aspects of the implementation of the eMOTION system and is the basis for the proof-of-concept performed in WP5.

The system specification of eMOTION to be worked out in WP3 shall provide an open architecture, which enables the step-by-step integration of all existing information services, if they follow the eMOTION Technical Standard Specification. The design of the architecture focuses on interoperability on the basis of ISO/TC 211 and OGC (Open Geospatial Consortium) standards. These are also the basis of Spatial Data Infrastructures (SDIs), which are currently emerging on all levels, from regional to European and world wide scale. The most prominent European SDI endeavour is INSPIRE, see http://www.ec-gis.org/inspire/.

The analysis part of WP3, which is documented in this deliverable, primarily deals with existing standards regarding to the eMOTION system. The goal of the analysis is to find out which of the existing standards have the potential to form the foundation of the eMOTION Technical Standard Specification, and which are important to eMOTION because they underlie existing information sources, into which eMOTION is going to tap. Tapping means: it must be possible to easily translate from that standard to the eMOTION standard.

Therefore it is also a task of WP3 to analyse current content offerings and to classify them according to their closeness to the analysed standards and their availability. Actually, since this has already been done in WP1, the documentation in WP3 and D5 restricts itself to the material which might play a potential role in the proof-of-concept.

The Technical Standards Specification, which is to be the main result of WP3, follows the Reference Model for Open, Distributed Processing, RM-ODP and is expected to

• [Information Viewpoint]: develop an eMOTION application schema, metadata information model, styling and symbolisation for visualisation and a data flow definition, and also

• [Computational Viewpoint]: define eMOTION service interfaces based on a distributed and Internet-based system architecture, and finally

• [Engineering Viewpoint]: explain the distribution of nodes in the eMOTION system.

Particularly, to create a uniform eMOTION application schema and a model of useful eMOTION service interfaces the analysis in D5 has to take a very close and detailed look at the available standards.



1.2 Methodology

First of all, it has been important to detect all relevant standards and evaluate their meaning and impact on eMOTION.

For this purpose the project could first and foremost resort to the specialized knowledge of its consortium partners, who possess the necessary experience concerning significant standards, specifications and projects from their diverse technical domains. An additional help has been a compilation of international and national standards prepared by the Transport Direct project of the U.K.’s Department for Transport, which kindly made available a preliminary version of an extensive catalogue of ITS standards to eMOTION.

The word “standard” was actually interpreted quite loosely. Of course, international standards were given precedence, however, if there was a national standard or even a project with a specified output, which was deemed suited to contribute to the eMOTION model, it has been included in the survey.

The main document of D5 gives an outline of the collected standards and specifications and evaluates them regarding their relevance to eMOTION. For a selection of the standards, those which have been deemed relevant for eMOTION, Appendix 1 of D5 presents a much more detailed analysis.

Existing ITS standards and in-use specifications are very diverse, some describe data models, from very abstract to very concrete and from simple to complex, some (the more modern ones) form a uniform package of data models or exchange format specifications with an integrated service interface. Today’s standards usually describe data exchange encodings in XML.

As a matter of course, D5 has also to investigate general IT standards (besides ITS standards), if they appear usable for the purposes of eMOTION. This particularly applies to the family of standards, which is employed for setting up Spatial Data Infrastructures, because eMOTION is expected to be compliant to these. This concerns the standards from ISO/TC 211, from Open Geospatial Consortium (OGC), and from OASIS.

In order to be able to effectively compare these very different standards from various domains, it was necessary to dissect the consideration of the standards into small particular facets. Of course, many standards contribute to more than one of these facets, which has to be accommodated.

This very detailed analysis is combined in Appendix 1 of D5.

The primary criteria for the decomposition were chosen as follows:

Content

Encodings

Services

Network and Communication

The “Content” chapter views the various standards according to the following technical



domains:

Road Network Data

Public Transport Network Data

Inter-modal Transport Network Data

Location Referencing

Traffic Flow Data

Traffic Messages

Parking

Public Transport Service Data

POI and Other Directories

Data for Routing

Data for Public Transport Journey Planning

Data for Inter-modal Journey Planning

Data for Freight Traffic

General Metadata

The criteria analysed in all these domains for all standards were

“Feature Catalogue”, which was carried out as elucidated UML diagrams and constitutes the main results of the analysis, XML defined specifications (stripped from their purely service related parts) were backwards-engineered to UML,

“Encoding”, which were usually not elaborated in depth,

“Portayal Catalogue”, which was aimed at detecting mapping standards (but gave no results),

“Service Reference”, which was to document the use of the content in a service context.

The chapter “Encodings” logically belongs to chapter “Services”. It accommodates the analysis of a few important encodings, which will or may play a role in the eMOTION specification. The chapter is in no way complete, because most encodings have been deemed part of the services they are using them and were described alongside with these.

The following categories of “Services” have been dealt with:

Application Service

Data Service

Mapping Service

Routing Service

Public Transport Journey Planning Service



Positioning Service

Directory service

Geocoding Service

Coordinate Transformation Service

Registry / Catalogue Service

Event Notification Service

Digital Rights Management and Security

Pricing and Ordering

Payment and Billing

Workflow Support

Network Management

Natural Language Translation

Here the criteria were

“Functionality”, pointing out the overall range of functions the service under considerations performs,

“Interface”, describing the way the service can be invoked.

The standards treated in the “Communication and Network” chapter do not overlap with the road and traffic oriented domains of eMOTION. The analysis of these standards has been done in anticipation of the Engineering Viewpoint of the specification in D6.

The analysis has used the following structure:

Internet Communication Standards

Public Wireless Networks

IMS

WiMAX

Wireless Communication Protocols

Hand-Held Devices and User Terminals

The analysis will allow to compare the particular standards and evaluate their usefulness for the eMOTION infrastructure definition.

1.3 Main Results

One of the first striking results of the content analysis is that no standards or specifications regarding visualisation, symbolisation or styling of maps have been found. Admittedly, there appear to be some quite different national conventions in place, and it can be expected that emerging Europe-wide and international information systems will be defining new de-facto international conventions. Since evidently the creation of maps on the basis of ITS data is not



currently an issue with an observable quest for harmonisation, the specification of eMOTION mapping styles can be done without interfering with any established conventions.

Another field, where virtually no specifications were found, is metadata. There is currently no established way to “talk” about ITS data, for example to explain its provenance, coverage, quality, etc. Therefore, the choice of an appropriate metadata model is left to the discretion of eMOTION. In order to publish eMOTION data in registries, eMOTION can choose, for example, ISO 19115 or any model, which appears appropriate.

Concerning content, it seems obvious that eMOTION cannot be based on a unique network model. This is true, though there is GDF (ISO 14825) being an international and widespread standard with an extensive, high quality database offered by two commercial vendors, which is the basis of nearly all navigation applications worldwide.

The observation is also made by projects like EuroRoadS: At the same time there exist a multitude of diverse road database solutions in the different countries, from national down to the communal domain, which carry significant data from public administrations, like traffic messages from Traffic Information Centres, road works planning or parking information in cities, etc. Often these data are not even network referenced, but only specified by street addresses or other means of referencing.

eMOTION should therefore do without choosing a specific network model as the basis of its specifications. The eMOTION specification should rather carry out the referencing of ITS features and properties to arbitrary networks by means of a flexible Location Referencing model. At the most, an abstract graph as for example described by the EuroRoadS project might be appropriate, in case abstract references to specific network nodes or edges are needed. The necessary conversion (projection) between the references to different network models can be accomplished by eMOTION services, which in this case encapsulate the access to the network data. Location Referencing can be done by various means, where modern developments like AGORA-C also have to be allowed for.

The results of the comparison of content standards regarding the domain of individual traffic (traffic data, traffic messages, parking) appear quite obvious. It appears that most of the harmonisation work in this domain has already been carried out by the DATEX 2 specification, which can therefore be employed as the basis for eMOTION modelling of traffic data. Incidentally, DATEX 2 also uses a variable Location Referencing scheme, which in this case comprises RDS-TMC location codes, TPEG-loc, and the use of coordinates.

The world of public transport looks much more complex.

Indeed, there is a CEN standard, named Transmodel (EN12896), which, being a reference model, appears to be the basis of most of the many public transport standards. However, Transmodel is a very complex and very abstract standard – it is a comprehensive reference model fitting all needs in the public transport domain. Moreover, it is not always obvious, in which way the claim to be based on Transmodel is actually justified for some standards of the domain.

As it appears, a simplified profile of Transmodel should be defined as the eMOTION public



transport model. Adhering to the Transmodel reference model will allow eMOTION to evolve to more complex profiles if necessary in the future. For the definition of the necessary objects, these should not be derived from Transmodel directly, but instead on the basis of concrete implementations of that standard.

IFOPT may be the initial point for the fixed objects, the public transport network model. The fixed objects should use the eMOTION Location Referencing definitions to express locations on the earth. Another possible initial point which was discussed among the eMOTION experts was SIRI, especially regarding schedule data and real-time data. By backwards engineering of its service interface definition reasonable objects for Timetable, etc. could be developed. These will have to be harmonised with other requirements from other standards and specifications of the domain.

Road Weather has turned out to be an isolated area, where only little harmonization effort needs to be spent. Surprisingly, the DATEX 2 model of the weather domain will need only few amendments to cover the necessary data.

Regarding services, eMOTION is by its project definition already geared towards the service standards employed in Spatial Data Infrastructures. Naturally, the possibility arises, to use these service standards (from ISO/TC 211 and OGC) to make available content according to the eMOTION content model.

Which of these services have to be employed still has to be checked. Standards which come into question are the OGC Web Feature Service (WFS) definition as the basic and queryable data source for eMOTION data, Web Map Server (WMS) for the generation of scalable maps and OpenLS for Location Based Services and Routing/ Journey Planning. WFS and WMS are also the basis of large scale SDI endeavours like INSPIRE.

1.4 Deliverable Overview

The main document of D5 treats the standards as a whole without dissecting them in single facets.

Standardisation Bodies

In a first step, the large international standardisation bodies which are responsible for most of the described standards are characterised.

The standardisation body to name first in this context is ISO (International Organization for Standardisation), which accounts for many of the standards in D5.

The Technical Committee (TC) at ISO, responsible for ITS is TC 204. Most of the traffic related standards described in D5 have their origin in ISO/TC 204, examples of which are GDF, TPEG, and ALERT-C.

Also ISO/TC 211 plays an important role for eMOTION, because it is responsible for the ISO 19100 series of standards, which cover geo-information in general. These standards are the basis of Spatial Data Infrastructures (SDIs) and eMOTION is planned to be an SDI for traffic and transport information.



CEN, the European Committee for Standardization is contributing technical standards to the objectives of the European Union and European Economic Area. Only few of the standards in this document are listed as CEN standards – one example is TRANSMODEL.

The W3C (World Wide Web Consortium) is an international consortium where Member organizations, a full-time staff, and the public work together to develop Web standards. Since 1994, W3C has produced more than ninety Web standards, called "W3C Recommendations." A W3C Recommendation is the equivalent of a standard.

OASIS (Organization for the Advancement of Structured Information Standards) is an international consortium that drives the development, convergence, and adoption of e-business standards. The consortium produces more Web services standards than any other organization along with standards for security, e-business, along with standardization efforts in the public sector and for application-specific markets.

Closely related to ISO/TC 211 standards are the standards of OGC (Open Geospatial Consortium). OGC is an international consortium of over 340 companies, government agencies and universities participating in a consensus process to develop publicly available interface specifications. Many of the OGC standards are concrete implementation standards of abstract ISO/TC 211 standards. OGC specifications support interoperable solutions that "geo-enable" the Web, wireless and location-based services, and mainstream IT.

Domain Specific Standards

In the compilation of standards in the document, the standards associated with the technical domains of eMOTION are treated first. The following domains had to be analysed, they form the central technical domains of eMOTION:

• Private traffic information

• Public transportation information

• Weather data

• Location based services

• Routing/navigation and public transport journey planning

Some standards do not fall easily into the above categories. However, the multitude of standards and projects visited needs some arrangement – the authors therefore have tried to make assignments on a best fit basis. Actually, “routing” is often regarded a subtopic of “location based services” – so some confusion may arise.

Private Traffic Information

Important standards visited in the Private Traffic Information domain are:

RDS-TMC – ISO 14819

TPEG standards – ISO 18234 / ISO 24530

DATEX 2

Many more standards and projects from this domain have been visited, partially also to



greater depth, because they cover border areas of the information model. The most modern standard is DATEX 2.

Public Transportation Information

Many more standards have been analysed to greater depth for the Public Transportation Information domain.

EN12896 – Transmodel is the reference model of most other public transport standards.

Other standards examined in depth are:

RailML®

Rail Journey Information System (RJIS)

NaPTAN / NPTG

IFOPT

SIRI

Weather Data

The Weather Data domain contains only a few relevant standards, though standards centered in other domains, like DATEX 2 or RDS-TMC, also cover weather.

The most important standards here seem to be

TLS (Technical delivery conditions for Roadside Controllers (German standard))

BUFR and CREX

Both are treated in depth. As it turns out, DATEX 2 also covers this area sufficiently and can be used as an exchange standard for weather data.

Location Based Services

From the provenance of standards definitions it can be seen that the Location Based Services (LBS) domain has not been derived from the ITS domain point of view.

There are ISO/TC 211 and associated standards (which also include routing/navigation as part of the LBS topic), namely

ISO 19133 – Location Based Services – Tracking and Navigation

ISO 19134 – Location Based Services – Multimodal Routing and Navigation

OGC OpenLS

and several standards/ in-use definitions concentrating on the directory and POI aspect, like

OASIS DSML

POIX

Tourism Markup Language (TourXML)

Routing/Navigation and Public Transport Journey Planning



The routing and navigation domain is, of course, the realm of

GDF – ISO 14852

though this common standard has a lot of extensions into other domains, like LBS, public transport information, etc.

The emerging Location Referencing standard AGORA-C ISO/CD 17572-3 has been also collected under routing/navigation, due to its association to GDF.

The ISO 19133, 19134 and OGC OpenLS standards might as well have been treated under this heading because they are also standards for routing. Actually, routing is considered a part of LBS.

Other standards and definitions from the public transport domain which fall more clearly under the heading are:

DELFI

JourneyWeb

OTA Standard (Group Air)

Ferry XML

Domain Independent Standards

In a second step standards and definitions are gathered which are not associated with ITS or Location Based Services objectives. However, these standards will be needed for a working information infrastructure for eMOTION

Spatial Data Infrastructure Standards

This mostly comprises the general purpose “geo-standards” which are established as the basis of Spatial Data Infrastructures (SDIs). SDIs are currently emerging on all levels and for many domains. The endeavour on the European level is named INSPIRE.

This standards provide web services for the general provision of data and maps over the Internet. They stem from the Open Geospatial Consortium and are in most cases also ISO TC 211 standards.

Registry Standards

Registries are services, which allow useful information to be published in a central place, in order to give possible users the chance to retrieve and find this information and to use it directly or as an information (meta information) of how to use some resource (known as the publish–find–bind pattern).

Registries are mainstream IT services and are not restricted to SDIs, where they are of course also employed. In a spatially enabled infrastructure, registries will need special capabilities. They will, for example also have to deal with spatial queries and store spatial metadata.

Registry standards from OASIS and from OGC have been examined. Additionally the TC 211 metadata standard ISO 19115 has been considered.



Authentication, Authorisation, Digital Rights Management

These are also mainstream IT standards which provide the necessary security in accessing services. Authentication makes sure, that the user of a service is indeed the person/entity he/she claims to be. Authorisation checks if a user, once authenticated is allowed the actions he/she is requesting. Digital Rights Management (DRM) sets this into a more extensive context, where license documents define the rights of a user and functionality interpreting these licences decide, what actions an authenticated user may perform.

Mainly relevant standards from OASIS and W3C are analysed in detail. There is also a special demand for geo-enabled DRM, which includes spatial criteria in defining the rights of a user.

eCommerce

eCommerce standards are mainstream IT standards, which deal with offering, selling, delivering and payment of data or service resources.

These standards, especially payment, are on the edge of interest concerning eMOTION and so only a few standards have been investigated. eMOTION will not generate specifications in this field.

Communication Standards

Communication standards deal with all specifications of the network infrastructure, which effect and support the exchange of information between computational entities in that network.

These standards have been assembled quite thoroughly (but not in extensive depth), particularly because mobile communication is one of the main objectives of eMOTION. Data gathering and integration in eMOTION will primarily use the Internet, and hence the mobile Internet as a communication platform. It has to be evaluated whether this claim can be put into practice on the basis of the standards assembled, which especially include Internet related standards, public wireless network standards, wireless communication protocols and hand-held devices for the end-user.

Other Standards

Under this heading we collected a few quite heterogeneous specifications, which otherwise would use a headline of their own. Main topics are:

Natural language translation:

eMOTION being a design for an ITS data infrastructure in Europe clearly is in need for multi-lingual presentation of data for end-users. The problem is in the data sources, from where often only clear-text material is delivered. This has to be translated into the target language of eMOTION applications, and natural language services can do this. Sadly, there are virtually no usable standards, however there are existing service offerings (SYSTRANLinks) which might be used.

Process chaining and workflow support:



It still has to be evaluated whether eMOTION indeed needs facilities, which allow programmed interconnections to be created between eMOTION services to provide new service functionality. If this turns out to be so, there will be an OASIS standard available (WS BPEL), which can effect this.

Network management

Another need for the eMOTION infrastructure is the necessity that some management will be necessary to keep the network of services going. There is an IETF standard available (SNMP) which helps in achieving the required quality of service in eMOTION.

Analysis of Available Data

This analysis has not been done extensively because it is already available from WP1 and is documented in D1. Only data offerings possibly relevant to the proof-of-concept have been analysed.

1.5 Appendix 1 Overview

The appendix of D5 documents a detailed analysis of selected standards and specifications. The criteria for selection are discussed in the main document.

As has been pointed out above, the close examination was necessary to find out on which existing and emerging standards the eMOTION specification can be based and to ensure semantic closeness to standards, which are possible sources of data for eMOTION.

In order to be able to effectively compare different standards from various domains, it was necessary to decompose the consideration of the standards into small particular facets. Many standards contribute to more than one of these facets.

Analysis of Content Standards

The “Content” chapter views the various standards according to a spectrum of semantic domains. For each of the domains the applicable cut-out of the associated standards and specifications is analysed, with a focus on the object model contained within. This “feature catalogue” is carried out in UML. Additionally, but with less emphasis, existing “encodings” for the content were analysed.

The other criteria applied have been pointed out above in section 1.2 Methodology.

Road Network Data

The specifications analysed are GDF (ISO 14825), the RDS-TMC implied network, the network definition from ISO 19133 (Location Based Services, Tracking and Navigation), and the network definition of the EuroRoadS project, which aimed at the definition of common specifications for the quality assured provision and exchange of road data in Europe and was built on ISO 191xx standards.

The survey of Road Network Data ignored the multitude of road database standards and specifications, which are in use on national and regional levels. This is justified because EuroRoadS provides us with an abstract model comprising all these and the relevant parts of GDF. Moreover, EuroRoadS is built on ISO 191xx including ISO 19133.



These considerations are source for the decision to make eMOTION a “network-independent” specification relying on location referencing alone, as was already pointed out above.

Public Transport Network Data

The following specifications have been analysed:

GDF (which contains a public transport extension based on Transmodel and optionally referencing to the road network), Transmodel, RailML, Rail Journey Information System (RJIS), NaPTAN, and IFOPT.

As it turns out, GDF, NaPTAN and IFOPT use the Transmodel Node (=Point) and Link model, special Points being Stop Points where travellers gain access to the network. IFOPT owns a very refined model of Stop Points. All models (including the railway specifications) assign geographic position to stop points.

Inter-modal Transport Network Data

This chapter presents the method defined in ISO 19133 and ISO 19134 to construct a multi-modal (inter-modal) network out of a series of separately defined single-mode networks. This is contrasted to the way Transmodel and Transmodel derived standards model the transfers between different modes.

Location Referencing

The Location Referencing chapter collects a list of different methods from different standards to describe locations in a network or otherwise on the surface of the earth. Locations can take the form of points, lines or areas.

DATEX 2 owns a flexible location referencing, which can accommodate ALERT-C (RDS-TMC), TPEG-LOC, and coordinate location referencing.

Alert-C relies on precoded locations.

ISO 19133 linear referencing defines point-like locations by referencing linear network elements of a specific network and specifying the arc length from a reference point on the linear geometry, where the referenced location is situated. Additionally a lateral offset may be given.

OGC OpenLS allows description of locations as Addresses, POIs or generalised geometric Positions.

TPEG-Loc supports all the common methods mentioned in ISO LRM 17572. It can provide not only a point position and expansion, but also the language aware textual descriptions of the area.

AGORA-C, designed for dynamic location referencing between client and service map databases from different suppliers. It has the ability to describe Points, Linear locations, Implicit Areas and Explicit Areas.

Traffic Flow Data

In the area of traffic data there is only DATEX 2 as international standardisation



available. DATEX 2 covers all relevant data that are needed by traffic information services.

The Journey Time Database is a standardisation from the UK and covers only a subset of traffic data that also is covered by DATEX 2.

Traffic Messages

The international standards analysed are DATEX 2, RDS-TMC (ALERT-C) and TPEG-RTM. Additionally, SRW (Scheduled Road Works) was investigated, which is a national U.K. specification.

DATEX 2 is based on RDS-TMC (ALERT-C), as is TPEG-RTM. The data contained in SRW is also contained in many of the international standards analysed. Therefore, also in this domain DATEX 2 is subsuming the other standards considered.

Parking

In the area of parking information there are three standardisations DATEX 2, TPEG-PKI and UTMC have been compared. The latter is a national specification from U.K.

DATEX 2 contains some of the dynamic part of parking data, but none of the static parts like fees and opening time. TPEG-PKI will have to be considered once its standardisation is completed. Currently the UTMC standard from the UK provides the most comprehensive data modelling for static and dynamic parking data.

Public Transport Service Data

The following standards and specifications have been analysed for the domain of public transport service data:

o Transmodel

o SIRI

o TransXChange

o RailML

o Rail Journey Information System

o TPEG-PTI

o OTA and FerryXML

The analysis confronts us with a complex picture of different modelling approaches, which still has to be fully investigated and carried over to a harmonised and agreed eMOTION model. Many of the approaches are based on Transmodel.

Most specifications (all except TPEG-PTI) contain Time Tables, at least static ones, though following different approaches. Some standards model fares, though no existing model of fares is expected to be sufficiently comprehensive enough to deal with all situations. TPEG-PTI concentrates on messages regarding events concerning public transport systems.

POI and Other Directories



The following specifications have been considered:

GDF (Theme “Service”), OGC OpenLS POI schema, OASIS Directory Service Standards, POIX, Tourism Markup Language (TourML), IFOPT and NPTG

The collection of standards is rather diverse and ranges from semantic descriptions of “classical” POIs to very general standards, which encode arbitrary directory information. Hierarchical structures, being the basis of gazetteer specifications are also covered.

Road Weather

The standards considered: TLS Standard, Environmental Data (FG3), BUFR and CREX for traffic weather data, road weather related ALERT-C codes, DATEX 2.

TLS and BUFR/CREX describe raw “sensor-data” communication standards which are used as inputs for content operators. There is no elaborated data or added value information contained.

ALERT-C in the framework of RDS-TMC standard covers solely elaborated data and also value added information between content operators and service providers.

DATEX 2 can be used for exchange of elaborated data and information as well as for measured data. It should therefore be the starting point of eMOTION modelling.

Data for Routing

The Data for Routing chapter shall investigate those parts of the specifications which define specific data needed for routing.

Two standards, ISO 19133 and OGC OpenLS Route Service, have been analysed regarding the structures they offer for representing the results of routing or navigation requests, i.e. for the representation of routes.

As it turns out, both models are quite similar, though the OGC OpenLS model does not list ISO 19133 as a contributing input reference. The OGC definition is better suited for transporting the information over a web service environment and should be used as a starting point.

Data for Public Transport Journey Planning

The Data for Public Transport Journey Planning chapter shall investigate those parts of the specifications which define specific data needed for public transport journey planning.

This comprises the representation of transport plans, all data additionally necessary to access the network at origin and destination, and the data necessary to allow distributed journey planning.

The following specifications have been considered: Transmodel, IFOPT, NPTG.

Data for Inter-modal Journey Planning

Only the representation of inter-modal routes by ISO 19134 has been considered.

Data for Freight Traffic

There are no specific standards in the area of freight traffic relevant for the eMOTION



project.

General Metadata

Since no ITS-domain specific metadata has been detected, a general metadata standard has been analysed. The ISO 19115 metadata standard has been chosen, because it fits well into the modelling framework for eMOTION.

Analysis of Encoding Standards

The chapter “Encodings” logically belongs to chapter “Services”. It accommodates the analysis of a few important encodings, which will or may play a role in the eMOTION specification. The chapter is not complete, because most encodings have been deemed part of the services they are using them and were described alongside with these.

Content Encodings

The encoding standard for data modelled in the framework of ISO/TC211 (the ISO 191xx standards) is ISO 19136, also known as Geography Markup Language, GML. The analysis focuses on this single content encoding standard due to its significance in the context of Spatial Data Infrastructures.

Geography Markup Language (GML) is an XML encoding for the transport and storage of geographic information, including both the spatial and non-spatial properties of geographic features.

Presentation Encodings

Presentation encoding standards are an important building block in serving the task of making content available to people. HTML is a typical presentation encoding which is not described in this place, because it is so well known a standard.

The following presentation standards are treated:

SMIL is an authoring language for interactive audiovisual presentations and constitutes a good way to represent multimedia content for example for POIs.

VoiceXML is designed for creating audio dialogs that feature synthesized speech, digitised audio, recognition of spoken and DTMF key input, recording of spoken input, telephony, and mixed initiative conversations.

The Speech Synthesis Markup Language (SSML) is designed to provide a rich, XML-based markup language for assisting the generation of synthetic speech in Web and other applications.

SAMPA, Speech Assessment Methods Phonetic Alphabet and X-SAMPA are computer-readable phonetic scripts based on the International Phonetic Alphabet (IPA).

The Pronunciation Lexicon Specification (PLS) is designed to enable interoperable specification of pronunciation information for both Automatic Speech Recognition (ASR) and Text-To-Speech (TTS) engines within voice browsing applications.



Analysis of Service Standards

The following categories of “Services” have been analysed. For each of the services the criteria “Functionality”, pointing out the overall range of functions the service under considerations performs, and “Interface”, describing the way the service can be invoked have been documented.

See also section 1.2 Methodology.

Application Service

Application service standards have not been found. Web Accessibility standards have been deemed out of scope, because end-user applications are not in the focus of eMOTION.

Data Service

The analysis comprises the OGC specifications Web Feature Service and Web Coverage Service as well as the services of the DATEX 2 and SIRI definition.

The latter two services are basically data services, however, also show some additional functionality like “event service”, because they can register clients and can call them back, in time intervals, or if the data base is changed.

Particularly, the OGC Web Feature Service may be the basic service definition for queryable data delivery in eMOTION.

Mapping Service

Considered are the OGC specifications Web Map Server and Web Map Server with Styled Layer Descriptor.

Both are suitable specifications for the delivery of maps from eMOTION data over the Internet. The Styled Layer variant allows for controlling the styling of the map from the side of the client.

Routing Service

The services described are the ISO 19133 Navigation Service and the OGC OpenLS Route Service.

Especially the OGC Route Service might be a candidate for an associated eMOTION service definition. The interface can also treat public transport journey planning requests and even inter-modal requests.

Public Transport Journey Planning Service

The following standards and specifications are considered: Journey Web, DELFI, OTA Standard (Air), Ferry XML.

JourneyWeb is an extensible protocol for dynamic data exchange over the Internet between multimodal public transport journey planners. It is also an extensive interface against public transport information in general, which means it is also a Data Service.

DELFI is comparable to JourneyWeb. It defines an interface and an implementation



which allow other Journey Planning interfaces to be integrated.

OTA and FerryXML own booking operations, which by their very nature are more complex than the Journey Planning interface proper.

Positioning Service

A Positioning Service provides location information to the user of the service.

The only service definition considered is the OGC OpenLS Gateway Service. The Gateway Service is a network-accessible service that provides the location of one or more mobile terminals.

Directory Service

A Directory Service provides access to an online directory (e.g. Yellow Pages) to find the location of either a specific directory content or one which is closest to a given position.

Two directory service definitions are considered, the OASIS Directory Service and the OGC OpenLS Directory Service. Both are possible candidates for the delivery of POI information, however a data service like the WFS might also be used.

Geocoding Service

Geocoding services translate different forms of geo-referencing into each other, mainly street addresses into coordinates. The reverse process is often called reverse geocoding.

Analysed were the OGC OpenLS Location Utility Service (including both a geocode and reverse geocode) and the OGC Gazetteer Service Profile of the Web Feature Service.

Both standards may be employed for eMOTION, however, eMOTION actually requires a more general model of location translation than is provided by these two specifications.

Coordinate Transformation Service

Coordinate Transformation Services provide an interface to coordinate systems metadata and perform transformations between different coordinate systems.

Just the OGC Web Coordinate Transformation Service has been found in this domain. It can be employed to transform between any coordinate reference system which is to employed in eMOTION.

Registry / Catalogue Service

Registry Services (Catalogue Services) cover the interactions of publishing and finding service and data offerings. They allow publication (registration) and retrieval of metadata like service descriptions, data descriptions, data specifications, application schemas, codelists, thesauri, coordinate reference systems, portrayal rules, symbology and contractual information.

The following service specifications have been documented:

o OASIS ebXML Registry Service and Protocol

o OGC Catalogue Service Specification (CSW)



o OGC Catalogue Service – ebRIM Profile of CSW

o OGC Catalogue Service – ISO 19115/19119 Profile of CSW

Which of the services appears suitable still has to be decided. This will depend on the metadata model to be chosen for eMOTION.

Event Notification Service

Event Notification services are required to realise PUSH-type services. They notify a user or trigger a remote service as soon as some condition occurs. The user or service has to subscribe to such a service and is called back on arrival of the condition. For calling back a user a variety of channels have to be utilised, like email, SMS, telephone, etc. This is because end users are usually not generally web accessible.

Two service definitions have been collected, the OASIS Web Services Notification and OGC Web Notification Service.

Which of the definitions seems appropriate has to be decided.

Digital Rights Management and Security

Under Digital Rights Management (DRM) Services we understand services suited and needed to control all aspects of the use of services and data based on rights and licensing information.

The GeoDRM RM defines the framework for web service mechanisms and rights languages to articulate, manage and protect the rights of all participants in the geographic information marketplace, including the owners of intellectual property and the users who wish to use it.

The eXtensible Access Control Markup Language (XACML) centres around an encoding for expressing security policies regarding any possible resources. There is also an extension to XACML by OGC, called GeoXACML, which adds spatial restrictions to XACML.

Security Assertion Markup Language (SAML) is an XML standard for exchanging Authentication and Authorization data between Security Domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions).

Pricing and Ordering

For openly accessible Web Services registering, retrieving and finding openly accessible web resources (usually by means of a Registry Service), there is also demand for a Web Service which makes an automated pricing, ordering and delivery workflow possible.

The OGC Web Pricing and Ordering Service specification describes a web service which covers all standard geo-eBusiness processes like pricing, ordering and online delivery for spatial products.

Payment and Billing

Two specification are presented, the Austrian standard eps and SEPA. Actually, SEPA



does not exist yet, so the interface cannot be described.

eps (Electronic Payment System) is a simple, safe and free of charge standard of Austrian Banks for e-Commerce and e-Government payments.

The Single Euro Payments Area (SEPA) will be created to give citizens, companies and other economic actors the opportunity to make and receive payments within Europe.

Workflow Support

When a series of automated service invocations has to be combined to accomplish the flow of business processing, Workflow Support Engines may be employed.

From the analysis it has not become clear whether eMOTION has indeed a requirement for Workflow Support or whether automated invocations of services will be performed within Application Service environments.

The OASIS Web Services Business Process Execution Language (WS-BPEL) specifies the common concepts for a business process execution language, if it is needed.

Network Management

As is the case with all distributed services infrastructures, the eMOTION framework is susceptible to the possibility that parts of the network fail or malfunction in unperceived ways.

One standard candidate for support of Network Management is the IETF specification Simple Network Management Protocol (SNMP).

Natural Language Translation

An service infrastructure for traffic information in Europe has necessarily to deal with the issue of multilinguality. There are several solutions to this problem, each of which does not solve the problem entirely.

The main problem is the provision of clear text in the orginal data source. This can only be solved by on-the-fly natural language translation.

Two specifications are considered: The OASIS Translation Web Service, which is a standard to automate the translation and localization process as a Web service, and a proprietary solution offered by SYSTRAN, the SYSTRANLinks translation service.

Analysis of Communication Standards

The standards treated in the “Communication and Network” chapter do not overlap with the road and traffic oriented domains of eMOTION. The analysis of these standards has been done in anticipation of the Engineering Viewpoint of the specification in D6.

The analysis has used the following structure. It will allow comparison of the particular standards and evaluate their usefulness for the eMOTION infrastructure definition.

Internet Communication Standards

The Internet protocol suite is a collection of network protocols implementing the stack



that constitutes the basic “building blocks” for the Internet.

The following standards are outlined in brief: HTTP, HTTPS, SSL/TLS, SSH, DNS, SMTP/POP3/IMAP, FTP, TCP, UDP, IPv4/IPv6/Ipsec, SOAP.

Public Wireless Networks

The following Public Wireless Networks are treated: GSM/GPRS/EDGE/UMTS.

The standards themselves, service throughput, cell radius, coverage and capacity, mobility aspects and application protocols are discussed.

IMS

IP Multimedia Subsystem is a system consisting of a telecommunication IP network with an innovative call/session control layer.

A general description and the architecture of the system are presented. Aspects of Quality of Service are discussed along with Security and Cost Charging. Additionally possible applications are discussed.

WiMAX

WiMAX (Worldwide interoperability for Microwave Access) is today the user-friendly name associated with IEEE 802.16a/REVd/ e standards.

The target of the on-going standardisation process is to achieve a cost effective broadband radio access solution in a planned evolution to low speed mobility and to taking benefit of interoperability and higher economy of scale through standardization.

The issue is pointed out by discussion performance, services and the interworking with the mobile network, both in a short term and long term scenario.

Wireless Communication Protocols

This section discusses technical questions regarding the migration from IPv4 to IPv6 in mobile network settings.

Hand-Held Devices and User Terminals

This section gives an overview over J2ME and SyncML.

Java 2 Platform Micro Edition (J2ME) constitutes a collection of Java APIs for the development of software on PDAs, cell phones and other consumer appliances.

Synchronisation Markup Language (SyncML) is an open platform-independent information synchronisation standard for wireless devices.



2. Standardisation Bodies

2.1 International Organization for Standardization (ISO) / TC 204

ISO (International Organization for Standardization) is a network of national standards institutes. One technical committee of ISO is ISO/TC 204.

The scope of ISO/TC 204 is the standardization of information, communication and control systems in the field of urban and rural surface transportation, including intermodal and multimodal aspects thereof, traveller information, traffic management, public transport, commercial transport, emergency services and commercial services in the intelligent transport systems (ITS) field.

ISO/TC 204 is responsible for the overall system aspects and infrastructure aspects of intelligent transport systems (ITS), as well as the coordination of the overall ISO work program in this field including the schedule for standards development, taking into account the work of existing international standardization bodies.

An overview of standards published by ISO/TC 204 is available at http://www.iso.org/iso/en/stdsdevelopment/tc/tclist/TechnicalCommitteeStandardsListPage.TechnicalCommitteeStandardsList?COMMID=4559

You can order ISO Standards at http://www.iso.org/ or at national standardisation bodies.

2.2 International Organization for Standardization (ISO) / TC 211

ISO (International Organization for Standardization) is a network of national standards institutes. One technical committee of ISO is ISO/TC 211.

The scope of ISO/TC 211 is the standardization in the field of digital geographic information. ISO/TC 211 is responsible for ISO geo-related standards, expressed in the ISO 191xx series. These standards all have a wide technical scope, i.e. they are dealing with spatial information in general, not just features regarding roads and mobility. The ISO 191xx standards are currently employed as the architectural basis in widespread efforts to establish Spatial Data Infrastructures (SDIs).

An overview of standards published by ISO/TC 211 is available at http://www.iso.org/iso/en/stdsdevelopment/tc/tclist/TechnicalCommitteeStandardsListPage.TechnicalCommitteeStandardsList?COMMID=4637

You can order ISO Standards at http://www.iso.org/ or at national standardisation bodies.

2.3 European Committee for Standardization (CEN)

CEN, the European Committee for Standardization, has membership consisting of the National Standards Bodies of the 27 European Union countries plus the National Standards Bodies of European Free Trade Area countries.

CEN contributes to the objectives of the European Union and European Economic Area with



voluntary technical standards which promote free trade, the safety of workers and consumers, interoperability of networks, environmental protection, exploitation of research and development programmes, and public procurement.

CEN's products are the European Standards (ENs), which can be bought from their National Members. An overview of CEN standards is avaiable at the On-line Catalogue of European Standards http://www.cen.eu/catweb/cwen.htm

2.4 World Wide Web Consortium (W3C)

The World Wide Web Consortium (W3C) is an international consortium where Member organizations, a full-time staff, and the public work together to develop Web standards. W3C produces Web standards called "W3C Recommendations." A W3C Recommendation is the equivalent of a Web standard, indicating that this W3C-developed specification is stable, contributes to Web interoperability, and has been reviewed by the W3C Membership, who favor its adoption by the industry.

An overview of recommendations and other technical reports published by the W3C are avaiable at http://www.w3.org/TR/

2.5 Organization for the Advancement of Structured Information Standards (OASIS)

OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards. The consortium produces Web services standards for security, e-business, and standardization efforts in the public sector and for application-specific markets. Founded in 1993, OASIS has more than 5,000 participants representing over 600 organizations and individual members in 100 countries.

More information concerning OASIS is possible to obtain at www.oasis-open.org, an overview of standards published by OASIS is available at http://www.oasis-open.org/specs/index.php.

2.6 Open Geospatial Consortium (OGC)

The Open Geospatial Consortium, Inc (OGC) is an international industry consortium of commercial, governmental, nonprofit and research organizations, participating in a consensus process to develop publicly available interface specifications. These OpenGIS® Specifications support interoperable solutions that "geo-enable" the Web, wireless and location-based services, and mainstream IT.

The OGC has a close relationship with ISO/TC 211 (see 2.2). The OGC abstract specification is being progressively replaced by volumes from the ISO 191xx series under development by this committee.

An overview of OpenGIS® Specifications is available at http://www.opengeospatial.org/standards



3. Domain Specific Standards

3.1 Private Traffic Information

3.1.1 DATEX

DATEX is the predecessor of DATEX 2, which is described in subsection 3.1.2.

Information is available at http://www.datex2.eu/

Relevance

With DATEX 2 the importance of DATEX will decrease even though DATEX is a European pre-standard. Because of this it is not described in detail.

3.1.2 DATEX 2

The development of the first DATEX standard started in 1997. The standardisation process was initialised by DG TREN and started with the European projects TRIDENT (TRansport Intermodality Data sharing and Exchange NeTworks) and COURIER (Cross-border Organisation & User Requirements for Information Exchange Review).

DATEX is a traffic and travel data exchange mechanism, designed and developed by a European task force set up to standardise the interface between inter-regional Traffic Control Centres.

Because DATEX has some disadvantages1 the DATEX 2 development was started. In 2003, the European commission launched the evolution of the DATEX technical specifications. The project “D2 evolving DATEX” has driven the evolution of the DATEX specifications to meet new technical and user needs and to help further deliver transport policy.

The current version DATEX 2 v1.0 can be obtained via http://www.datex2.eu/?q=node/21, standard documents are [DATEX 2 EC, 2005], [DATEX 2 EC, 2006a], [DATEX 2 EC, 2006b], [DATEX 2 EC, 2006c] and [DATEX 2 TC, 2006].

Relevance

The main aim of DATEX 2 is to establish standardised links between Road Operators, TICs and Service Providers to allow the easy and efficient communication of traffic and traveller Information.

1 DATEX-Net is not an open communications standard as it only allows interoperability between compatible DATEX-Net systems; DATEX-Net is based on EDIFACT messages, which are text based and are therefore an inefficient means of communication; DATEX is a procedural standard, not an "object orientated" approach; DATEX adopts point to point communications that can be expensive and inefficient.



DATEX 2 provides up to date and easy to use technology to exchange data, with a scalable set of interoperable profiles. The DATEX 2 approach defines a clear set of rules - the UML profile - and how to use UML to model DATEX data. The exchange of XML messages encoded according to the DATEX 2 specifications is preferably implemented on top of standard Internet protocols.

The core data model of DATEX 2 (named “Level A”) includes an extensive data model, that will be suitable for most data exchange scenarios. It covers traffic and travel related information. DATEX 2 provides a lot of possibilities to create traffic messages that describe any information that should be given to the road user in case of traffic disturbance. In addition it is possible to give information about weather conditions and recommendation for the behaviour of the road user related to environmental and weather conditions. In the area of parking information there is only small relevance of DATEX 2.

One part of DATEX 2 is the description of the location the information is provided for. DATEX 2 uses different established methods for location referencing like Alert-C, TPEG-LOC or localisation by coordinates.

DATEX 2 addresses a variety of needs with different data exchange profiles: The Regular Profile offers rich functionality based on the Web Services family of protocol standards, whereas the Low Cost Profile establishes a minimum interface being capable of carrying the full DATEX content while at the same time requiring minimum Internet access features.

The use of UML, XML and HTTP and web services as well as the well defined data dictionary provide a lot of potential for the use of DATEX 2 in the eMOTION framework. Although DATEX 2 isn’t yet a European standard it will be developed to a European standard for traffic data exchange. The Level A data model should be the basic for eMOTION services.

A deeper presentation of the standard is available in Appendix 1 at

- subsection 2.4.1 (Location Referencing)

- subsection 2.5.1 (Traffic Flow Data)

- subsection 2.6.1 (Traffic Messages)

- subsection 2.7.1 (Parking)

- subsection 2.10.4 (Weather Data)

- subsection 4.2.3 (Datex 2 Data Sservice)

3.1.3 EuroRoadS - Road Network Information Model

EuroRoadS was a project aiming at the definition of common specifications for the quality assured provision and exchange of road data. It was funded by the EU eContent programme and ended in autumn 2006.

The deliverables of the EuroRoadS project (e.g. the final specification [Euroroads, 2006]) can be obtained via:



http://www.euroroads.org/php/documents.php

This analysis makes use of Deliverable D6.3 “Road Network Information Model”. It is publicly available.

Relevance

The vision of the EuroRoadS-project was:

• to establish a European-wide public road data infrastructure delivering access, through a single portal, to harmonised and quality assured road information for multipurpose use. (But not to create a European road database.).

• that EuroRoadS-compliant national road databases will cover the EU25+ by the end of 2012.

• that the European Directive establishing an infrastructure for spatial information in the European Community (INSPIRE) will, for the European road network, be based on the EuroRoadS specifications and other results.

This points very much into the direction of the eMOTION project, which aims at creating a harmonised model of road and traffic related data, which it will make available in a way compliant to SDIs and especially INSPIRE. EuroRoadS is also based on the ISO TC211 framework of “geo-standards”. It defines GML as its encoding for data exchange.

There is a good chance that the findings of EuroRoadS and eMOTION are complementary.

A deeper presentation of the standard is available in Appendix 1 at subsection 2.1.3.

3.1.4 Global System for Telematics: Enhanced Floating Car Data (GST: EFCD)

GST (Global System for Telematics) is an EU-funded Integrated Project that created an open and standardized end-to-end architecture for automotive telematics services. Enhanced Floating Car Data (EFCD) is part of the GST and developed an open system for FCD, making it possible that vehicles equipped with advanced sensors yield information that is processed and transferred to a service centre.

Information is available at http://www.gstforum.org/en/7_sub-projects/ enhanced_floating_car_data_efcd/

Relevance

EFCD is not described in detail because back-channel information has been defined to be out of scope for eMOTION.

3.1.5 Highways Agency Pavement Management System (HAPMS)

The Highways Agency Pavement Management System (HAPMS) is a UK national database which stores the current condition of the network’s road surfaces and pavements.

Information is available at



http://www.highways.gov.uk/aboutus/documents/ha_ann_rpt_2001_2002.pdf [TSO, 2003]

Relevance

HAPMS is not described in detail because it covers asset management and maintenance, so it is out of scope for eMOTION. Only the definition of the HAPMS network is covered within the description of Scheduled Road Works (SRW), see subsection 3.1.16.

3.1.6 Intelligent roads (INTRO)

INTRO (Intelligent roads) is a research project supported by the European Commission with the aim of developing innovative methods for increased capacity and safety of the road network. This combines sensing technologies and local databases with real-time networking technologies. Information is available at http://intro.fehrl.org/

Relevance

The project examines back-channel informations which are out of scope for eMOTION.

3.1.7 ISO 14819: Radio Data System - Traffic Message Channel (RDS-TMC)

RDS-TMC is the acronym for Radio Data System - Traffic Message Channel. RDS is a standard from the European Broadcasting Union for sending small amounts of digital information using FM radio broadcasts. There are several different types of information which can be transmitted by RDS. One of them is the TMC. It is used to deliver traffic and travel information to the drivers.

A radio needs a special RDS-TMC decoder to announce the correct message for the driver on the radio display. Navigation systems are also prepared to receive RDS-TMC information and use it for better trip planning.

The messages are coded using the Alert-C protocol. Alert-C was a major product of the DRIVE Project V1029 (“RDS Advice and Problem Location for European Road Traffic”), which had the aim to standardize RDS-TMC throughout Europe.

The international standard ISO 14819 is the main standard for traffic and travel information. It consists of several parts which define how to create a correct RDS-TMC message. The first part ISO 14819-1 defines generally how to code a RDS-TMC message using in Alert-C protocol ([ISO 14819-1, 2003]). The second part, ISO 14819-2, defines all possible events used in such a message ([ISO 14819-2, 2003]). And the third part, ISO 14819-3, defines how a correct location table has to be set up ([ISO 14819-3, 2004]). Finally ISO 14819-6 contains information how to encrypt RDS-TMC messages and how to provide conditional access to RDS-TMC messages ([ISO 14819-6, 2006]).

The standard is available at ISO and all local organizations in every country which are members of the ISO organization. Translations for the CEN – English are available at the TMC forum’s web site at www.tmcforum.com.



Relevance

As the RDS-TMC solution is widely employed across Europe to provide dynamic traffic and travel information it is essential to incorporate RDS-TMC’s standards into the eMOTION standards’ analysis.


- subsection 2.1.4 (Road Network)



- subsection 2.10.3 (Road Weather)

3.1.8 ISO 18234 / ISO 24530: Transport Protocol Experts Group (TPEG) Standards

The Transport Protocol Experts Group (TPEG) is a group of experts led by the European Broadcasting Union. This group developed the TPEG specifications for transmission of language independent multi-modal Traffic and Travel Information.

The result of these specifications are the ISO standards 18234 and 24530: the ISO/TS 18234 series specifies a binary format to exchange traffic and travel informations, ISO/TS 24530 (tpegML) covers the data exchange in XML format.

TPEG standards cover the following areas:

- A unified location referencing system suitable for use by all TPEG applications is described with TPEG-LOC in ISO/TS 18234-6:2006 and ISO/TS 24530-2:2006 (tpeg-locML) ([ISO 18234-6, 2006], [ISO 24530-2, 2006]).

- ISO/TS 18234-4:2006 and ISO/TS 24530-3:2006 (tpeg-rtmML) establish the method of delivering Road Traffic Messages within a TPEG service ([ISO 18234-4, 2006], [ISO 24530-3, 2006]).

- The standards for the exchange of parking information are under development. These are ISO/NP TS 18234-7 and ISO/NP TS 24530-5 (tpeg-pkiML) ([ISO 18234-7, 2007], [ISO 24530-5, 2007]).

- ISO/TS 18234-5:2006 and ISO/TS 24530-4:2006 (tpeg-ptiML) establish the method of Public Transport Information delivery within a TPEG service ([ISO 18234-5, 2006], [ISO 24530-4, 2006]).

Relevance

TPEG Applications currently include road traffic messages and public transport messages, but in future are likely to include parking information, congestion and travel time information, and weather information.

TPEG-LOC allows the service provider to give to human end users an impression of where



an event has taken place, even where they may not be familiar with the location. This is achieved in a language independent way by the use of TPEG-LOC tables (using language independent dictionaries).

The TPEG-RTM application is designed to allow the efficient and language independent delivery of road information directly from service provider to end-users. The information provided relates to event and some status information on the road network and on associated infrastructure affecting a road journey.

TPEG-PTI is intended to cover all modes of public (i.e. collective) transport as well as inter-urban and intra-urban travel. It is designed to allow the efficient and language independent delivery of public transport information directly from service provider to end-users.

Standards from the TPEG family are widely used in Europe, so the need of incorporation of thse standards into the eMOTION framework is evident. Another meeting point of this standard and eMOTION framework, which is possible to identify, lies in the TPEG-LOC’s ability to provide positional information using WGS84.




- subsection 2.7.2 (Parking)

- subsection 2.8.6 (Public Transport Service Data)

3.1.9 Integrated Transport Network Layer (ITN)

Ordnance Survey MasterMap is a digital representation of the real world containing more than 450 million uniquely identified geographic features in the UK. It is available in five data layers, one of them is the Integrated Transport Network Layer (ITN), which is a a geographic reference layer for Great Britain’s road infrastructure.

Information is available at http://www.ordnancesurvey.co.uk/oswebsite/products/osmastermap/layers/itn/

Relevance

eMOTION will be concentrating on network referencing technology and not on networks. Because of this ITN is not described in detail.

3.1.10 Journey Time Database (JTDB)

Recognising the potential benefits for data management, the Highways Agency, Englands highway authority, commissioned a research and development project to identify and test a suitable registry structure and mechanism that meets the needs of the Agency and other



organisations, specifically for Travel Information Highway (TIH), but with the possibility of extension to the wider ITS sector.

The Journey Time Database is part of this registry an can be visited on web site: (http://www.itsregistry.org.uk/content/_3291048e_1100177597830_416785_0_Index.html).

Relevance

The Highways Agency Journey Time Database provides journey time information for each 15-minute interval throughout the year for road links between junctions on the Highways Agency core network. Journey time data from a range of data sources are merged and the journey times are used to generate a road timetable for all days of the year. This sort of information should be considered within the eMOTION framework.


3.1.11 Code of Practice for Traffic Control and Information Systems (MCH1869)

MCH1869 is a Code of practice defined by the UK Highways Agency that applies to roadside systems that convey instructions or information to road users by signal control, variable signs/symbols.

Information is available at http://www.transportdirect.gov.uk/research/pdf/scfd06.pdf

Relevance

MCH 1869 covers the maintenance of traffic control and information systems, so it is out of scope for eMOTION and it is not described in detail.

3.1.12 Open Travel data Access Protocol (OTAP)

The Open Travel data Access Protocol (OTAP) allows service providers to easily and cost effectively access the real time traffic data held in the databases of road operators, traffic information centres and other content providers.

Information is available at http://www.itsproj.com/otap/ .

Relevance

With DATEX 2 there will be no further development of OTAP, so it is not described in detail.

3.1.13 Realizing Enhanced Safety and Efficiency in European Road Transport (REACT)

The REACT project (Realizing Enhanced Safety and Efficiency in European Road Transport) aims at optimizing road safety and the flow of traffic. It is based on advanced functionalities



on board the vehicles themselves and centralised resources organised around analytical models that predict the traffic in a given region.

Information is available at http://www.react-project.org/ and http://www.intempora.com/ENG/references/react.php?nav1=ref&nav2=proj

Relevance

REACT is a back-channel project and so it is not described in detail.

3.1.14 Safety Standards For In-Vehicle Information Systems

Safety standards are described in a publication named 'Development of Safety Principles for In-vehicle Information and Communications Systems'. It provides a detailed account of UK and European standardisation within this area.

Information is available at http://www.esafetysupport.org/download/working_groups/30.pdf ([TRL, 2000]).

Relevance

This area is out of scope for eMOTION. Because of this it is not described in detail.

3.1.15 Street events Data Exchange Protocol (SDEP)

Street events Data Exchange Protocol (SDEP) comprises an XML data schema and web service WSDL for exchanging streetworks and street events data between systems.

The specification [SDEP, 2006] is available at http://www.govtalk.gov.uk/schemasstandards/schemalibrary_schema.asp?schemaid=254 .

Relevance

SDEP is for the communication between local authorities to coordinate roadworks. This is out of scope for eMOTION and it is not described in detail.

3.1.16 Scheduled Road Works (SRW)

Scheduled road work data are part of the pavement management system of the Highway Agency in the UK (HAPMS). The HAPMS is used to manage the pavement assets based on data about pavement conditions, traffic data and roadwork planning data. The data about scheduled roadwoks are used in the TCC to identify key disruption due to planned events (maintanence events) in advance.

Information is available at http://www.hm-treasury.gov.uk/documents/public_spending_reporting/public_service_performance/psr_psp_actionha.cfm and http://www.itsregistry.org.uk/content/_9_5_1_3291048e_1142853280996_729104_27Report.html



Relevance

Information about road works are a essential part of traffic information services. The root of road work information is a road work (pavement) management system. These systems are able to provide detailed raod work data that e.g. can be use by service operators to generate traffic forecasts for road works. The data model of “Scheduled Road Works” is part of the ITS Metadata Registry in the UK2. Because of the relevance of road works for information services, the data model is relvant for eMOTION.


3.1.17 Traffic Info Centre XML-based Data Model (TICXML )

TIC – Traffic Info Centre is a software package for creating, receiving, editing, distributing and improving traffic and travel information. TICXML is a proprietary XML-based data model to communicate traffic messages according to DATEX data dictionary.

Information is available at http://www.gewi.com/data/tic/overview/start.htm

Relevance

TICXML is not described in detail because it is a proprietary data model with minor relevance.

3.1.18 Travel Information Highway (TIH)

The Travel Information Highway (TIH) is an open and independent association of information publishers and receivers in the UK who have an interest in exchanging real-time travel information using an agreed set of TIH Principles. The objective of the TIH is the widespread exchange of travel information through the use of common standards and best practice for the public-sector and commercial interests.

Information is available at http://www.ha-research.gov.uk/projects/index.php?id=597 and http://members.traffic-wales.com/courier/sys_tih.html

Relevance

TIH does not specify new standards but TIH principals for services to be compliant with TIH. TIH recommends the use of standards like DATEX2 or SIRI for data dictionary or service interfaces, so TIH principles are not described in detail.

2 The Registry is a repository of data definitions and data models, with an associated supporting process for improvement of quality and for harmonisation across different systems. The registry aims to cut across work in isolated "silos" and avoid re-invention and duplication of effort.



3.1.19 TrafficML

TrafficML is an advanced XML data feed that leverages the Traffic.com Traffic Information Management System (TIMS) for data processing and multi-platform services dissemination. Traffic.com offers consumers real-time customized traffic reports in 83 U.S. markets.

Information is available at http://corporate.traffic.com/news/press_releases/Release_TrafficProTrafficML_Launch_12_19_06.htm

Relevance

TrafficML has no relevance in Europe, so it is not described in detail.

3.1.20 XML Schemas for Exchange of Transportation Data (TransXML)

TransXML: XML Schemas for Exchange of Transportation Data examines a proposed common framework for exchange of transportation data in eXtensible Markup Language, which is defined by the US Transportation Research Board.

Information is available at http://www.trb.org/news/blurb_detail.asp?id=7338.

Relevance

TransXML is relevant to authorities exchanging construction plans, and it has relevance in the US. Therefore it is not described in detail.

3.1.21 TRansport Intermodality Data sharing and Exchange NeTwork (TRIDENT)

TRIDENT (TRansport Intermodality Data sharing and Exchange NeTwork) was a research project with the goal to support multimodal travel ITS services by establishing common and reusable mechanisms that enable sharing and exchanging data between transport operators (content owners) of different modes as well as information service providers.

Information is available at http://www.ertico.com/en/activities/activities/trident_website.htm

Relevance

Output of TRIDENT is DATEX (DATEX 2 is covered in subsection 3.1.2), so it is not described in detail.

3.1.22 UTMC Standard - TS004: Car Park Monitor MIB

The Urban Traffic Management and Control (UTMC) programme is the UK Department for Transport (DfT) main initiative for the development of a more open approach to Intelligent Transport Systems (ITS) in urban areas. It is divided into the two main parts where the first one deals with the general UTMC specification (TS003 specifies a framework of applicable standards) ([DfT-UTMC TS003, 2005]). Second one’s focus (TS004) is placed on the UTMC Management Information Bases (MIBs) and data objects definitions ([DfT-UTMC TS004,



2007]).

TS004 provides standards for UTMC “common data” (ie data communicated between applications of a UTMC system, or between a UTMC system and an external system) through holding definitions of current UTMC Data Objects and session management protocols, and making them available to users. This common data specification covers not only Car Park Monitoring but also MIBs like Air Quality Monitor, VMS and many others.

A new UTMC system should normally use the currently registered UTMC Data Objects and session management protocols as far as they are applicable. Where local needs require the development of new Data Objects and session management protocols, these should normally be submitted for approval to the Registry. This will ensure that any potential overlaps (for example with Data Objects currently under review for registration) are identified.

Full UTMC specification is possible to obtain via www.utmc.uk.com. The latest version of the TS004 specification is TS004.003:2007 .

Relevance

Although the UTMC standard is of national coverage it should be captured by the eMOTION framework. The reason for this decision is even more supported by the fact that UK is quite a strong player in the ITS development area. The large number of UK’s public transport, car park and other ITS services which are currently in operation make a strong argument for incorporation of this standard into eMOTION in this way.


3.1.23 Video Information Highway (VIH)

The Video Information Highway (VIH) is a service by the UK Highways Agency providing access to CCTV images in the Bristol area.

Information is available at http://tempo.austriatech.org/fileadmin/library/72/EEG_ST2_Video_Information_Highway.pdf.

Relevance

VIH has only local relevance, so it is not described in detail.

3.2 Public Transportation Information

3.2.1 EU-Spirit

EU-Spirit is a European travel information system offering the calculation of door to door travel itineraries between European cities or regional areas.

Information is available at http://www.eu-spirit.com/



Relevance

EU-Spirit will be covered in the description of DELFI, so it is not described in detail.

3.2.2 FareXChange

FareXChange is a proposed protocol for structuring and then exchanging fares information in all its complexity in the UK. It is planned by Transport Direct. There is currently no indication when this might be completed.

Information is available at http://www.dft.gov.uk/pgr/regional/ltp/accessibility/developing/research/analysisofcostfactorsforacce3616

Relevance

FareXChange has no relevance for eMOTION because it is not at a sufficient state of development to provide useful input .

3.2.3 International Air Transport Association (IATA) Standards

The International Air Transport Association (IATA) is an international trade body, which represents many airlines and which also represents, leads and serves the airline industry in general. IATA develops standards within a number of functional areas, e.g. PADIS (Passenger and Airport Data Interchange Standards), which aims at the development of messages in the Reservations, Electronic Ticketing, and Airport Services functional areas, or SSIM (Standard Schedules Information Manual), which establish a set of common standards for external exchanges.

Information is available at http://www.iata.org/whatwedo/policies_regulations/standards

Relevance

IATA provides several standards very close to the requirements of airlines and airports and so they are not useful for the eMOTION scope. Against this OTA provides data related to the passenger, this is described in subsection 3.5.10.

3.2.4 Identification of Fixed Objects in Public Transport (IFOPT)

IFOPT is described in Standardisation CEN, prCEN TS 278207 Public transport – Identification of Fixed Objects in Public Transport (IFOPT) [CEN-IFOPT, 2007].

Currently status is draft only for technical committee review. Latest details on status may be found on the CEN Road Transport and Traffic Telematics Technical Committee website found at http://www.nen.nl/cen278/, or on the CEN website at

http://www.cen.eu/cenorm/businessdomains/businessdomains/isss/activity/intelligent+transport.asp

The most recent draft may be found through the NaPTAN site, http://www.naptan.org.uk/



Relevance

IFOPT defines a model and identification principles for the main fixed objects related to public access to Public Transport (e.g. stop points, stop areas, stations, connection links, entrances, etc.). Such information is important for tasks such as multimodal journey planning, allowing trip start, trip end and interchange information to be exchanged or interrogated. The standard is suitable for describing public transport access points including, but not limited to railway stations, airports, on street bus and tram stops, hail and ride zones, taxi ranks and ferry terminals. While the model is based on the TransModel standard, it defines further objects required to describe accessible paths within and between public transport Stop Points, for example allowing description of particular accessibility issues associated with public transport interchanges. Because of this it has relevance for the eMOTION framework.

The standard defines four connected submodels:

• Stop Place Model – Network, Mode, Stop, Stop Area, Stop Point, Path Link

• Gazetteer/Topographical Model – Locality, Hierarchy

• POI Model – POI Classification, POI Hierarchy, POI Geometry.

• Administrative Area Model

Only the Stop Place model is the mandatory part of the standard, with other models being optional.


- subsection 2.2.6 (PT Network Data)

- subsection 2.3.3 (Inter-modal Transport Network Data)

- subsection 2.9.6 (POI)

- subsection 2.12.2 (Data For Public Transport Journey Planning)

3.2.5 Intelligent Integration of Railway systems (InteGRail)

The InteGRail research project aims to create a holistic, coherent information system, integrating the major railway sub-systems, in order to achieve higher levels of performance of the railway system in terms of capacity, average speed and punctuality, safety and the optimised usage of resources.

Information is available at http://www.integrail.info/

Relevance

InteGRail is specific for railway companies. Therefore it is not described in detail.



3.2.6 National Public Transport Access Node Database / National Public Transport Gazetteer (NaPTAN / NPTG)

NaPTAN is a UK national standard supported by the UK Department for Transport, used for the National Public Transport Access Node database, and forms part of the UK’s GovTalk eGovernment Initiative. The latest version, 2.1 was released in September 2005. The standard may be accessed from the website http://www.naptan.org.uk.

The National Public Transport Gazetteer (NPTG) provides a topographic database of towns and settlements in the UK. The data and schema are maintained for the UK Department for Transport. Detailed information on NPTG may be found at http://www.nptg.org.uk/.

The standards are described together in the NPTG and NaPTAN Schema Guide [DfT-NaPTAN, 2005], available from the NaPTAN website.

Relevance

NaPTAN provides a unique identifier for every point of access to public transport in the UK, together with systematic meaningful text descriptions of the stop point and its location, allowing their unambiguous discovery and reference. Stops can be related to topographic regions via NPTG.

NPTG provides a unique identifier for every town and settlement in the UK to and from which passengers might want to travel, together with meaningful text descriptions, allowing their unambiguous discovery and reference.

An XML schema and CSV file format are specified for exchange of NaPTAN data and NPTG localities. NaPTAN and NPTG are used by a number of other UK standards, so because of its relevance in the UK they should be considered in eMOTION.


- subsection 2.2.5 (NaPTAN - PT Network Data)

- subsection 2.9.7 (NPTG – POI and Other Directories)

- subsection 2.12.3 (NPTG - Data for PT Journey Planning)

3.2.7 PlusBus

PlusBus is a UK specific scheme for extending rail ticket use to local buses, described in NaPTAN/NPTG.

Information is available at http://www.plusbus.org.uk/

Relevance

PlusBus is covered with NaPTAN/NPTG, so it is not described in detail.



3.2.8 PubTrans

PubTrans is a platform that provides transport organisations with the opportunity to improve customer information, transport management and the integration of different systems from multiple suppliers. It is used by some public transport authorities in Scandinavia.

Information is available at http://www.hogia.com/p1838/p1838_eng.php

Relevance

PubTrans has only regional usage in Scandinavia, and there is no public interface available. So it is not described in detail.

3.2.9 Rail Journey Information System (RJIS)

The RJIS Datafeeds Interface Specification for Timetable Information describes the extraction format for exchange of data with the UK Rail Journey Information System.

RJIS is maintained by the UK Association of Train Operating Companies, ATOC. Standards may be accessed from their website at:

http://www.atoc.org/rsp/Data_Feeds/01_Types_of_Data.asp

Relevance

RJIS provides data for scheduled passenger rail services like fares data, timetable data and routing guide data. Also available are so-called fixed leg records, which describe links between public transport access points without fixed timetable information. RJIS is used by train companies within the UK, so it has relevance in the context of the eMOTION framework. It will, however, due to its legacy exchange formats probably be replaced by something fundamentally different within a few years. It is conceivable that this might be based on the UK TransXChange standard.




- subsection 2.8.5 (PT Service Data)

3.2.10 Railway Markup Language (RailML®)

RailML.org is a development partnership of independent businesses and institutions. An organization can participate in the railML Initiative as either a supporting partner or as a development partner. Supporting partners receive - in accordance with the licensing conditions - the right to use the railML schemas. Also, the web site contains a link to each supporting partner. An organization can further enhance its participation and become not just a supporting partner, but also a development partner. As a development partner, an



organization can participate in the creation and further development of the railML schemas by bringing proposals and comments into the development process.

One goal of railML is to designate the totality of all XML schemas that have been written for railway data, including of all the individual formats. At the moment the subschemas Timetable ([RAILML, 2004]), Rollingstock and Infrastructure are available.

For more information see http://www.railml.org/

Relevance

RailML is designed for data exchange between rail operators and the focus is the operation of trains. Information about the infrastructure, the equipment and services of the rolling stock and the timetable is also necessary for travel information systems. The RailML is used by important European rail operators and is part of daily business. With this it is relevant in the context of the eMOTION framework.




3.2.11 Real Time Information Group: Bus Management Standards - RTIGT021

The Real Time Information Group (RTIG) is a group of local authorities and bus operators in the UK. Amongst other things they develop standards at UK and European levels. One of these standards is RTIGT021, which describes a common TransXChange export format specification for use with bus RTI systems

Information is available in the library catalogue which can be found at

http://www.rtig.org.uk/downloads.htm

Relevance

RTIGT021 is subsumed by TransXChange, so it is not described in detail.

3.2.12 Real Time Interest Group XML (RTIG-XML)

RTIG-XML is an XML protocol to allow distributed computers to exchange real-time information about buses. The protocol is a UK standard sponsored by the UK Real Time Interest Group. RTIG-XML 2.0 is the UK implementation of the CEN European SIRI standard.

Information is available at http://www.kizoom.com/standards/rtigxml/index.htm

Relevance

As noted above RTIG-XML is covered with SIRI, so it is not described in detail.



3.2.13 Service Interface for Real Time Information (SIRI)

The Service Interface for Real Time Information (SIRI) specifies a European interface standard for exchanging information about the planned, current or projected performance of real-time public transport operations between different computer systems.

SIRI has been built by a European consortium of equipment suppliers, transport authorities, transport operators and transport consultants from CZ, D, DK, F, NO, SE and the UK with the backing of VDV in Germany, the Direction des Transports Terrestres of the French Ministry for Transport, and RTIG in the UK, and builds on the work of the EU Trident project. The workgroup was convened by CEN TC278 WG3, it was organised by VDV (D) with editorship provided by RTIG (UK) and Transmodel expertise from France.

Relevance

SIRI represents a modularised set of discrete functional services for operating public transport information systems. It covers planned and real time timetable exchange, information about vehicle activity which can be used to guarantee reliable connections at stops.

The aim of SIRI was the inclusion of the best elements of various national and proprietary standards in Europe. It was realized using an XML schema, TransModel terminology and modelling concepts.

The SIRI services shall be provided over a standardised Communications layer, based on a Web Services Architecture which allows all the functional services for Security, Authentication, Version Negotiation, Recovery/Restart, and Access Control/Filtering. Both, an immediate Request/Response architecture; and an asynchronous Publish/Subscribe protocol are intended for implementation. The modularized approach allows the implementation of only a subset of services actually required.

The mentioned descriptions of the SIRI interfaces, functions and functional services are thought to serve as an overview of the key features relevant to eMOTION and does not suite as exhaustive list of definitions. More detailed information can be obtained from the SIRI Website (www.siri.org.uk).


- subsection 2.8.2 (Public Transport Service Data)

- subsection 4.2.4 (Data Service)

3.2.14 ENV 12896: Transmodel

Transmodel version 5.1 standardizes the definition and modeling of relevant Public Transport related data aiming to build a reference for the variety of applications and systems in this domain ([TRANSMODEL, 2001]). A few examples are on-street and in-vehicle systems delivering information for passengers, web-based services for trip planning, booking,



information etc. or systems run by PT operators such as planning and scheduling systems; driver and vehicle rostering; fares management, AVM systems etc.

Subdomains included in Transmodel are:

- Network description

- Versions, validity and layers

- Tactical planning components

- Vehicle scheduling

- Driver scheduling

- Schedules and versions

- Rostering

- Personnel disposition

- Operations monitoring and control

- Passenger information

- Fare collection

- Management information

- Multi-modal operation in public transport

- Multiple operators' environment

The website of Transmodel is available at http://www.transmodel.org/

Relevance

The Transmodel European data model provides a good and wide reference for the support of: a detailed and structured documentation for the information needs of a PT company, the development of systems and processes related to passenger information and transportation services, the design of software applications supporting and implementing these services and processes, the management and organisation of systems and information in environments or organisations running existing applications in different functional areas of public transport, and the starting process for the definition of a database schema leading to the (physical) implementation of a data repository. Such data will suit the usage/exchange of information by applications and processes and may also or useful also to collect and organize information that might be accessible by other systems and users (employees, managers etc.)

Within the subdomains available in Transmodel only a subset of them are of relevance to the main characteristics of the eMOTION “Public Transport” domain. Besides the description of network data, a major relevance is given to passenger information and to public transport journey planning.







- subsection 2.12.1 (Data for PT Journey Planning)

3.2.15 Transport Exchange (TransXChange)

TransXChange is the UK national de facto standard for the exchange of bus route and timetable information. TransXChange is a concrete implementation based on an early version of TransModel. TransXChange is sponsored by the UK Department for Transport

The latest version of TransXChange (current version 2.1) may be found at http://www.transxchange.org.uk/.

Relevance

TransXChange may be used to exchange public transport routes and timetables, including trains, buses and other scheduled mode data. It is part of a family of coherent Transport related XML standards in the UK. Thus it should be considered in eMOTION.

A deeper presentation of the standard is available in Appendix 1 at subsection 2.8.3

3.2.16 Rail Data Transmission and Data Processing (UIC)

The International Union Of Railways (Union Internationale des Chemins de fer - UIC) creates UIC leaflets, which should be a reference for the entire railway community.

Information is available at http://www.uic.asso.fr/etf/codex/codex-resultat.php?sschapitre=91

Relevance

UIC leaflets define interactions for internal purposes of rail operators, so they are out of scope for eMOTION.

3.2.17 Verband Deutscher Verkehrsunternehmen - VDV-Schnittstelleninitiative (Interface Initiative)

The Association of German Transport Undertakings (Verband Deutscher Verkehrsunternehmen - VDV) is the organisation for Germany’s public transport companies and rail freight transport companies. Amongst other things it defines an Integration Interface for Automatic Vehicle Management Systems, which approaches to be a universal interface for the integration of AVMS systems. It is described in the VDV-Projects VDV 453 and VDV 454.

Information is available at



http://www.vdv.de/en/wir_ueber_uns/vdv_projekte/rbl_schnittstellen.html

Relevance

The VDV interface is not described in detail because the recommendations VDV453 and VDV454 represent the subset of the CEN standard 'SIRI', which is explained in subsection 3.2.13.

3.3 Weather Data

3.3.1 Binary Universal Form for the Representation of meteorological data (BUFR) / Character form for the Representation and EXchange of data (CREX)

The table driven code forms BUFR (Binary Universal Form for the Representation of meteorological data) and CREX (Character form for the Representation and EXchange of data) offer the great advantages of flexibility and expandability compared with the traditional alphanumeric code forms. These beneficial attributes arise because BUFR and CREX are self-descriptive. The term "self-descriptive" means that the form and content of the data contained within a BUFR or CREX message are described within the BUFR or CREX message itself. In addition, BUFR offers compression, or packing, while the alphanumeric code CREX provides human readability. BUFR was first approved for operational use in 1988. Since that time, it has been used for satellite, aircraft, wind profiler, and tropical cyclone observations, as well as for archiving of all types of observational data. In 1994, CREX was approved as an experimental code form by the WMO Commission on Basic Systems (CBS Ext.94). In 1998, CBS (CBS-Ext. 98) recommended CREX be approved as an operational data representation code form as from 3 May 2000. In 1999, this recommendation was endorsed by the WMO Executive Council (EC-LI (1999)). CREX is already used among centres for exchange of ozone, radiological, hydrological, tide gauge, tropical cyclone, and soil temperature data.

BUFR should always be the first choice for the international exchange of observational data. CREX should be used only when BUFR cannot. BUFR and CREX are the only code forms the WMO needs for the representation and exchange of observational data and are recommended for all present and future WMO applications. This guide to Table Driven Code Forms is designed in three layers to accommodate users.

One can obtain the documentation of the BUFR and CREX standard ([BUFRCREX, 2002a], [BUFRCREX, 2002b]) via download from the following link:

http://dss.ucar.edu/docs/formats/bufr/

Relevance

World Wide Standard for International interchange of meteorological data. Used for example in Germany and Czech Republic to interchange content of road weather stations since 2005. With this it is relevant for eMOTION.



Formerly the so called SH10 and SH70 Format was used to interchange Road Weather Source-Data from Road Weather stations and also for interchange forecast products data from the National Weather Service of Germany (DWD). This national standard SH10 / SH70 was substituted by BUFR and CREX Format.


3.3.2 TLS Standard - Environmental Data (FG3)

TLS (in German: 'Technische Lieferbedingungen für Streckenstationen') is a national standard for Road Weather and Environmental Data Acquisition on Road Site Remote Stations (Controllers). The standard is issued from the German Institute for Road Traffic (Bundesanstalt für Straßenwesen BASt). The standard is mandatory for all road side equipment to be installed on German Highways or Federal Roads.

The actual documentation about TLS Standard can be obtained via the following link: http://www.bast.de/cln_007/nn_42642/DE/Publikationen/Fachliche/Einzelschriften/tls/tls.html

Relevance

National standard for Data Acquisition and Control on Road Site Remote Stations. It is also used in a numerous countries in Europe for example in Austria (ASFINAG), Croatia, parts of the Czech Republic etc. The Standard is based on ISO/OSI TC57 and consists of seven Layers. It is used for line based Data communication but the Data model is also used in many message-based communication protocols on the GSM mobile-network or within the GPRS or UMTS standard. ASFINAG in Austria also defined an internal standard, called “TLS over IP”, which can be obtained from the following link: http://www.asfinag.net/plant/Verkehrstelematik/PLaNT_135.221.10_04.10.15_TLS-over-IP.pdf

TLS was also used in Germany for exchange of Data between subcentral and central computer stations. This section only refers to the Application Layer of the Protocol and the Data Model of the so called function group FG3 which deals with Road Weather and Environmental Data.

TLS is relevant in the eMOTION context because it is widely used in Europe.


3.3.3 UK National Air Quality Standards/Strategy

The UK Air Quality Standards for air pollution are concentrations over a given time period that are considered to be acceptable in the light of what is known about the effects of each pollutant on health and on the environment.



Information is available at http://www.airquality.co.uk/archive/standards.php#std

Relevance

Air quality standards are out of scope for eMOTION, so this is not described in detail.

3.4 Location Based Services

3.4.1 Directory Services Standards (DSML)

The Directory Services Markup Language (DSML) is published by the OASIS consortium. It bridges the world of directory services with the world of XML. DSML v1.0 provides a means of representing directory information in XML ([OASIS-DSML, 1999]). DSML v2.0 adds support for querying and modifying directories ([OASIS-DSML, 2002]).

The intent of DSMLv1 is to allow XML-based enterprise applications to access profile and resource information from a directory in their native environment. DSMLv1 allows XML and directories to work together and provides a common ground for all XML-based applications to make better use of directories.

DSMLv1 is intended to be a simple XML schema definition that will enable directories to publish basic profile information in the form of an XML document so that it can be easily shared via native Internet protocols (such as HTTP or SMTP), as well as used by other applications. The principal goal is to ensure that directories are able to make a growing breed of XML based applications directory aware.

It is not an initial goal of DSMLv1 to specify the attributes that all directories must contain, or the method with which the directory information is accessed from the directory. The expectation is that standard protocols (such as LDAP - Lightweight Directory Access Protocol), proprietary access protocols (such as Novell's NDAP - Novell Directory Access Protocol) and proprietary APIs (such as Microsoft's ADSI - Active Directory Service Interfaces) could produce DSMLv1 documents as an optional output.

DSMLv2 provides a method for expressing directory queries and updates (and the results of these operations) as XML documents. DSMLv2 documents can be used in a variety of ways. For instance, they can be written to files in order to be consumed and produced by programs, or they can be transported over HTTP to and from a server that interprets and generates them.

DSMLv2 functionality is motivated by scenarios including:

A smart cell phone or PDA needs to access directory information but does not contain an LDAP client (Lightweight Directory Access Protocol).

A program needs to access a directory through a firewall, but the firewall is not allowed to pass LDAP protocol traffic because it isn’t capable of auditing such traffic.

A programmer is writing an application using XML programming tools and techniques, and the application needs to access a directory.



This specific standard can be downloaded via:

http://www.oasis-open.org/committees/dsml/docs/dsml.zip (DSMLv1) and

http://www.oasis-open.org/specs/index.php#dsmlv2 (DSMLv2)

Relevance

Firstly as this standard, among other things, helps to portable end-user devices like smart phones, PDAs etc. to reach the directories (through the DSMLv2 extension), it should be covered by the eMOTION specification.

The second argument, reflecting relevance of OASIS standards in connection with the eMOTION project, is that OASIS consortium has over 5000 participants and that it has been led and sponsored by well known companies (SUN Microsystems, SAP, IBM, etc.) makes the OASIS standards relevant to be part of the eMOTION framework.



- subsection 4.7.1 (Directory Service)

3.4.2 OGC Web Feature Service (WFS): Gazetteer Service Profile

The OGC Gazetteer definition is openly available, however, it does not yet have the status of a standard. OGC lists it as a so-called “best practice paper”.

Document:

OGC Best Practices Document: Gazetteer Service - Application Profile of the Web Feature Service Implementation Specification – Version 0.9.3 Open Geospatial Consortium, 2006-06-05, Ref.No OGC 05-035r2 [OGC-WFS-G, 2006]

A copy of the document can be downloaded at:

http://portal.opengeospatial.org/files/?artifact_id=15529

The Gazetteer Service is defined as a profile of the OGC Web Feature Service Specification, which is described at subsection 4.1.3. It allows a client to search and retrieve elements of a georeferenced vocabulary of well-known place-names.

The profile builds on ISO 19112: Spatial referencing by geographic identifiers.

Relevance

Especially application services need the possibility to find out the location or other feature information of features known by identifiers which are possibly part of a thesaurus-like structure.

A Gazetteer is very much like a Geocode and Reverse Geocode, however it is organised



using feature data, which can be arbitrarily defined, but owns predictable core of location and identifier data. For this reason it is possible to define the Gazetteer as a subset of the Web Feature Service definition.


3.4.3 HIGHWAY

HIGHWAY is to offer higher safety and location-based value added services where interactions between the person in control, the vehicle and the information infrastructure are addressed in an integrated way.

Relevance

The main objective is beyond the scope of eMOTION, so it is not described in detail.

3.4.4 Multi-modal Information and Traffic Management Systems on Trans-European Networks (INFOTEN)

INFOTEN (Multi-modal Information and Traffic Management Systems on Trans-European Networks) is a research project of the European 4th Framework Research, which has introduced language-independent systems for traffic information exchange, multi-modal traveller information services and advanced driver warning systems in the Alpine area and Central Europe. It introduced new concepts of multi-modal traveller information services based on information kiosks and mobile devices.

Information is available at http://cordis.europa.eu/telematics/tap_transport/research/projects/infoten.html

Relevance

This application oriented approach of INFOTEN is beyond the scope of eMOTION, so it is not described in detail.

3.4.5 ISO 19133: Location-based services - Tracking and navigation

ISO 19133:2005 describes the data types, and operations associated with those types, for the implementation of tracking and navigation services ([ISO 19133, 2005]). It is designed to specify web services that can be made available to wireless devices through web-resident proxy applications, but is not restricted to that environment.

This specific standard can be obtained via:

http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=32551&scopelist=PROGRAMME



Relevance

ISO 19133 provides us with a useful network specification for routing and navigation purposes. Being an international standard, this network definition might serve as the basis for the definition of a harmonised definition of a routable network in eMOTION.

Clearly, road networks have to be “topological” to be of any use for navigation. They have to constitute 1-dimensional complexes (graphs) consisting of “nodes” and “edges”, which realise the necessary connectivity to perform routing in. The relevant part of ISO 19133 adds the additionally necessary model of usable vehicle routes in junctions (nodes) to the topological network as defined in ISO 19107.

The definition of Linear Referencing in ISO 19133 constitutes a very general model of this location referencing method. This definition might serve as the basis for the definition of linear referencing as part of the location referencing model of eMOTION. ISO 19133 has been made use of in various other projects and standard definitions.

In addition, ISO 19133 provides us with a fully-fledged specification for a Navigation Service, which is basically a service for finding optimised routes though a network under constraints. It also contains the necessary definitions for the main results of such a service, which are the calculated route and detailed descriptions for navigating such a route. Being an international standard, it should be considered when defining the necessary features and services for the eMOTION specification.


- subsection 2.1.2 (Road network)



- subsection 2.11.1 (Data for Routing)

- subsection 4.4.1 (Routing Service)

3.4.6 ISO 19134: Location-based services - Multimodal routing and navigation

Building on ISO 19133, ISO 19134:2007 describes a model for multi-modal (in the sense of inter-modal) routing and navigation ([ISO 19134, 2007]). ISO 19133, which is depicted in subsection 3.4.5, also defines the concept of “combined networks”, which is exploited in ISO 19134 to define a multi-modal network containing the necessary structures to support multi-modal (inter-modal) navigation and routing.


http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=32552&ICS1=35&ICS2=240&ICS3=70



Relevance

Together with ISO 19133, ISO 19134 provides us with a specification for inter-modal routing and navigation purposes. Being an international standard, this network definition might serve as the basis for the definition of a harmonised definition of a routable network in eMOTION.


- subsection 2.3.1 (Inter-Modal Transport Network Data)

- subsection 2.13.1 (Data for inter-modal Journey Planning)

3.4.7 OpenGIS® Location Service (OpenLS)

The standard

OpenGIS® Location Service (OpenLS) Implementation Specification: Core Services Version 1.1, Document OGC 05-016 [OGC-OpenLS, 2005]

defines Location Based Services for a “GeoMobility Server” platform. It defines the interfaces for a couple of core service types, namely Directory Service, Gateway Service, Location Utility Service, Presentation Service, and Route Service.

OpenLS also defines a uniform data model of so-called Abstract Data Types (ADT), which form the common basis of the interface definition.

Obtain the standard in its version 1.1 from the OGC Internet site using the URL

http://www.opengeospatial.org/standards/olscore

Relevance

The Abstract Data Types (ADT) definition of the standard (among other GeoMobility-related objects) defines object models for POIs and for location referencing. Since the OGC OpenLS definition of service interfaces constitutes a valuable candidate definition for various eMOTION services (as noted below, e.g. Directory, Routing, …), the modelling of POIs and of locations in this standard has to be considered for the corresponding specifications of eMOTION.

eMOTION needs content models for typical responses from routing services and the OGC OpenLS Route Service defines a clearly laid out and simple example for this. Besides OpenLS Route Service provides an interface for the computation of routes in networks. The interface is suited for road networks, and public transport networks, and also for inter-modal transport planning operations.

In addition, the eMOTION service definition has to include means to perform the typical query activities associated with POIs and other directory information. A typical use case of that kind would be for example: “Find the filling station nearest to my current position!” or ”Which modern art museums will be in walking distance to my hotel?”. The OGC OpenLS Directory Service provides a possible interface for questions of this kind.



Actually, a directory service is a special kind of data service, and the necessary functionality might also be performed by such a service definition. A specialised directory service, however, is optimised for its underlying directory data model and a user-friendly way to specify the necessary query inputs.

The OGC OpenLS Gateway Service provides a possible interface for the requirement to determine the current position of a mobile user. This is an important requirement, because the eMOTION service definition is targeted towards mobile use of services.

Also, eMOTION has the need to treat geographical positions, place names, and addresses interchangeably. Typically, addresses are only known partially and have to be completed to obtain usable information. The OGC OpenLS Location Utility Service meets these requirements.




- subsection 2.11.2 (Data for Routing)

- subsection 4.4.2 (Routing Service)

- subsection 4.6.1 (Positioning Service)

- subsection 4.7.2 (Directory Service)

- subsection 4.8.1 (Geocoding Service)

3.4.8 Point Of Interest eXchange Language Specification (POIX)

Especially for POI Services there is a type of standard language called POIX (Point Of Interest eXchange Language Specification) developed by Hiroyuki Kanemitsu, TOYOTA MOTOR CORPORATION and Tomihisa Kamada, ACCESS Co., Ltd. ([W3C-POIX, 1999]).

It is made available by the W3C Consortium as a note, the latest version can be found at http://www.w3.org/TR/poix .

Relevance

POIX is a location-related information descriptive language prepared with the aim of exchanging location-related information over the Internet, and is designed with XML 1.0 (Extensible Markup Language [W3C Recommendation]). Not only does POIX denote a simple location, but it also provides an environment capable of representing various information comprehensively with the targeted location.

The POIX is rather simple and easy to implement in eMOTION. In combination with SMIL and GML it can improve the accessibility of POI Services for Service Providers. For example, Elisabeth Haid, Günter Kiechle and Sven H. Leitinger have developed a proposal for "Multimedial Descriptions of georeferenced touristic Objects/Points of Interest“ (Reference:



"Multimediale Beschreibung geo-referenzierter touristischer Objects of Interest" http://www.salzburgresearch.at/research/gfx/050115_corp05_final_paper_haid_etal.pdf - in German language). They combined POIX with Tourism Markup Language (TourML, see 3.4.9), Synchronized Multimedia Integration Language (SMIL, see 4.5.4) and Geography Markup Language (GML, see 4.1.1). Their goal was an extension of TourML because this standard is limited in many ways.


3.4.9 Tourism Markup Language (TourML)

Tourism markup language (TourML, Link: http://www.opentourism.org/index.php/TourML) is an XML encoding for the transport and storage of tourism information, including both the spatial and non-spatial properties of tourist objects, based on GML and developed by the Open Tourism Consortium. TourML defines the XML Schema syntax, mechanisms, and conventions that

1. Provide an open, vendor-neutral framework for the definition of tourism application schemas and objects;

2. Allow profiles that support proper subsets of TourML;

3. Support the description of tourism application schemas for the full range of tourism objects and activities;

4. Enable the creation and maintenance of distributed tourism application schemas and datasets;

5. Support the storage and transport of application schemas and data sets;

6. Increase the ability of tourism supporting organizations to share tourism application schemas and the information they describe;

7. Enhance the tourist's experience by providing relevant location-based information in an appropriate format.

TourML supports a variety of data exchanges, as the following examples illustrate.

1. A hotel chain generates a TourML description of all its hotel properties for electronic delivery and uploading to TourML compliant databases;

2. A symphony orchestra creates a TourML file describing its forthcoming tour with details of cities visited and local contact information and supplies it to the tourist bureaus in each city it will visit;

3. A car rental firm produces a TourML file detailing the location of its rental agencies;

4. A local history group prepares for its state tourism agency a TourML file describing the historical features of its area and their location.

The Open Tourism Consortium (OTC) is a consortium of companies, government agencies,



individuals, and universities participating in the development of publicly available standards and open source software to support tourism. OTC was initiated by the Center for Information Systems Leadership in 2003.

Relevance

TourML should be taken into account for the eMOTION framework in the context of POI services because it is an international standard which covers objects and events of interest to tourists.


3.5 Routing/Navigation and Public Transport Journey Planning

3.5.1 Association of Transport Coordinating Officers-Common Interface File (ATCO-CIF)

Traveline is a service which provides impartial journey planning information about all public transport services – buses, coaches, trains, ferries, trams, metro and underground - throughout England, Wales and Scotland. One of the protocols which are in use is ATCO-CIF, which is based on the rail Common Interface File system. This is widely used in the UK as the main way of transferring data within traveline.

Information is available at http://www.pti.org.uk/index.htm.

Relevance

ATCO-CIF functionality is described in the more detailed TransXChange, while the format is used in RJIS, so it is not described in detail.

3.5.2 Nationwide Electronic Time Table Information - Durchgängige Elektronische Fahrplaninformation (DELFI)

DELFI is a system for distributed public transport journey planning in Germany. Within several DELFI-projects an interface was developed that allows a local journey planning service to request partial itineraries from other journey planning servers and to put them together to create one integrated journey plan for the end user.

The End user can request a connection in any web portal (journey planner of any regional transport operator). The local system decides if the itinerary request can be answered by the local system or if to query the distributed DELFI system.

The English version of the DELFI documentation ([DELFI, 2006]) can be obtained via:

http://www.delfi.de/html/40_dokumente.htm



Relevance

Studying the DELFI system may be important for eMOTION because DELFI realises a hierarchical service for public transport planning. I.e. DELFI does not do the “plan finding” by itself, but relies on regional transport planning services, whose outputs it joins to answer region-crossing requests. It is comparable to Journey Web (see 3.5.9), however, DELFI also describes implementation aspects and is not only an interface definition.


3.5.3 Ferry XML

The Ferry XML standard was developed by the Travel Technology Initiative (TTI). The TTI was founded in 1989 to establish technology standards within the travel industry. At that time, a number of leading travel companies recognized the benefits of using common system interfaces and documentation and agreed to form an industry wide group to develop technology standards. TTI has an Alliance agreement with the Open Travel Alliance (OTA) with whom it works closely. It chairs or is represented on a number of OTA committees.

Ferry XML was created by providing a XML structured alternative to the existing EDI Unicorn standard for booking ferry reservations.

It has been a specific design criterion to produce a minimum specification that can be used in every implementation without the need to negotiate data omissions thus optimizing the ease and speed at which the message set can be introduced. However, it is also understood that some data additions may be required in certain circumstances which would be the subject of a Service Level Agreement (SLA) between the relevant trading partners.

The XML Schema defined build upon the specifications managed by the Open Travel Alliance (OTA), (http://www.opentravel.org ). The messages themselves are maintained by the Travel Technology Initiative (TTI), (http://www.tti.org ), which is currently the managing authority for Package Holiday messages within the OTA and which will also be the managing authority for Ferry messages once they are accepted into the OTA specifications.

Each message pair is made up of a Request and Response schema.

Relevance

As eMOTION regards traffic in an intermodal way, shipping traffic is important as well. In coastal regions ferries take part in the daily traffic as much as all the other means of transportation. Therefore ferry transportation is relevant for eMOTION.

Ferry XML is important because the most main players of the ferry industry uses the XML Messages pairs. With the Ferry XML Message pairs it is possible to request the availability of ferry connections and to book a specific connection. There are further some other pairs for special procedure such as canceling a booking reservation.




- subsection 2.8.7 (covers also OTA) (PT Service Data)

- subsection 4.5.4 (PT Journey Planning Services)

3.5.4 Global Distribution Systems (GDS)

Global Distribution Systems (GDS) are computerized systems with the goals to book and sell tickets for multiple airlines. There are four main GDS networks in use: Amadeus, Galileo, Sabre and Worldspan.

Information is available at the websites of these big four GDS companies: http://www.amadeus.com/, http://www.galileo.com/, http://www.sabre.com/ and http://www.worldspan.com/.

Relevance

GDS offer products for airlines, but there is no generic standard available, so they are not relevant for eMOTION.

3.5.5 IM@GINE IT

IM@GINE IT (Intelligent Mobility AGents, Advanced Positioning and Mapping Technologies INtEgration Interoperable MulTimodal, location-based services) was a European research project which aims to develop a platform that had to function in real-time, offer multimedia, intermodal transport information, and take account of the personal preferences of the user.

Information is available at http://www.pti.org.uk/index.htm and http://istresults.cordis.europa.eu/index.cfm/section/news/tpl/article/BrowsingType/ Features/ID/81610

Relevance

In IMAGINE IT the elementary content services, which provide the necessary data play a minor role. These content services, however, form the main focus of eMOTION, so IMAGINE IT is not described in detail.

3.5.6 Intermodal Concepts in European Passenger Transport (INTERCEPT)

INTERCEPT (INTERmodal Concepts in European Passenger Transport) is a research project which encourages by example the implementation of intermodal door-to-door transport solutions in European cities.

Information is available at http://www.btsa.es/intercept/index.htm.

Relevance

INTERCEPT is not relevant for eMOTION because it produces no standards which could be taken into account.



3.5.7 ISO 14825: Geographic Data Files (GDF)

ISO14825:2004 describes a data model for representing real-world geographic phenomena on a conceptual level, a semantic level, and a physical level. The core is an object oriented concept of features that are

• semantically sub-typed into a rich set of feature classes;

• topologically organised in terms of fully integrated (planar) graphs, connectivity-only graphs, or independent (geometric) entities representing non-explicit (“spaghetti”) topology;

• categorised into points, lines, areas, or complexes;

• in possession of a rich set of semantic attributes; and

• able to play roles in semantic relationships with other features.

GDF’s thematic scope covers the transportation networks (road, rail, water); administrative and other named areas, public transport, Points-of-Interests (POIs) – called services in GDF –; road furniture, and others. GDF gives rules how to capture and classify data (in terms of a common “language”), and how to deliver it in terms of exchanging geographic database content. Any content item is optional (except if it is required for consistency and integrity reasons conditional to other content being captured), this means the actual content of GDF “map products” is determined by application needs and market requirements.

GDF is widely used in the automotive and personal navigation services business where there is a need to transport highly detailed and complex geographic models to support applications such as navigation, route guidance, dynamic map display, online routing services, local search, location-based services, etc. Due to commercial adoption by the leading map database providers, the GDF standard is the only globally supported standard for delivering high-end navigable map content towards a globalized market place of (automotive, personal, web) navigation and location services.


http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=30763&ICS1=3&ICS2=220&ICS3=1 ([ISO 14825, 2004])

This standard is subject to ongoing development, including dedicated harmonization with TC211 ISO191xx standards. The next edition (referred to as XGDF – eXtended GDF) is targeting “technical freeze” by the end of 2007. As part of devising XGDF, UML has been introduced as data modelling language adopting TC211 conventions. Content extensions will include 3D city models, enhanced multi-modal navigation features (e.g., pedestrian connectivity and accessibility properties), and spatio-temporal capabilities. Encoding extensions with include an XML realization, and a SQL-MM compliant realization of relational database tables.



Relevance

The ISO14825 standard is a recognized reference for representing road network data in the navigation and location services market. Its taxonomy for classifying features, attributes and relationships and its 3-level “architecture” (shared geometry & topology, simple features, aggregated features) has been adopted for large-scale map data production by the leading map database vendors. Such road network data forms the geographic information infrastructure for today’s commercial navigation and routing applications, as a base for ongoing developments for future pedestrian and multi-modal navigation product features such as envisaged by eMOTION.


- subsection 2.1.1 (Road Network Data)



3.5.8 ISO 17572-3: AGORA-C

AGORA-C is a method for on-the-fly location referencing. It is currently being standardised by ISO TC 204 as

ISO 17572-3 Intelligent Transport Systems (ITS) -- Location Referencing for Geographic Databases – Part 3: Dynamic Location References (Dynamic Profile) ([ISO 17572, 2007])

At the time of writing the state of the standard is CD.

Note that the use AGORA-C is protected by license rights.

AGORA-C contains the following elements to enable on-the-fly location referencing:

• the AGORA-C encoding framework including the building blocks and a list of allowed attributes;

• the AGORA-C logical data model;

• the AGORA-C encoding rules, comprising rules for the mandatory Core Profile and rules for the optional Extended Profile;

• a coding procedure, comprising separate parts for the Core and Extended Profiles;

• a detailed description of the AGORA-C physical format.

The coding procedure is based on the encoding rules, and may be used as a guideline to develop an encoding algorithm.

Relevance

The AGORA-C location referencing concept is designed to compensate for differences that may exist between maps used by different location reference systems. This is important for



eMOTION, because with eMOTION various models of location referencing should be handled.


3.5.9 JourneyWeb

JourneyWeb is an extensible protocol and open XML-schema for dynamic data exchange over the Internet between multimodal public transport journey planners

The protocol enables any one journey planner to send questions to another, and to receive answers back, so that journeys can be planned beyond the boundary of the first journey planning system. The protocol can be used with journey planners used in telephone call centres, on the Internet or at kiosks.

JourneyWeb documentation and schema are Crown Copyright, are managed by the UK Department of Transport, and may be used without charge under a perpetual nonexclusive, non-transferable, royalty-free licence.3

JourneyWeb assumes clients have full knowledge of the NaPTAN and NPTG databases. Geocode references are by UK Ordnance Survey Eastings and Northings.

The most recent (though unofficial) version of JourneyWeb described is JourneyWeb v3.0.

Reference: Journey v3.0 Schema Guide – Consultation Draft version 2.0. Available from http://www.kizoom.com/standards/journeyweb/schema/schemas.htm

Relevance

JourneyWeb describes a protocol for the exchange of journey planning information between journey planning engines, allowing a local journey planning engine to make requests on a remote journey planning engine, allowing a journey plan to be provided between locations not covered by the same journey planning service. There are several implementations using JourneyWeb, so it should be considered in the eMOTION framework. Journey Web is comparable to DELFI (see 3.5.2).


3.5.10 OGC Web Coordinate Transformation Service (WCTS)

OGC Web Coordinate Transformation Service Version 0.3.0 is a draft standard and is publicly available. It has the status of an OGC Discussion Paper.

3 A new CEN activity to see if any standardisation can be achieved in distributed jouney planning is launched with an intial meeting of EU-SPIRIT, DELFI and Jouney Web stakeholders on 31 August 2007.



Document:

Web Coordinate Transformation Service (WCTS) draft Implementation Specification. Open Geospatial Consortium, 2005-01-31, Ref.No OGC 05-013 [OGC-WCTS, 2005]

A copy of the standard can be downloaded at:


The document specifies the interface to a Web Coordinate Transformation Service, which can be used by geospatial applications and other services.

The definition is based on the following OGC standard concerning coordinate systems and coordinate transformation:

Coordinate Transformation Services, Revision 1.00 Open Geospatial Consortium, 2001-01-12, Ref.No. OGC 01-009 [OGC-CT, 2001]

This standard can be obtained from:

http://www.opengeospatial.org/standards/ct

Relevance

Transformation of geospatial data from one coordinate reference system (CRS) to another is frequently required when using data from different sources in one application. That is, geospatial data are often stored in different coordinate reference systems (CRSs). To use together data stored in different CRSs, such data must be transformed or converted into the same CRS. Not all applications or services are capable of directly performing such transformations.

In eMOTION this requirement is part of a larger one, requiring to translate different location references into each other of necessary.


3.5.11 OpenTravel Alliance (OTA) Standard

The standardisation of air traffic on an international level is organised by the OTA Consortium, which is responsible for these topics.

The OpenTravel Alliance is a non-profit organization working to establish a common electronic vocabulary, represented in XML format, for use in the exchange of travel information. Members of the OpenTravel Alliance include airlines, hotel companies, car rental companies, cruise lines, railways, global distribution systems, distribution companies, solutions providers, software developers and consultants.

The OpenTravel Alliance is focused on solving the problems inherent with connecting multiple systems within the complex travel distribution area.

The OTA's mission is to engineer specifications that make data transmission flow smoothly



throughout travel, tourism and hospitality.

The OTA creates, expands and drives adoption of open universal data specifications, including but not limiting to the use of XML, for the electronic exchange of business information among all sectors of the travel industry.

The OTA published twice a year a new specification. In this section, the second release from the year 2006 (OTA Specification 2006B) is described.

The actual complete OTA Specification can be downloaded from the OTA Website: http://www.opentravel.org.

OTA standards are service standards – the content is provided as part of the response of a service interface. The content interesting for eMOTION covers mainly the description of public transport plans.

Relevance

The OTA service standard was designed to allow various businesses (car rental agencies, airlines, hotels and travel agencies) to coordinate reservations across the Internet. The OTA Substandard for the Air Industry, developed from the OTA Air Group, has a set of XML Messages types to communicate with the flight plan and booking systems from the Airlines. So the Standard gives a specification so that an information and booking system can communicate with the airlines’ booking systems.

Therefore it is for instance possible to request with an “AirAvailable” Request the actual Flight Plans from all Airlines, which have implemented this special OTA Message. The most important international Airlines (for Example: Delta, Continental, United American, US Airways, Virgin, British Airways, Lufthansa/SWISS) have already implemented most of the OTA Messages. Also the four main Global Distribution Systems (Amadeus, Galileo, Sabre und Worldspan) use the OTA Messages to provide their booking and information service.

The “AirAvailable”-Operation is therefore also of great importance to eMOTION.


- subsection 2.8.7 (covers also Ferry XML) (PT Service Data)

- subsection 4.5.3 (PT Journey Planning Services)



4. Domain Independent Standards

4.1 Spatial Data Infrastructure

4.1.1 Geography Markup Language (GML)

Geography Markup Language (GML) is an XML encoding in compliance with ISO 19118 for the transport and storage of geographic information modelled according to the conceptual modelling framework used in the ISO 191xx series and including both the spatial and non-spatial properties of geographic features ([OGC-GML, 2004]).

In the basis of the GML definition are predefined XML representations for ISO 19107 geometries and topology and ISO 19108 temporal specifications. Yet, a mechanism for extending GML to arbitrary application schemas is also part of the standard.

GML is the final outcome of a model driven architecture procedure, which starts at ISO 191xx conceptual modelling.

The GML specification defines the XML Schema syntax, mechanisms, and conventions that:

• Provide an open, vendor-neutral framework for the definition of geospatial application schemas and objects; GML can represent geospatial phenomena in addition to simple 2D linear features, including features with complex, non-linear, 3D geometry, features with 2D topology, features with temporal properties, dynamic features, coverages, and observations.

• Allow profiles that support proper subsets of GML framework descriptive capabilities;

• Support the description of geospatial application schemas for specialized domains and information communities;

• Enable the creation and maintenance of linked geographic application schemas and datasets;

• Support the storage and transport of application schemas and data sets;

• Increase the ability of organizations to share geographic application schemas and the information they describe.

Implementers may decide to store geographic application schemas and information in GML, or they may decide to convert from some other storage format on demand and use GML only for schema and data transport.

More Information is available at http://www.opengeospatial.org/standards/gml.

Relevance

GML is widely used by other relevant standards to exchange geospatial data, e.g. OGC Web Feature Service, and therefore it is of great importance within eMOTION.




4.1.2 OGC Web Coverage Service (WCS)

OGC WCS Version 1.1.0 is a publicly available open standard.

Standard document:

Web Coverage Service (WCS) Implementation Specification / OGC WCS Version 1.1.0 Open Geospatial Consortium, 2006-10-17, Ref.No OGC 06-083r8 [OGC-WCS, 2006]

A copy of the current standards can be downloaded at:

http://www.opengeospatial.org/standards/wcs

The Web Coverage Service supports electronic retrieval of geospatial data as "coverages" – that is, digital geospatial information representing space-varying phenomena.

Relevance

Environmental data and original weather data typically come as coverages. For example, noise pollution values (frequency and intensity) derived by a simulation model in the vicinity of roads will be given on a raster basis.

Therefore coverage may play a role in the eMOTION context.


4.1.3 OGC Web Feature Service (WFS)

OGC WFS Version 1.1.0 is a publicly available open standard.

It refers to OGC Filter Encoding Version 1.1.0 and OGC GML Version 3.1.1, which are both publicly available open standards.

Standard documents:

OpenGIS® Web Feature Service (WFS) Implementation Specification / OGC WFS Version 1.1.0, Open Geospatial Consortium, 2005-05-03, Ref.No OGC 04-094 [OGC-WFS, 2005].

OpenGIS® Filter Encoding Implementation Specification / OGC FE Version 1.1.0 Open Geospatial Consortium, 2005-05-03, Ref.No OGC 04-095 [OGC-FE, 2005]

Regarding GML see 4.1.1.



The WFS standard is currently in the process of being revised. The new version 1.2.0 will also appear as ISO 19142.

A copy of the current standards can be downloaded at:

http://www.opengeospatial.org/standards/wfs http://www.opengeospatial.org/standards/filter

Relevance

One of the core tasks of eMOTION services will be the provision of data according to the eMOTION data model. Data from various sources will have to be queried, combined, processed and made available to other services and end users.

WFS defines a general model for accessing data over the web, without being specialised on certain information domains. It provides a “web database interface”. The “data independent” WFS standard definition can therefore possibly make up for a large quantity of specialised data services and their specialised query and updating operations.

Using the WFS definition as the central data provision mechanism also has the advantage of being in line with relevant Spatial Data Infrastructure endeavours in Europe and word-wide.


4.1.4 OGC Web Map Service (WMS)

OGC WMS Version 1.3.0 is a publicly available open standard. It constitutes also an International Standard ISO/DIS 19128.

Standard documents:

OpenGIS® Web Map Service (WMS) Implementation Specification/ OGC WMS Version 1.3.0 Open Geospatial Consortium, 2006-03-15, Ref.No OGC 06-042 [OGC-WMS, 2006]

See http://www.opengeospatial.org/standards/wms

also:

ISO/DIS 19128 – Geographic Information – Web map server interface

Relevance

Well defined maps for various content domains will form an important part of the eMOTION product definitions. The maps from various sources can be easily combined to build effective web information applications.

Most maps are defined on the background of an information model of the underlying content



domain. So, the data behind the map can also be queried by means of a WFS or simply by using the limited functionality of the GetFeatureInfo operation.


4.1.5 OGC Web Map Service (WMS) with Styled Layer Descriptor (SLD)

OGC WMS with Styled Layer Descriptor (SLD) builds on OGC WMS Version 1.3.0 as described above. It is actually an extension to this standard (a so-called profile), which is defined in the standard document:

Styled Layer Descriptor profile of the Web Map Service Implementation Specification / Version 1.1.0, Open Geospatial Consortium, 2007-01-05, Ref.No OGC 05-078r3 [OGC-SLD, 2007].

The SLD profile of the WMS again makes use of the Symbology Encoding (SE) standard, which is defined in:

Symbology Encoding Implementation Specification / Version 1.1.0, Open Geospatial Consortium, 2006-07-21, Ref.No OGC 05-077r4 [OGC-SE, 2006].

The SLD document specifies how a Web Map Service can be extended to allow user-defined styling. The styling of maps is done by referring to data store semantics, and is the subject matter of Symbology Encoding.

Download the mentioned standards from:

http://portal.opengeospatial.org/files/?artifact_id=12637 http://www.opengeospatial.org/standards/symbol

Relevance

As already pointed out in the context of a “pure WMS” maps will form an important part of the eMOTION product definitions.

The SLD enhancement extends the attractive concept of combining maps from different WMS sources by just overlaying them, and by introducing styling from the client side. This effectively adds possible interactivity to the maps, because with the aid of SLD clients can render objects visible/invisible or can highlight selected objects. They can also alter maps to be better suited for people with visual handicaps, or just on demand of the viewer. There are indeed endless possibilities by controlling styling from the client side, which can be well compared to functionality known from GIS.




4.1.6 OGC Web Notification Service (WNS)

OGC Web Notification Service (WNS) Version 0.0.9 is openly available, but is not a standard. It is a draft standard and has the status of an “OpenGIS® best practice paper”.

Document:

Draft OpenGIS® Web Notification Service Implementation Specification Open Geospatial Consortium, 2006-11-18, Ref.No OGC 06-095 [OGC-WNS, 2006]

A copy of the draft standard document can be downloaded at:


The Web Notification Service (WNS) is a network-accessible service by which a client may conduct asynchronous message interchanges with one or more other services.

Relevance

The eMOTION service definition rests on a service model, which encompasses both pull-mode services as well as push-mode services. Push-mode requires service instances, which accept a subscription from a client (the user of the service), and which alert that client as soon as a certain condition arises.

The OGC WNS defines a service component, which isolates and solves the problem of subscription and of “calling-back” a subscribing client over some predetermined “back-channel”.


4.1.7 OASIS Web Services Notification (WSN)

The Web Services Notification (WSN) is a family of specifications, which is published as a standard by the OASIS consortium.

Standard documents are the following:

- Web Services Base Notification ([OASIS-WSN-Base, 2006]): It contains the basic specification of the WSN.

- Web Services Brokered Notification ([OASIS-WSN-BN, 2006]): This document describes the possibility to reproduce notifications which are produced by other entities. In the following description of the WSN the part of a notification broker is not considered.

- Web Services Topics ([OASIS-WSN-Topics, 2006]): A mechanism to organize and categorize items of interest for subscription is defined in this document.

See the OASIS website of the WSN Committee where you can find the related documents: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn



The WSN uses some other OASIS standards such as WS-Addressing.

Relevance

Notification Services are necessary to implement event-driven interaction patterns.

In the context of eMOTION many events exist where it makes sense to inform interested users. One example: a driver should be informed if there is a traffic jam in front of the road section he is using. Therefore notification services are an important part of the eMOTION services. Notification services are also contained in typical ITS service definitions like SIRI or DATEX 2.


4.2 Registry

4.2.1 ISO 19115: Geographic information – Metadata

ISO 19115:2003 ([ISO 19115, 2003]) defines a schema required for providing information on geographic content and services. The schema includes information about the identification, the extent, the quality, the spatial and temporal schema, spatial reference, and distribution of digital geographic data.

ISO 19115:2003 is applicable to:

• the cataloguing of datasets, clearinghouse activities, and the full description of datasets;

• geographic datasets, dataset series, and individual geographic features and feature properties.


http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26020

Relevance

According to the envisioned eMOTION architecture, content and service resources are to be detected and evaluated from registry services, which belong to the eMOTION infrastructure. Since no domain-specific metadata has been detected in this analysis, it will be necessary to make use of some general metadata model, which seems appropriate.

ISO 19115 lends itself to be employed in that role because it is an international metadata standard which is part of the TC 211 standardisation process and is geared towards geographic features.

There are also catalogue definitions which are specifically tailored towards the use of ISO 19115 metadata, see 4.2.4. The use is, however, not restricted to this, e.g. metadata can also be part of individual data exchange to express the quality of data items.




- subsection 2.15.1 (ISO 19115: Metadata)

4.2.2 OGC Catalogue Services Specifications

The OGC Catalogue Services Specification currently comprise of

• the Catalogue Interface standard (CAT Version 2.0.2), which defines the service functionality and binds to several distributed computing environments including HTTP, which case the service definition is called Catalogue Services for the Web (CSW),

and two application profiles of CAT 2.0.2, particularly CSW,

• the first of which rests on the ISO 19115 / 19 metadata standards and

• the second of which makes use of the ebXML Registry Information Model (ebRIM).

Both profiles will be described in the following sections (see 4.2.3 and 4.2.4).

Document:

OpenGIS® Catalogue Services Specification Version 2.0.2, Corrigendum 2 Release Open Geospatial Consortium, 2007-02-23, Ref.No OGC 07-006r1 [OGC-CAT, 2007]

Download the document from the following URL:

http://www.opengeospatial.org/standards/cat

Relevance

Registries/Catalogues are an important component of the eMOTION architecture. The use of the OGC specifications may be of advantage, because the spatial nature of road and traffic information also requires spatially enabled catalogue services. Other definitions would have to be extended into that direction.


4.2.3 OGC Catalogue Services - ebRIM Profile of CSW

This is a Draft Standard defining a profile of the CAT Version 2.0.2 framework (see 4.2.2). It is based on its HTTP binding (CSW 2.0.2). The document is publicly available.

The information model of the profile is the international standard the OASIS ebXML Registry Information Model v2.5 also known as ISO/TS 15000-3.

Standard document:

OGC® Catalogue Services — ebRIM (ISO/TS 15000-3) profile of CSW, Version 1.0.0 Open Geospatial Consortium, 2005-10-17, Ref.No OGC 05-025r3 [OGC-ebRIM,



2005]

Download the document from the following URL:

http://www.opengeospatial.org/standards/cat

Relevance

Registries/Catalogues are an important component of the eMOTION architecture. The use of the OGC specification instead of the original ebRS service definition (see 4.2.5) may be of advantage, because the spatial nature of road and traffic information also requires spatially enabled catalogue services.

On the other hand, the OGC registry models misses important parts of a registry definition like explicit lifetime control of registry objects.


4.2.4 OGC Catalogue Services - ISO19115/ISO19119 Profile of CSW

This is a Draft Standard defining a profile of the CAT Version 2.0.2 framework (see 4.2.2). It is based on its HTTP binding (CSW 2.0.2).

The draft standard document explains how Catalogue Services based on the ISO19115/ISO19119 Application Profile for the OGC® Catalogue Services Specification v2.0.2 are organized and implemented for the discovery, retrieval and management of data metadata, services metadata and application metadata.

The document is not currently available publicly, although it should be soon.

The information model of the profile is the international standard the OASIS ebXML Registry Information Model v2.5 also known as ISO/TS 15000-3.

OGC® Catalogue Services – ISO Metadata Application Profile, Version 1.0.0 Open Geospatial Consortium, 2007-05-02, Ref.No OGC 07-045 [OGC-CATISO, 2007]

Relevance

Registries/Catalogues are an important component of the eMOTION architecture. The use of this OGC specification may be of advantage, if ISO 19115 and ISO 19119 are deemed a usable metadata model for eMOTION.

The OGC catalogue model does, however, not support any form of explicit lifetime control of registry objects.




4.2.5 OASIS ebXML Registry Services and Protocols

An ebXML Registry is an information system that securely manages any content type and the standardised metadata that describes it. It provides a set of services that enable sharing of content and metadata between organisational entities in a federated environment.

The standard is defined in the following two OASIS documents [OASIS-ebXML, 2005a] and [OASIS-ebXML, 2005b]. Both are openly available standards.

Download the documents from the following URLs:

http://docs.oasis-open.org/regrep/v3.0/specs/regrep-rim-3.0-os.pdf

http://docs.oasis-open.org/regrep/v3.0/specs/regrep-rs-3.0-os.pdf

Relevance

eMOTION will need centralised service instances, which let service providers publish their services and contents. The metadata published can subsequently be found by clients and be used to bind to those services and contents for transactions. There is also a need to publish associated metadata resources, like schemas, styling information, licences, etc.

OASIS ebXML registries can provide this.


4.3 Authentication, Authorisation, DRM

4.3.1 Contact And Contactless Telematics platform Yielding a Citizen Pass integrating urban Services and financial Operations (CALYPSO)

CALYPSO (Contact And Contactless Telematics platform Yielding a Citizen Pass integrating urban Services and financial Operations) develops and implements a system based on a single smart card for multiple uses, for transportation, banking and other services. Using the same microprocessor card, the system provides contact and contactless operations in a multi-service, multi-operator environment for payment, ticketing, identification, location, reservation, information and security functions.

Informaton is available at http://cordis.europa.eu/telematics/tap_transport/research/projects/calypso.html.

Relevance

CALYPSO is a research project with a technical scope, so it is not described in detail.

4.3.2 Global System for Telematics: Certification (GST: CERTECS)

GST (Global System for Telematics) is an EU-funded Integrated Project that created an open



and standardized end-to-end architecture for automotive telematics services. One part of GST is Certification (CERTECS). CERTECS is specifying, prototyping and validating a certification process for telematics components, systems and services, targeted at the automobile industry and supported by relevant methods and information technology.

Informatons are available at http://www.gstforum.org.

Relevance

CERTECS is a research project, out of scope for eMOTION and it is not described in detail.

4.3.3 OGC Geospatial Digital Rights Management Reference Modell (GeoDRM RM)

The Geospatial Digital Rights Management Reference Model (GeoDRM RM), Version 1.0.0, is an abstract OGC Specification. The document is publicly available.

Standard document:

Geospatial Digital Rights Management Reference Model (GeoDRM RM) Open Geospatial Consortium, 2006-02-28, Ref.No OGC 06-0004r3 [OGC-GeoDRM, 2006]

Obtain a copy of the document from:

http://www.opengeospatial.org/standards/as/geodrmrm

GeoDRM RM is a reference model for digital rights management (DRM) functionality for geospatial resources. Note that neither a fully defined services model nor an explicit rights expression language is contained. The document defines only abstract concepts.

Relevance

eMOTION also covers the lawful relationships between the different actors in its proposed value chain. This has been done in Work Package 2 and has been documented in deliverables D3 and D4. D3 already contains a reference to GeoDRM RM – it has at this place been employed as a reference model for rights and licences.

A key aspect of the GeoDRM RM is that it is abstract, or general, rather than specifying implementation details about types of agreements. Such agreements might range from an open content sharing model to a cost-recovery program of a public or government organization or a full commercial vendor license model.

The standard defines

• a architectural model for digital rights management of geospatial resources,

• a metadata model for the specification of rights and licences, particularly those having a geospatial apect,

• a model of requirements on rights management and rights enforcement.

The OGC GeoDRM RM is an important standard reference, though a real service definition on the basis of the abstract model still needs to be defined.




4.3.4 OASIS Security Assertion Markup Language (SAML)

SAML 2.0 is a publicly available open standard from OASIS. The standard is defined in a series of documents. The SAML core standard is:

Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, 2005-03-15, Document identifier: saml-core-2.0-os [OASIS-SAML, 2005]

Download the standards from:

http://docs.oasis-open.org/security/saml/v2.0/

SAML specifies an encoding (an XML language) for use in a service oriented environment, it is not a service.

Relevance

SAML is a generally accepted and fully automated means of providing authentication to clients wishing to access secured domains. It is an auxiliary standard for trusted services.


4.3.5 OASIS eXtensible Access Control Markup Language (XACML) / GeoXACML

The eXtensible Access Control Markup Language (XACML), Version 2 is an international open standard from OASIS. The standard document is publicly available.

Standard document:

eXtensible Access Control Markup Language (XACML), Version 2 OASIS, 2005-02-01, Document id: oasis-access_control-xacml-2.0-core-spec-os [OASIS-XACML, 2005]

Obtain a copy of the document from:

http://docs.oasis-open.org/xacml/2.0/XACML-2.0-OS-NORMATIVE.zip

The standard centers around an encoding for expressing security policies regarding any possible resources, XACML. However it does this in an abstract framework of components like Policy Decision Points, Policy Enforcement Points, etc., which allows us to view the standard in the scope of services.

There is also an extension to XACML by OGC, called GeoXACML, which adds spatial restrictions to XACML. This document has the status of a discussion paper.

"Geospatial eXtensible Access Control Markup Language (GeoXACML)", Version: 0.3.0, Open Geospatial Consortium (OGC), Editor: Andreas Matheus, 2007-03-22,



Ref. No. OGC 07-026 [OGC-GeoXACML, 2005]

Obtain a copy from:

http://portal.opengeospatial.org/files/index.php?artifact_id=10471

Relevance

Access Control is an important part of Digital Rights Management (DRM), it is also an important issue of its own.

In the context of a DRM system XACML (or GeoXACML) based components may provide the functionality for the enforcement of licencing constraints.


4.4 eCommerce

4.4.1 Electronic Payment System (eps)

eps is a simple, safe and free of charge standard of Austrian Banks for e-Commerce and e-Government payments.

As eps is an interface between Austrian onlinebanking sytems and e-shop portals, it allows to pay in more than 300 Web-shops via the common online banking. It is also possible to pay a lot of electronical public authorities procedures (parking ticket, dog taxes etc.) by eps online transaction as it is an accepted standard for e-government by the Federal ministry of Finance in Austria.

eps was developed in 2003 by the 4 leading Austrian Banks (Erste Bank, Raiffeisen, BAWAG, Bank Austria)

eps online- transaction is the summary of the following payment systems: Partner Online Paying (Bank Austria Creditanstalt), Direct Pay (BAWAG P.S.K. Gruppe), Netpay (Erste Bank und Sparkassen) and ELBA Payment (Raiffeisen Bankgruppe).

eps e-payment standard has been created by the bank comprehensive studycircle for cooperation within payments (STUZZA) collectively with the Austrian Banks, the BMF and the CIO (Chief Information Office).

eps e-payment standard is an open, normed interface for online payment systems.

The eps is a secure and direct payment method via web. It is usefull for webservices in Austria but not for the EU in common as it is only a national standard.

The eps could inspire the SEPA project which will create a new European standard for banks, merchants and customers.

Informaton is available at http://www.eps.or.at/



Relevance

eps can be an additional information source in the context of the eMOTION payment and billing domain, but it has only a minor relevance because of it's national character.


4.4.2 Global System for Telematics: Security (GST: SEC)

GST (Global System for Telematics) is an EU-funded Integrated Project that created an open and standardized end-to-end architecture for automotive telematics services. One part of GST is Security (SEC). The Security sub-project is defining an infrastructure for secure telematics applications. Security from a user point of view (applications, services, user devices) and a technology point of view (networks, platforms) will be covered.

Information is available at http://www.gstforum.org

Relevance

The defintion of an infrastructure for secure telematics applications is not relevant for eMOTION, so it is not described in detail.

4.4.3 Global System for Telematics: Service Payment (GST: S-PAY)

GST (Global System for Telematics) is an EU-funded Integrated Project that created an open and standardized end-to-end architecture for automotive telematics services. One part of GST is Service Payment (S-PAY). Service Payment is to recommend a payment and billing architecture that meets current and future telematics service requirements.

Information is available at http://www.gstproject.org/spay/

Relevance

End-user billing systems are not in the center of concern of eMOTION, so it is not described in detail.

4.4.4 Integration of Contactless technologies into public transport environment (ICARE )

ICARE (Integration of Contactless technologies into public transport environment) concerns a new contactless payment and ticketing system for multi-modal and multi-operator Public Transport.

Information is available at http://cordis.europa.eu/telematics/tap_transport/research/projects/icare.html



Relevance

The usage of a new payment and ticketing system is not in the scope of eMOTION, so it is not described in detail.

4.4.5 Interoperable smart card ticketing (ITSO)

ITSO Organisation was formed to build and maintain a specification for secure and loss-less ‘end-to-end’ interoperable smartcard ticketing transactions. This specification is publicly available, currently in Version 2.1.2.

Information is available at http://www.itso.org.uk/

Relevance

The purpose of the Specification is to provide a platform and tool-box for the implementation of interoperable contactless smart customer media, which is out of scope for eMOTION, so it is not described in detail.

4.4.6 Single Euro Payments Area (SEPA)

The Single Euro Payments Area (SEPA) will be created to give citizens, companies and other economic actors the opportunity to make and receive payments within Europe, whether between or within national boundaries by the same basic conditions, rights and obligations, regardless of their location.

SEPA is a single payments market where citizens and economic actors can make payments as easily and cheaply as in their hometown. The SEPA programme has been championed by the European Commission (EC) and the European Central Bank (ECB) working with the Eurosystem, and supported by the European Payments Council (EPC) which brings together the European payments industry.

SEPA is expected to improve competition, promote more efficient payment systems and strengthen the Euro. Once SEPA is achieved, it will be possible for consumers to reach all accounts SEPA-wide from one home country account. More widely accepted payments cards will displace cash improving customer safety and security. Merchants will be able to accept payment cards from all SEPA countries and back office processes will be simplified.

From 2008 the SEPA payment instruments (credit transfers, direct debits and cards) will operate alongside existing national processes, with full migration achieved from 2010 onwards. After the transition purely national solutions for core credit transfers and direct debits, and purely national card schemes will no longer exist.

More information is available at http://www.europeanpaymentscouncil.eu/

Relevance

Electronic payment is taken into account by SEPA, but this is not available at the moment, so it could be relevant for eMOTION at a future date.




4.4.7 Transferred Account Procedure (TAP / TAP3)

TAP is the process that allows a visited network operator to send billing records of roaming subscribers to their respective home network operator. TAP3 is the latest version of the standard and will enable billing for a host of new services that networks intend to offer their customers.

Information is available at http://www.gsmworld.com/using/billing/index.shtml

Relevance

TAP covers payment and billing between different international telecommunication operators. Against this, eMOTION being mainly an Internet based services architecture, so this standard is out of scope and it is not described in detail.

4.4.8 OGC Web Pricing and Ordering Service (WPOS)

The Web Pricing & Ordering Service is an OGC pre-standard. It has the status of an OGC discussion paper.

Document :

Pricing & Ordering Service (WPOS), XML Configuration & Pricing Format (XCPF) Open Geospatial Consortium, 2002-10-18, Ref.No. 02-029r1 [OGC-WPOS, 2002]

Obtain a copy from:

http://portal.opengeospatial.org/files/index.php?artifact_id=11500

The specification describes a web service which covers all standard geo-eBusiness processes like pricing, ordering and online delivery for spatial products.

Relevance

eMOTION might employ this pre-standard to impose a pricing and ordering strategy on the delivery of products.


4.5 Communication Standards

4.5.1 ANEMONE

The ANEMONE project will realize a large-scale testbed providing support of mobile users and devices and enhanced services by integrating cutting edge IPv6 mobility and multihoming initiatives together with the majority of current and future wireless access



technologies.

Information is available at https://www.ist-anemone.eu/index.php/Home_Page

Relevance

Anemone is a research project which is still in progress. In contrast to eMOTION it has a more application oriented, technical view, and it is not described in detail.

4.5.2 Continuous air interface, long and medium range (CALM)

Intelligent transport systems -- Continuous air interface, long and medium range (CALM) provides protocols and parameters for medium-range, medium- to high-speed wireless communications in the ITS sector using infra-red systems.

The standard is publicly available as ISO 21214:2006 at http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=41104&ICS1=3&ICS2=220&ICS3=1

Relevance

The usage of infra-red systems is out of scope for eMOTION, so this standard is not described in detail.

4.5.3 Global System for Telematics: Open Systems (GST: OS)

GST (Global System for Telematics) is an EU-funded Integrated Project that created an open and standardized end-to-end architecture for automotive telematics services. One part of GST is Open Systems (OS). The objective of OS is: Establishing an open telematics market by standardising key interfaces that allow the different players of the value chain to easily develop, implement and deploy new functionality or sub-systems.

Information is available at http://www.gstproject.org/os/

Relevance

The scope of GST/OS is more application oriented than eMOTION and no standard is approved, so it is not described in detail.

4.5.4 Hand-Held Devices and User Terminals

A variety of user interfaces for mobile data services such as wireless Internet, picture messaging and mobile e-mail, currently have been developed as part of Mobile Operating Systems. A short review of the main operating systems using in smartphones and PDAs includes:

• Symbian OS from Symbian Ltd. that has the largest share in most markets worldwide.

• Linux operating system, strongest in China and in Japan and used as a basis for a



number of different platforms developed by several vendors, PalmSource for example is moving towards an interface running on Linux.

• Windows Mobile from Microsoft, available for Smartphones and PDAs. Recent versions are supporting Exchange Server 2007, Outlook 2007, and Windows Vista.

• RIM BlackBerry operating system

• Palm OS developed by PalmSource

The most relevant software platform technologies and standards are outlined in the following.

Java Platform, Mobile Edition (J2ME )

Java Platform, Mobile Edition (Java ME platform) is a widespread technology in the mobile industry. It is the foundation for implementing core applications such as address books, messaging, or the mobile device user interface such in the case of the Symbian OS.

Location APIs, messaging, PIM functionality, Bluetooth and graphics acceleration are examples of features that the Java ME platform has standardized. The trend for new API's and abstractions is going on allowing access to and expanding set of functionality.

Multitasking is a key feature for Java ME technology. The necessary facilities and client infrastructure to allow multiple applications to run concurrently is introduced even for low-end devices with very limited hardware and OS support.


Synchronization Markup Language (SyncML)

SyncML (Synchronization Markup Language) is a platform-independent standard for information synchronization. The purpose of SyncML is to go beyond a limited vendor- or OS-specific syncronization system offering an open standard instead. Several companies support SyncML in their mobile software.

SyncML is not only a method to synchronize contact and calendar information between handheld devices and personal computer or network-based services. Support for push email, backup solutions and more general information synchronization purposes is provided.

All SyncML compatible device, system or service including web services can exchange data with SyncML over several types of connections (Wireless Internet, Bluetooth etc.)

Here’s a summary of some attractive features of SyncML:

Data type independence: more types of data can be synchronized

Network independence: several transport means can be used to transfer SyncML packages.

Self-containment: each SyncML package is self-contained

based on XML technology.




4.5.5 IP Multimedia Subsystem (IMS)

IP Multimedia Subsystem is a system consisting of a telecommunication IP network with an innovative call/session control layer. Starting from the IETF/Internet SIP protocol, the telecommunication community has built a full system named IMS (IP Multimedia Subsystem), which is an evolution of three standards:

• Internet SIP, specified by IETF (starting middle 90’)

• Mobile IMS, fully standardized by 3GPP (3rd Generation Partnertship Project ,finalized in 2001-2003, and still under enhancement)

• Fixed IMS, standardized by ETSI TISPAN (first release end 2005)

The key points of these standards are briefly summarized in the following table, where a state of the art of the specifications is also given.

Features IETF 3GPP TISPAN

Authentication YES only Framework

YES (USIM/ISIM) YES (USIM/IMS/NASS bundled/others)

Charging features No Full Full

SIP based call/session control YES only framework

YES YES

QoS control Basic Full on GPRS/UMTS

Only partially specified for generic IP accesses

Full for IPaccesses, still under

completition

Access network interfacing Proprietary Mobile+WLAN

Generic IP supported but

YES (xdsl)

Interconnection interfacing Proprietary YES YES

IP based transport YES YES YES

IP based terminals and applications

YES YES YES

Service supported IP multimedia IP multimedia IP multimedia

Standardization of the NO Voice call Voice call



telecommunication services (Under extension for multimedia calls)

PoC, Combinationals, IM, LBS

Table 1 - NGN standards related to IMS

A preliminary consideration is that IMS is a 3GPP standard intended for the Mobile network context, extending significantly the naked SIP IETF work made targeting free Internets. Through a general agreement in the telecommunication community it has been assumed as general reference solution, which is currently also applicable to fixed networks, with some changes and modifications made essentially in the TISPAN standardization framework.

Additionally the cable networks community has demonstrated a specific interest in extending the 3GPP specifications, to cope with the cable use case (release 8).

Regarding the development of solution applicable to the fixed and mobile case, it is difficult to predict when an IMS really capable to merge the two worlds will be available.

Currently the mobile 3GPP IMS solution is capable to control W-LAN and fixed accesses, but with the constraints of being based on Mobile IMS control, with mobile specific authentication and QoS control required also on the other accesses.

Additionally, IMS experiences some scalability problems in the mobile case. Today a fully IMS architecture for voice and data integration services is possible only in the fixed domain.

In the mobile domain IMS, due to constraints in the GPRS/UMTS always-on signalling and access radio resource allocation policy, the solution is not fully scalable and currently is limited to advanced services (combinational services, data, multimedia) reserved to a limited customer base.

A deeper presentation of the standard is available in Appendix 1 at subsection 5.3.

4.5.6 Internet Communication Standards

The Internet protocol suite

The Internet protocol suite is a collection of network protocols implementing the stack that constitutes the basic “building blocks” for the Internet. It is also known as TCP/IP from the names of the two major protocols defined in it: Transmission Control Protocol (TCP) and Internet Protocol (IP). Such suite can be described for analogy with the OSI model, that describes in a slightly different (and rigid) way the levels of the stack. The TCP/IP stack is probably closer to real-world standards than the OSI model. Every level solves a series of problems related to the transmission of data and provides services to the higher levels. The higher levels are more related to the end user whether the lower levels are closer to the physical transmission means.



In this section an overview of TCP/IP’s Application layer standards that are of relevance for eMOTION is provided.

A deeper presentation of the Internet protocol suite is available in Appendix 1 at subsection 5.1.

Hyper Text Transfer Protocol (HTTP)

HTTP is the acronym for Hyper Text Transfer Protocol and is the main system for the transmission of information on the web. HTTP protocol is currently maintained by the World Wide Web Consortium (W3C) and from its initial definition at the end of years '80 to most recent versions it constitutes together with the HTML language, the nucleus base of the “World-Wide initiative Web WWW global information”. Available standards are [IETF-HTTP 1.0, 1996] and [IETF-HTTP 1.1, 1999].


Hyper Text Transfer Protocol Secure (HTTPS)

HTTPS introduces some security features to HTTP by creating an encrypted communication channel between the client and the server. When such a channel is created, the communication is made using the HTTP protocol. This type of communication ensures that only the two parties involved have knowledge of the contents. It uses encryption mechanism such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS) ([IETF-HTTP TLS, 2000]).


Secure Sockets Layer / Transport Layer Security (SSL/TLS)

Secure Sockets Layer (SSL) is a protocol developed to carry out encrypted communications over the Internet enabling more secure communication to prevent, for example, falsification or tapping. It has been used as a basis for the development of the IETF standard protocol Transport Layer Security (TLS) ([IETF-TLS, 1999])

Key features of these technology are:

Authentication (every client establishes a certified, unique connection with the correct server)

Confidentiality in data transmission: after an initial handshake a private session key is defined to go along with the communication

Reliability: The transport level includes a message integrity control based on a MAC (Message Authentication Code) using secure hash functions. This allow to verify that no modifications have occurred during the transmission between client and server.

SSL/TLS are mainly used in HTTPS. Both protocols uses a public-key encryption method and certificates to verify the identity of the two ends involved in the communication.


Secure Shell (SSH)



Secure Shell or SSH is a network protocol that allows data to be exchanged over a secure channel. SSH has become a de-facto standard for remote administration of UNIX systems and network devices providing for such operations confidentiality and integrity of data. SSH uses public-key cryptography for authentication.

An SSH client program is typically used to establish connections to a remote server that runs a SSH daemon accepting those connections. Both are commonly present on most modern operating systems.

This is an open architecture providing considerable flexibility so that SSH can be used for a variety of purposes.


Domain Name System (DNS)

The Domain Name System (DNS) is a service used to resolve host names to IP addresses ([IETF-DNS, 1987]). This is of primary importance for the daily use of the Internet where the user has usually no knowledge about the IP of a resource and a well-known name has to be used instead.

DNS is also used for a reverse resolution (reverse DNS lookup): the operation of resolving host names from IP addresses.


Simple Mail Transfer Protocol / Post Office Protocol version 3 / Internet Message Access Protocol (SMTP/POP3/IMAP)

SMTP

Simple Mail Transfer Protocol (SMTP) is the standard protocol for Internet transmission of emails ([IETF-SMTP, 2001]). It’s a simple protocol that allow to specify multiple message addressees, verify their existence and deliver the message to them. SMTP allow to send messages and to make requests for messages to the server. For this, the client uses other protocols such as POP3 or IMAP. A limit of SMTP is the lack of any authentication mechanism for a sender. This may cause spam and the possibility to display a false sender name in the email. An extension to SMTP called “SMTP-AUTH” has been developed to cover these gaps.

POP3

Post Office Protocol version 3 (POP3) is a standard protocol used to retrieve e-mail from a remote server ([IETF-POP3, 1996]). To be read, a message has to be transferred to the local computer. POP3 works in clear. No encryption is provided.

IMAP

IMAP (Internet Message Access Protocol or Interactive Mail Access Protocol) ([IETF-IMAP, 2003]) is a communication protocol for the reception of emails with some differences from SMTP:

online and off-line access is provided: the client using IMAP, unlike POP3, can



remain connected to the server

multiple users can access the same mail box

MIME parts in a message can be addressed separately.

Server message attributes management is available (e.g. to know if a message has been already read)

Multiple mailbox access available

There is the possibility to perform searches on the server

Passwords can be encrypted.


File Transfer Protocol (FTP)

FTP stands for File Transfer Protocol and is a service that provides basics elements to share files between hosts ([IETF-FTP, 1985]).

SFTP (SSH File Transfer Protocol), or FTPS (FTP over SSL which adds SSL or TLS encryption to FTP) can be used to solve criticisms tied to some FTP security gaps ([IETF-FTP, 1997]).


Transmission Control Protocol (TCP)

Transmission Control Protocol (TCP) is the transport level protocol of the Internet Protocol Suite ([IETF-TCP, 1981]). Most part of Internet application are supported by TCP. It can be classified as a 4th level protocol in the OSI stack and it is usually combined with the IP network protocol. The combination is so common that sometimes TCP/IP is wrongly considered a unique protocol.

The combination of TCP and IP (which doesn’t offer any guaranty on packet delivery, delay, congestion) allow to establish a reliable bi-directional communication channel between two processes.


User Datagram Protocol (UDP)

UDP (User Datagram Protocol) is a packet-oriented transport protocol generally used in combination with the IP protocol ([IETF-UDP, 1980]).

Unlike TCP it doesn’t manage the process of sorting packets and the re-transmission of lost packets. It is a connectionless, unreliable protocol allowing, however, efficient performance for “light” or time-sensitive applications such as audio-video transmission.

Unlike TCP, UDP provides only basic transport services dispensing with those features that, although necessary for reliability, can introduce delays. If any reliability feature is required for the transmission of the information these will be implemented in a higher level protocol (application)




Simple Object Access Protocol (SOAP)

SOAP is a packaging standard, which sits on top of other transport and application layer standards of this chapter. It has been defined by W3C ([W3C-SOAP, 2007]).

SOAP Version 1.2 is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. It uses XML to define an extensible messaging framework providing a message construct that can be exchanged over a variety of underlying protocols, like HTTP, SMTP.

SOAP provides a distributed processing model which assumes a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries. The SOAP distributed processing model can support many message exchange patterns including but not limited to one-way messages, request/response interactions, and peer-to-peer conversations.

Though packaging of messages for web services can also be done by means of HTTP alone (for example by using the POST method), SOAP today is established as the web service packaging standard due to its flexible distributed processing model and its close relation to other main-stream web service technologies like UDDI (for discovery) and WSDL (for description) and their support by the main market players.

eMOTION should define new services using the SOAP framework.


4.5.7 Pronunciation Lexicon Specification (PLS)

This W3C recommendation ([W3C-PLS, 2006]) is currently in the state Last Call Working Draft.

Access the standard at: http://www.w3.org/TR/pronunciation-lexicon/

The accurate specification of pronunciation is critical to the success of speech applications. Most Automatic Speech Recognition (ASR) and Text-To-Speech (TTS) engines internally provide extensive high quality lexicons with pronunciation information for many words or phrases. To ensure a maximum coverage of the words or phrases used by an application, application-specific pronunciations may be required. For example, these may be needed for proper nouns such as placenames, roads and service operator names.

The Pronunciation Lexicon Specification (PLS) is designed to enable interoperable specification of pronunciation information for both ASR and TTS engines within voice browsing applications. The language is intended to be easy to use by developers while supporting the accurate specification of pronunciation information for international use.

Relevance

For the use of a pronunciation lexicon an eMOTION application service is responsible. With



this the definition of a pronunciation lexicon is not a central eMOTION service, but has a potential relevance for eMOTION.


4.5.8 Public Wireless Networks - GSM/GPRS/EDGE/UMTS

GSM, GPRS, EDGE, UMTS can be considered as different flavours of one single system, that is the word wide well known system used by more than 2.4 billion of subscribers all over the world.

Such technologies are substantially a pool of access technologies, each one based different functionalities in the radio access network, which are all commonly referring to a core network system, capable to control voice and connection oriented services, packet based services (including real time and broadband services), by means of two integrated complementary core networks, one circuit based (CS core network) and the other packet based (PS Core network).

Moreover advanced IP services control is included by means of a specific subsystem, the IMS, which is gaining popularity in the world of Telecommunication as the reference solution to provide to real time services on IP, not only for the mobile environment that has originally defined it, but also for the Fixed line and the Cable service operators.

Such core systems are also integrating platforms for the control of application services, ranging from traditional Intelligent networks (or better the mobile version CAMEL) to the more advanced distribute one, such as OSA / Parlay approach or the application enablers approach of the already mentioned IMS.

These systems are really native mobile systems, so they are extremely performant in terms of support of mobility, including high speed continuous mobility of the subscribers, such as the high speed trains that have recently reach new operative speed levels (and without the complex maglev features). Also in terms of ubiquity, at least basic voice and data services are substantially provided practically all over the world (over 220 countries and 860 networks).

The Broadband capabilities of the mentioned systems are reduced with respect to the broadband expectations of the fixed networks, but with the new UMTS enhancement already deployed in the most advanced countries (HSDPA/HSUPA), the speed has risen to real basic operative speeds of more of 2 Mbit/s peak per user, and to a potential of more than 10 Mbit/s. Further developments are ongoing for the SAE/LTE technology.


4.5.9 Speech Assessment Methods Phonetic Alphabet (SAMPA / X-SAMPA)

To represent the sounds of any spoken language a phonetic alphabet is used. A common



standard of a phonetic alphabet is the International Phonetic Alphabet (IPA). IPA uses letters and special symbols to represent the pronunciation of words.

The Speech Assessment Methods Phonetic Alphabet (SAMPA) is a computer-readable phonetic script using 7-bit printable ASCII characters, based on the International Phonetic Alphabet. SAMPA tables are valid only in the language they were created for. The tables of languages are not harmonised so there are conflicts between languages. The result of this problem is that SAMPA cannot be used as an ASCII representation of the general IPA alphabet. To solve this problem X-SAMPA was created, which provides one single table without language-specific differences.

More information about X-SAMPA is available at

http://www.phon.ucl.ac.uk/home/sampa/x-sampa.htm

Relevance

In the case that it is necessary to transport phonetic information within a eMOTION service the usage of X-SAMPA is a good possibility. An alternative may be the usage of Unicode characters.


4.5.10 Synchronized Multimedia Integration Language (SMIL)

The Synchronized Multimedia Integration Language (SMIL, pronounced "smile") enables simple authoring of interactive audiovisual presentations. SMIL is typically used for "rich media"/multimedia presentations which integrate streaming audio and video with images, text or any other media type. SMIL is an easy-to-learn HTML-like language, and many SMIL presentations are written using a simple text-editor.

For a more detailed description of the goals of the SMIL language, see the W3C Activity Statement (http://www.w3.org/AudioVideo/Activity.html) on Synchronized Multimedia; a regularly updated report to W3C members that is also available to the public.

More Information is available in the standard socument [W3C-SMIL2, 2005] at http://www.w3.org/TR/SMIL/

Also available is a working draft of a new SMIL 3.0 version ([W3C-SMIL3, 2007]) at http://www.w3.org/TR/SMIL3/

Relevance

Though not directly connected to eMOTION it is a very good extension for POI standards to enrich contents with multimedia component on mobile devices. SMIL 3.0 will be a new multimedia standard for all web services. Content Providers can easily exchange layout data with this format.




4.5.11 Speech Synthesis Markup Language specification (SSML)

This W3C recommentation is known as the Speech Synthesis Markup Language specification (SSML) and is based upon the JSGF and/or JSML specifications, which are owned by Sun Microsystems, Inc., California, U.S.A.

Access the standard document [W3C-SSML, 2004] at:

http://www.w3.org/TR/speech-synthesis/

SSML is part of a larger set of markup specifications for voice browsers developed through the open processes of the W3C. It is designed to provide a rich, XML-based markup language for assisting the generation of synthetic speech in Web and other applications. The essential role of the markup language is to give authors of synthesizable content a standard way to control aspects of speech output such as pronunciation, volume, pitch, rate, etc. across different synthesis-capable platforms.

The intended use of SSML is to improve the quality of synthesized content.

Relevance

As in the case of VoiceXML, SSML is a possible addition to eMOTION application services.


4.5.12 Voice Extensible Markup Language (VoiceXML)

VoiceXML is a standard format from W3C. It is designed for creating audio dialogs that feature synthesized speech, digitised audio, recognition of spoken and DTMF key input, recording of spoken input, telephony, and mixed initiative conversations. Its major goal is to bring the advantages of Web-based development and content delivery to interactive voice response applications.

The latest version of the standard document [W3C-VoiceXML, 2004] is available at: http://www.w3.org/TR/voicexml20/

Relevance

All Web Services which require user interactions in form of submission, confirmation or requests can make use of VoiceXML to enable Voice commands and automated replies/reactions from the underlying systems. So VoiceXML is a possible addition to eMOTION application services.




4.5.13 Worldwide Interoperability for Microwave Access (WiMAX)

The IEEE 802 LAN/MAN Standards Committee (or IEEE Project 802) develops LAN and MAN standards, mainly for the lowest 2 layers of the Reference Model for Open Systems Interconnection (OSI). In the framework of the IEEE Project 802, the IEEE 802.16 Working Group on Broadband Wireless Access Standards develops standards and recommended practices to support the development and deployment of broadband Wireless Metropolitan Area Networks (Wireless MAN).

The Working Group initial interest was the 10-66 GHz and in the design of the OSI Physical layer specification for this band Line-Of-Sight propagation was deemed a practical necessity. Due to the short coverage range caused by the rain attenuation, the main areas of interest are the urban and the metropolitan where there is a high subscriber density, while the high bandwidth availability allows the provisioning of high capacity services to business subscribers.

In order to expand the field of application of Broadband Wireless Access, almost contemporarily the IEEE 802.16 Working Group developed a new version of the standard, named 802.16a and approved at the beginning of 2003, for the bands in the range 2-11 GHz. Design of the Physical layer is driven by the need for Non-Line-Of-Sight operation in order to deploy these systems also in suburban and rural areas and to reduce the equipment cost for the residential market.

WiMAX (Worldwide interoperability for Microwave Access) is today the user-friendly name associated with IEEE 802.16a/REVd/ e standards. Two bodies drive the standardization of the 802.16 solutions: IEEE802.16 working group and the WiMAX forum initiative.


4.5.14 Wireless Communication Protocols

The main protocol used in wireless communications is certainly IP. When TCP/IP was adopted in the 1980s, it relied on a two-level addressing scheme. At the time this offered adequate scalability. Unfortunately, the designers of TCP/IP could not have predicted that their protocol would eventually sustain a global network of information, commerce, and entertainment.

The Internet has been facing the depletion of IPv4 address space since the early 90s. The registries (RIPE-NCC, ARIN, APNIC) responsible for global IP address allocation have enacted strict policies to help to minimize the problem, but the Internet continues to grow exponentially. Over the past two decades, numerous extensions to IPv4 have been developed to improve the efficiency with which the 32-bit address space can be used. Two of the more important of these are subnet masks and classless interdomain routing (CIDR).

In the meantime Network administrators have increased the use of private addressing and, as a consequence the relying on network address translation (NAT), technologies to deploy networks.



Today these actions are fully mature and have demonstrated that are capable to sustain the “big Internet” evolution. Nevertheless managing those NAT devices is an additional effort task and, by their nature, some applications (few), such as IPsec, simply cannot work across a NAT device.

Meanwhile, an even more extendible and scalable version of IP, IP Version 6 (IPv6), has been defined and developed. IPv6 is a natural evolution from IPv4 and attempts to address many of the older protocol’s shortcomings, IPv6 uses 128 bits rather than the 32 bits currently used in IPv4. IPv6 provides 640 sextrillion addresses.

A deeper presentation of the standards is available in Appendix 1 at subsection 5.5.

4.6 Other Standards

4.6.1 Dynamic and Distributed Adaptation of scalable multimedia content in a context-Aware Environment (DANAE)

DANAE (Dynamic and Distributed Adaptation of scalable multimedia content in a context-Aware Environment) proposes to address the dynamic and distributed adaptation of scalable multimedia content in a context-aware environment. Its objectives are to specify, develop, integrate and validate in a testbed a complete framework able to provide end-to-end quality of (multimedia) service at a minimal cost to the end-user.

Information is available at http://danae.rd.francetelecom.com/.

Relevance

This is out of scope for eMOTION, so it is not described in detail.

4.6.2 Disability Discrimination Act (DDA)

The UK Department for Transport commissioned a research project to enable an assessment of the travel information needs of disabled people. This is in line with the Government’s current emphasis on reducing the social exclusion of certain groups of people, including disabled people. The social inclusion agenda is supported by the Disability Discrimination Act (DDA) 1995, which is essentially a body of civil rights legislation that gives disabled people the right to a whole range of goods, facilities and services.

The final report of the research project, along with Transport Direct’s disability policy, is available at http://www.dft.gov.uk/transportdirect/research/accessibilityusability.

Relevance

eMOTION does not primarily research into application service issues, so this standard is out of scope as far as the impacts on delivery of information to end-users is concerned.



The DDA does not define the information needs of those with disabilities. However certain information items are important to allow those with disabilities to access transport services. Therefore the content of the information available through eMOTION is significantly affected and the eMOTION data model has to consider these aspects.

Transport Direct’s disability policy includes a recommendation that: “Transport Direct should strive to provide information on such items that are essential to disabled travellers and can be provided at reasonable cost”. Priority information items identified in the research report were:

• Availability of assistance for disabled persons at infrastructure points

• Accessibilty of infrastructure and vehicles

• Availability of accessible taxis

Such information items may be found in standards covered in this report, and the eMOTION model should seek to take advantage of these information items where they are available.

A more detailed survey of user needs for elderly and disabled travellers was carried out by the TELSCAN project. Information may be found at:

http://cordis.europa.eu/telematics/tap_transport/research/projects/telscan.html

Though these matters will have to considered in modelling, the issue has not been investigated in depth, because legal matters are not easily covered by the objective and structure of the current analysis (D5).

4.6.3 European ITS Framework Architecture / Framework Architecture Made for Europe (EITSFA / FRAME)

The European ITS Framework Architecture (EITSFA) – also known as FRAME (FRamework Architecture Made for Europe) provides a framework for the development and deployment of working and workable ITS solutions within the European Union.

Information is available at http://www.frame-online.net/

Relevance

EITSFA is a ‘meta-standard’ for developing Eurpoean ITS architectures. eMOTION is unique by going the ISO TC211 way, so it does not fit to the framework. Therefore EITSFA is not described in detail.

4.6.4 Highways Agency Logging Environment (Halogen)

Halogen (Highways Agency Logging Environment) is the UK Highways Agency central source for HATMS (Highways Agency Traffic Management Systems) logged data. It provides a Secure storage of HATMS logs, a centralised log enquiry and reporting facility, timely information on HATMS Logging System Status, and delivery channels of historic and real-time information derived from the received Logs.



Information is available at http://www.trafficxml.org.uk/halogenweb/jsp/index.jsp

Relevance

This will not add new aspects to the eMOTION model, so it is not described in detail.

4.6.5 INFOPOLIS 2

INFOPOLIS 2 (Advanced passenger information for European citizens of 2000) improves travellers' ability to access electronic sources of information on all modes of transport, by offering transport operators guidelines for good presentation of information.

Information is available at http://www.ul.ie/~infopolis/ and http://cordis.europa.eu/telematics/tap_transport/research/projects/infopolis2.html, e.g. [INFOPOLIS 2, 1999]

Relevance

INFOPOLIS 2 has an application oriented point of view, which is not in the eMOTION scope, so it is not described in detail.

4.6.6 Simple Network Management Protocol (SNMP)

The Simple Network Management Protocol (SNMP) is defined by the Internet Engineering Task Force (IETF) as part of the Internet Protocol Suite. It is used to administrate and to monitor arbitrary network-attached devices. With SNMP the system configuration of a network-attached device can be described in the form of variables, which can be queried and in some cases set by managing applications.

There are three different version of the SNMP in use. Since 2004 SNMPv3 is the current standard version of SNMP, earlier versions are considered obsolete by the IETF. SNMPv3 is defined by RFC 3410 - RFC 3418, which can be found at http://www.ietf.org/rfc.html .

Relevance

It is important, that relevant parts of the eMOTION framework can be monitored, so that malfunctions can be detected. With this the SNMP is a relevant part of the eMOTION framework.


4.6.7 SYSTRANLinks

SYSTRANLinks is a proprietary solution of a translation service offered by SYSTRAN. The main purpose of SYSTRANLinks is to translate web pages. High valued solutions of SYSTRANLinks ('SYSTRANLinks Silver', 'SYSTRANLinks Gold') offered an API which can be used to initiate a translation process. With this not only web pages can be translated, also



other formats, e.g. plain text, are possible.

Informations about SYSTRANLinks are available at http://www.systran.co.uk/index/Products/Online-Services/SYSTRANLinks

Relevance

SYSTRANLinks is an opportunity to translate text via a web service, but it uses no standard API, so it does not really fit the eMOTION requirements.


4.6.8 OASIS Translation Web Service (Trans-WS)

The OASIS Translation Web Service (Trans-WS) provides an encapsulation of all the information which is needed by publishers of content to be translated so that they are able to automatically connect to and use the services of any translation vendor, over the Internet, without any previous direct communication between the two.

The Translation Web Service is under development, the last specification document available is [OASIS-TransWS, 2007]. The specification document of the standard is focused on specifying the calls needed to use Web services for the submission and retrieval of translation and other work.

It is available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=trans-ws

Relevance

The main purpose of the standard is to support localisation projects. Machine Translation, which is relevant in the context of eMOTION, is not described in the standard specification. With this it is still unclear whether the standard will support translation as needed for eMOTION.


4.6.9 Transit Communications Interface Profiles (TCIP)

TCIP (Transit Communications Interface Profiles) is a suite of data interface standards for the US transit industry. It is used as part of the US National ITS Architecture.

Information is available at http://www.apta.com/about/committees/rsrchtec/tcip/

Relevance

TCIP is an US standard and with this not relevant for eMOTION, so it is not described in detail.



4.6.10 Web Accessibility Initiative (WAI)

The WAI (Web Accessibility Initiative) develops strategies, guidelines, and resources to help make the Web more accessible to people with disabilities.

Information is available at http://www.w3.org/wai

Relevance

eMOTION does not primarily research into application service issues, so this standard is not described in detail.

4.6.11 OASIS Web Services Business Process Execution Language (WS-BPEL)

The OASIS Web Services Business Process Execution Language (WS-BPEL) specifies the common concepts for a business process execution language which forms the necessary technical foundation for multiple usage patterns including both the process interface descriptions required for business protocols and executable process models.

In this way it is less a service but rather a modelling language for controlling business processes.

WS-BPEL is based on the business process language published in the Business Process Execution Language for Web Services (BPEL4WS) specification. Version 2.0 of WS-BPEL ([OASIS-WSBPEL, 2007]) has been approved as an OASIS Standard in April 2007 and is a further development of the BPEL4WS (Business Process Execution Language for Web Services), which was developed outside the OASIS consortium.

The WS-BPEL 2.0 specification is available at http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf ,

the technical committee of WS-BPEL can be found at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel

Relevance

From the analysis it has not become clear whether eMOTION has indeed a requirement for Workflow Support or whether automated invocations of services will be performed within Application Service environments.




5. Analysis of Available Content

Referring to the results of WP1 and WP2 the required and existing data – including “static” network and topographic data – will be described in a catalogue. It is analysed with respect to the following issues:

• Accessibility

• Fitness-for-use

• Closeness to content standards analysed in chapter 2.

The last item is of great importance, because the eMOTION approach requires that the data, though being of different provenance and provided from distributed sources, will need to be of uniform semantics. This means that information standards will have to be harmonised in the process of providing the data by services.

“Fitness-for-use” would actually also encompass the quality aspect. As it turned out, however, quality measures, like up-to-dateness, accuracy, schema conformance, etc., are usually not available generally. We therefore omitted this aspect to avoid perhaps misleading comparisons between the various datasets on that sensitive issue.

The available content material gathered in D1 largely already provided all necessary information. Instead of simply repeating the information from D1 in this place, it was decided to concentrate on material which might play a role in the “Proof of Concept” part of eMOTION. Therefore the coverage might seem a bit “patchy”, but this is intended.

5.1 Road Network Data

Name (Provider / Service) Tele Atlas

URL (of Provider and/or Web Service)

www.teleatlas.com

Geographic Extent (Country/Countries, City)

Global

Accessibility/Fitness-for-use

- available media

CD, DVD, B2B Web Service

- usage restrictions License conditions

- costs Depending on application

Closeness to content standards analysed in D5

GDF



Name (Provider / Service) Navteq

Description Road network data


www.navteq.com


Global


- available media

CD, DVD

- usage restrictions License conditions

- costs Depending on application


GDF

Road network data from public road authorities: see Deliverable D1.

5.2 Public Transport Network Data

Name (Provider / Service) ÖBB – Austrian Federal Railways / SUPERNOVA

Description Network description for the purpose of traffic flow simulation. Relationship between stoppoints


www.oebb.at, service is not public


Austria, Europe in a larger scale, based on licensed network data of a 3rd party.


- available media

unknown, in principle as a dump of the database, but no interface implemented

- usage restrictions only internal use for simulation of traffic flow, other use is not foreseen

- costs not relevant, because no usage possible


None. Uses WGS 84 as a coordinate reference system.

Name (Provider / Service) ÖBB – Austrian Federal Railways / Vertriebsstellenbeschreibung – description of outlets



Description Detailed information about stoppoints including every kind of facilities and contact persons.

examples:

Name of stoppoint, location (address), lines, shops, ticket sale, opening hours, contact persons, toilets, elevators, parking facilities, assistance for disabled persons, lounges, etc.


www.oebb.at, service is not public


Austria


- available media

unknown, maybe as a dump of the database

- usage restrictions only internal use, other use is not foreseen, but can be negotiated.

- costs subject of negotiations


unknown relationship to standards

Name (Provider / Service) NaPTAN

Description An UK nationwide system for uniquely identifying all the points of access to public transport in the UK. There are over 346,000 NaPTAN points recorded across the UK and NaPTAN is thought to be 99% complete. consequently updated database, 3rd update was in 2006


http://www.naptan.org.uk


United Kingdom


- available media

Download

- usage restrictions Use of the NaPTAN data is subject to license by the Department of Transport. Public Sector and Commercial Licences are available. (http://www.naptan.org.uk/termsOfUse.htm )

- costs Fees may be charged for Commercial Licenses.




NaPTAN

Name (Provider / Service) National Public Transport Gazetter (NPTG)

Description NPTG consists of the following elements:

o A standard for identifying and naming localities.

o A database of all the localities points in the UK.

o An XML Schema for exchanging localities as XML documents content. All or part of the database may be exchanged in this format.

o An exchange format for exchanging localities as csv files


www.nptg.org.uk


United Kingdom


- available media

see NaPTAN

- usage restrictions see NaPTAN

- costs see NaPTAN


NaPTAN

5.3 Traffic Flow Data

Name (Provider / Service) Traffic flow data for freeway network and main roads

Description Dynamic data about the current or forecast state of traffic flow. Different types of data possible like Level of Service (LoS) data, raw data like velocity, traffic volume or traffic density, link level travel time




Providing institution:

Belgium: Centre Perex (OTAP)

Germany: Verkehrszentrale (TIC) Hessen (OTAP and DATEX)

TIC Bavaria (DATEX)

TIC Berlin (DATEX)

The Netherlands: TIC Netherlands (OTAP)

UK: Q-Miss (OTAP)

France: Autoroutes GIE (OTAP, DATEX)

Spain: Servei Català de Trànsit (SCT, regional road traffic administration from Catalonia, Spain) (DATEX)


freeway network and main road network


- available media

DATEX-TRAILS-, OTAP-XML-, DATEX 2-XML-files

- usage restrictions At the moment for free for service providers, registration necessary

- costs -


All the mentioned data models are precursors of DATEX 2, at the moment DATEX 2 nodes are not in operation (only pilots)

5.4 Traffic Messages

Name (Provider / Service) Traffic messages

Description Traffic messages about planned (planned road closures or road works) and unexpected events (incidents, congestion)





Belgium: Centre Perex (OTAP)

TIC Antwerpen (DATEX)

Germany: Verkehrszentrale (TIC) Hessen (OTAP and DATEX)

TIC NRW (Northrhine-Westphalia) (DATEX)

TIC Bavaria (DATEX)

TIC Berlin (DATEX)

The Netherlands: TIC Netherlands (OTAP)

UK: Q-Miss (OTAP)

France: Autoroutes GIE (OTAP)

TIC Bordeaux/Metz (DATEX)

Spain: Servei Català de Trànsit (SCT, regional road traffic administration from Catalonia, Spain) (DATEX)



- available media

DATEX-TRAVIN-, OTAP-XML-, DATEX 2-XML-files


- costs -


All the mentioned data models are precursors of DATEX 2, at the moment DATEX 2 nodes are not in operation (only pilots)

Name (Provider / Service) Traffic messages from German “Verkehrswarndienst”

Description Traffic messages about planned (planned road closures or road works) and unexpected events (incidents, congestion) in Germany



Nationale Meldestelle (TIC NRW in Cologne)

Landesmeldestellen (federal centres) in every federal staat of Germany


Whole Germany- mainly messages for the freeway network but also regional information on main roads




- available media

RDS-TMC-messages


- costs -


Close to Alert-C and DATEX 2 standard

Name (Provider / Service) Traffic messages

Description Traffic messages about planned (planned road closures or road works) and unexpected events (incidents, congestion) in Europe


ERIC – European Road Information Centre (automobile clubs)

www.eric3000.com


European freeway network


- available media

RDS-TMC

- usage restrictions For automobile clubs and service provider, registration necessary

- costs Not for free but rate unknown


Close to Alert-C

5.5 Weather Data

Name (Provider / Service) German Weather Service ( Deutscher Wetterdienst DWD)



Description Data of ca. 500 Road Weather Remote Stations on German Highways from Road Weather Information System (SWIS) Different equipped location, rough-Data such as: - Airtemperature and –humidity - Precipitation Data - Wind Data - Road Surface Data (Temperatur, Road Surface condition etc.) Location Referenced by WGS84 and Road name and Position (km)


www.dwd.de (Provider Homepage)


Federal Republic of Germany Federal Highways


- available media

- FTP

- usage restrictions Only for Weather Services and Content Operators Restricted usage – content owner is the Federal Highway Administration

- quality Depending on Federal Country – sometimes not reliable enough – partly poor maintained equipment

- costs Depending on license conditions


BUFR and CREX

Name (Provider / Service) German Weather Service ( Deutscher Wetterdienst DWD)

Description Forecast products for traffic and Road Winter maintenance - general 3 day forecast of road condition (text format) for a specific climate area - detailed 24h forecast of road and atmospheric condition for a specific climate area - Precipitation radar bitmap data (2x2km) every 15 minutes composite data out of 11 Radar Stations


www.dwd.de (Provider Homepage)


Federal Republic of Germany




- available media

- FTP

- usage restrictions Only for Content Operators and winter maintenance organisations

- quality Forecast 24h stated with > 80% reliability. No objective investigations known.



BUFR and CREX

Name (Provider / Service) Meteomedia AG, Swäbrig, Switzerland

Description Precipitation Forecast for 2h based on Radar Graphic Bitmap Bitmap geogr. referenced with 2x2 km resolution (GIF)


www.meteomedia.ch (Provider Homepage)


Federal Republic of Germany, Switzerland, Austria


- available media

- FTP / XML

- Internet

- usage restrictions Only for Contractors/Customers

- quality Objective investigations not yet available



BUFR

Name (Provider / Service) MC-Wetter GmbH, Berlin, Germany, Meteogroup

Description Road Weather Content and Products for winter maintenance purposes: - general Ice-Warning and forecast for a specific area - detailed Ice-Warning and forecast for a specific location - Precipitation radar forecast (2h) bitmap - Road Weather remote station data on a specific location on the road




www.glaette24.de (Service Homepage)


Federal Republic of Germany, optional other European countries Netherlands, Belgium, France, Switzerland, Austria, Europe wide


- available media

- http : /Internet

- FTP / XML (if required)

- usage restrictions Only for subscriped Customers


- costs Price list available


BUFR

Name (Provider / Service) Cooperation: MC-Wetter GmbH, Berlin, Germany, Meteogroup and micKS MSR GmbH, Fellbach, Germany

Description Road Weather Content for traffic information services: - ALERT-C messages


www.mc-wetter.de (Provider Homepage) www.micks.de (Provider Homepage)


Federal Republic of Germany, optional other European countries Netherlands, Belgium, France, Switzerland, Austria, Europe wide


- available media

- Internet

- FTP / XML

- usage restrictions Only for subscriped Customers (Service Providers)


- costs Price list available


RDS-TMC, ALERT-C, XML

Name (Provider / Service) Magyar Közut Kht. (General Road Administration of Hungary)



Description Road Weather Data from Remote Station on National Roads at ca. 200 locations - based on the UTMET Systems. Each station provides the following data: - Airtemperature and –humidity - Precipitation - Road Surface condition and Temperature Location referenced by WGS84 and Road Type and position


Utmet.kozut.hu


Hungary National Roads, Highways


- available media

- http : / Internet

- usage restrictions Only for authorized users

- quality Availability 97% per Year, Reliability of atmospheric data – high quality Reliability of road condition – medium quality

- costs Not yet stated


BUFR

Name (Provider / Service) Mowis GmbH, Lenzing, Austria

Description Dynamic Traffic Weather Forecast (2 ...3h) Information and Warnings - Precipitation, snowfall and Aquaplaning - fog / Visibility - Ice Warnings - Wind warnings Referenced on specific locations (WGS84) ca. 120000 locations. 1h Update


www.mowis.com


Austria other European countries optional




- available media

- http : / Internet

- SMS, WAP

- RDS/TMC

- usage restrictions Only for subscribed users

- quality No objective investigations known

- costs Not known


RDS/TMC

Name (Provider / Service) Road and Motorway Directorate of the Czech Republic (RSD)

Description Road Weather Data from Remote Station on National Roads and Highways. Different equipped stations providing the following data: - Airtemperature and –humidity - Precipitation - Wind - Visibility (partly) - Road Surface condition and Temperature Location referenced by WGS84 and Road Type and position Data Format used: SH70


www.rsd.cz (Provider Hompage)


Czech Republic National Roads, Highways


- available media

- http : / Internet

- Radio, Television

- usage restrictions Only for authorized users

- quality No objective investigations known

- costs Not yet stated




5.6 Public Transport

Name (Provider / Service) GTT Turin

Description Information for Public Transport Service:

Bus network (lines, stops)

Bus Timetable

Estimated Passing Times for a Bus on a selected stop

Information on fares

GTT Railway timetable and network information

Information on Parking (localization, fares, free places)

Information on road works


http://www.5t.torino.it/5t/it/arriviinfermata


City of Turin


- available media

Web Access

- usage restrictions free

- costs probable free


Unknown relationship to standards

Name (Provider / Service) AMT – Azienda Mobilità e Trasporti S.p.A.

Public transport service data

Description Information for Public Transport Service Users:

Lines, stops, timetable and fares information for:

Fixed service (Buses)

Flexible service (Small buses)

Dedicated services (e.g. the Airport-City service)

Underground

Funicolar Railway




www.amt.genova.it


City of Genoa


- available media

CD ROM




unknown relationship to standards

Name (Provider / Service) AMT – Azienda Mobilità e Trasporti

City of Genua / Public transport service data

Description Information for Public Transport Service:

Lines, stops, timetable and fares information for:

Fixed service (Buses)

Flexible service (Small buses)

Dedicated services (e.g. the Airport-City service)

Underground

Funicolar Railway


http://www.amt.genova.it


City of Genua


- available media

Web Access




Unknown relationship to standards

Name (Provider / Service) ATOC Rail Settlement Plan



Description Data feed information for the UK rail network. Separate feeds for Fares, Timetables, Routes and Additional Data


http://www.atoc.org/


United Kingdom


available media

CD delivery (monthly or weekly update) or FTP Access (monthly, weekly or daily).

usage restrictions Subject to Licence. Details available at http://www.atoc.org/rsp/Data_Feeds/03_Conditions.asp

costs Detailed information on charging available from http://www.atoc.org/rsp/Data_Feeds/04_Cost.asp


Uses RJIS as described in the Appendix

5.7 Parking

Name (Provider / Service) Static and dynamic parking data

Description Static data about parking facilities (e.g. tariffs, opening times, additonal services) and dynamc data about the current and forecasted occupancy of parking facilities


Data provided Traffic management centres of the cities

German wide parking information service powered by BMW and ADAC (www.parkinfo.com)

Actualisation of data 1 up to 15 minutes.


Services cover in most cases one city or a conurbation in Germany.

Parkinfo.com is German national service.


- available media

www.parkinfo.com: interface developed by BMW

local parking guidance systems: interfaces provided by manufacterer of PGS

parkinfo.neuss.de, parkinfo.wuppertal.de: OGC-WMS

- usage restrictions n/a



- costs n/a


Data models are in most case in proprietary format

5.8 POI and other additional data

Name (Provider / Service) Tele Atlas

Description


www.teleatlas.com


World wide


- available media

CD, DVD, B2B Web service

- usage restrictions License agreements

- costs Depending on type of use of data and application functionalities


ISO14825: GDF - Geographic Data Files

Name (Provider / Service) Navteq

Description


www.navteq.com


Europe


- available media

DVD, CD

- usage restrictions Oracle, Shape-file, GDF-AR, GDF-AS

- costs business model dependant





Name (Provider / Service) Czech office for surveying, mapping and cadastre (COSMC)

Description


www.cuzk.cz


national (Czech Republic)


- available media

CD, DVD, html - data are offered by Geoportal of COSMC, http://geoportal.cuzk.cz/

- usage restrictions restrictions are given by licence contract about application of data

- costs free of charge within the state administration

for commercial or private use, the data are provided for a charge


not known

Name (Provider / Service) Central European Data Agency a.s.

Description


www.ceda.cz


national (Czech republic)

the scale of the processed data is mainly focused on POI close to highways, speedways, roads of the 1st class and the cities above 10 000 inhabitants


- available media

CD

- usage restrictions not known

- costs data are provided for a charge



Name (Provider / Service) Czech Statistical Office



Description


www.czso.cz


Czech republic


- available media

CD, I-net (e-mail)

- usage restrictions no restrictions, except that all data are offered on CD, partial data sets based on user demands mostly through I-net

- costs free of charge within the state administration

for commercial or private use, the data are provided for a charge


not known – data are offered on .dbf eventually on .xls format

5.9 Map Data

Name (Provider / Service) EuroGlobalMap and EuroRegionalMap by EuroGeographics

Description EuroGlobalMap v1.1 is a digital topographic dataset that covers Europe at the scale 1:1 Million. It is seamless and harmonised data and is produced in cooperation by the National Mapping and Cadastral Agencies of Europe, using official national databases.

EuroRegionalMap is a topographic reference dataset at the scale 1:250 000.

Contents: Administrative boundaries, Hydrography, Transport, Settlements, Elevation, Named location (geographical names)


http://www.eurogeographics.org/eng/04_products_globalmap.asp

http://www.eurogeographics.org/eng/04_products_regionalmap.asp


EuroGlobalMap: Europe (35 European countries)

EuroRegionalMap: France, Germany, Belgium, Luxemburg, Denmark, Ireland, Northern Ireland, (is currently being extended)


- available media

CD-ROM, DVD, on-line download



- usage restrictions Licence agreement

- costs Cost examples:

EuroGlobalMap: Single user licence for 2 years: € 3.354

EuroRegionalMap: Single user licence for 2 years and the countries Belgium, Luxembourg, Denmark, Germany, France: € 18.574


none

Name (Provider / Service) InfoTerra

Description


http://www.infoterra-global.com/infoterra_global1.htm


Infoterra, a leading provider of geo-information products and services, delivers reliable geospatial knowledge to customers worldwide - when and where they need it.


- available media

- usage restrictions

- costs


More data is listed in Deliverable D1 subsection 4.3.9.



6. Literature

[BUFRCREX, 2002a] "Guide to WMO Table Driven Code Forms: FM 94 BUFR and FM 95 CREX - Layer 1: Basic Aspects of BUFR and CREX and Layer 2: Functionality and Application of BUFR and CREX", WMO, 2002.

[BUFRCREX, 2002b] "Guide to WMO Table Driven Code Forms: FM 94 BUFR and FM 95 CREX - Layer 3: Detailed Description of the Code Forms", WMO, 2002.

[CEN-IFOPT, 2007] "Technical Specification (TC278WG3 SG6): Road Traffic and Transport Telematics – Public Transport – Identification of Fixed Objects in Public Transport", Technical Committee CEN/TC 278, 2007.

[DATEX 2 EC, 2005] "DATEX II - EXCHANGE MECHANISM", Deliverable 4.1, Document Number D2_4.1v1.01, European Commission DG TREN, 2005.

[DATEX 2 EC, 2006a] "DATEX 2 V1.0 - USER GUIDE", Document version: 1.0, European Commission, Directorate General for Transport and Energy, 2006.

[DATEX 2 EC, 2006b] "DATEX 2 V1.0 EXCHANGE - PLATFORM SPECIFIC MODEL", Document version: 1.0, European Commission, Directorate General for Transport and Energy, 2006.

[DATEX 2 EC, 2006c] "DATEX 2 V1.0 - MODELLLING METHODOLOGY", Document version: 1.0, European Commission, Directorate General for Transport and Energy, 2006.

[DATEX 2 TC, 2006] "DATEX 2 - MIGRATION STUDY ISSUE I/2005, ARTS + CORVETTE EuroRegional Projects", DATEX Technical Committee, Work Package 6, Deliverable D2_WP6_Migration Study_V1.4.doc, 2006.

[DELFI, 2006] "Report on the current status of the DELFI-system implementation", DELFI Documentation, Version 4.02, Contents by the Partners of DELFI, 2006.

[DfT-NaPTAN, 2005] "NPTG and NaPTAN Schema Guide.Release 2.1", Department for Transport UK, 2005

[DfT-UTMC TS003, 2005] “TS003:2005 - The UTMC Framework Technical Specification”, Department for Transport UK, 2005



[DfT-UTMC TS004, 2007] "TS004.003:2007 - UTMC Objects Registry”, Department for Transport UK, 2007

[Euroroads, 2006] "EuroRoadS Final specification of core European road data", Deliverable D6.5, Torsten Svärd, 2006.

[IETF-DNS, 1987] "Domain Names - Implementation and Specification" - RFC 1035, Internet Engineering Task Force - Network Working Group, November 1987.

[IETF-FTP, 1985] "File Transfer Protocol" - RFC 765, Internet Engineering Task Force - Network Working Group, October 1985.

[IETF-FTP, 1997] "FTP Security Extensions" - RFC 2228, Internet Engineering Task Force - Network Working Group, October 1997.

[IETF-HTTP 1.0, 1996] "Hypertext Transfer Protocol -- HTTP/1.0" - RFC 1945, Internet Engineering Task Force - Network Working Group, May 1996.

[IETF-HTTP 1.1, 1999] "Hypertext Transfer Protocol -- HTTP/1.1" - RFC 2616, Internet Engineering Task Force - Network Working Group, June 1999.

[IETF-HTTP TLS, 2000] "HTTP Over TLS" - RFC 2818, Internet Engineering Task Force - Network Working Group, May 2000.

[IETF-IMAP, 2003] "Internet Message Access Protocol - Version 4rev1" - RFC 3501, Internet Engineering Task Force - Network Working Group, March 2003.

[IETF-POP3, 1996] "Post Office Protocol - Version 3" - RFC 1939, Internet Engineering Task Force - Network Working Group, May 1996.

[IETF-SMTP, 2001] "Simple Mail Transfer Protocol" - RFC 2821, Internet Engineering Task Force - Network Working Group, April 2001.

[IETF-TCP, 1981] "Transmission Control Protocol Specifications" - RFC 793, Internet Engineering Task Force - Network Working Group, September 1981.

[IETF-TLS, 1999] "The TLS Protocol Version 1.0" - RFC 2246, Internet Engineering Task Force - Network Working Group, January 1999.

[IETF-UDP, 1980]



"User Datagram Protocol" - RFC 768, Internet Engineering Task Force - Network Working Group, August 1980.

[INFOPOLIS 2, 1999] "INFOPOLIS 2 – D3 – Needs of Travellers: an Analysis Based on the Study of their Tasks and Activities"; N. Lecomte, R. Patesson, P. Steinberg, S. Kotituomo, F. Canoz, E. Hochede, and T. Porombka; September 1999.

[ISO 14819-1, 2003] "ISO 14819-1:2003 Traffic and Traveller Information (TTI) -- TTI messages via traffic message coding -- Part 1: Coding protocol for Radio Data System -- Traffic Message Channel (RDS-TMC) using ALERT-C", International Organization for Standardization (ISO), 2003.

[ISO 14819-2, 2003] "ISO 14819-2:2003 Traffic and Traveller Information (TTI) -- TTI messages via traffic message coding -- Part 2: Event and information codes for Radio Data System -- Traffic Message Channel (RDS-TMC)", International Organization for Standardization (ISO), 2003.

[ISO 14819-3, 2004] "ISO 14819-3:2004 Traffic and Travel Information (TTI) -- TTI messages via traffic message coding -- Part 3: Location referencing for ALERT-C", International Organization for Standardization (ISO), 2004

[ISO 14819-6, 2006] "ISO 14819-6:2006 Traffic and Traveller Information (TTI) -- TTI messages via traffic message coding -- Part 6: Encryption and conditional access for the Radio Data System -- Traffic Message Channel ALERT C coding", International Organization for Standardization (ISO), 2006

[ISO 14825, 2004] "ISO 14825:2004 Intelligent transport systems -- Geographic Data Files (GDF) -- Overall data specification", International Organization for Standardization (ISO), 2004.

[ISO 17572, 2007] "ISO/CD 17572-3 Intelligent Transport Systems (ITS) -- Location Referencing for Geographic Databases – Part 3: Dynamic Location References (Dynamic Profile)", International Organization for Standardization (ISO), 2007

[ISO 18234-4, 2006] "ISO/TS 18234-4:2006 Traffic and Travel Information (TTI) -- TTI via Transport Protocol Expert Group (TPEG) data-streams -- Part 4: Road Traffic Message (RTM) application", International Organization for Standardization (ISO), 2006

[ISO 18234-5, 2006] "ISO/TS 18234-5:2006 Traffic and Travel Information (TTI) -- TTI via Transport Protocol Expert Group (TPEG) data-streams -- Part 5: Public Transport Information (PTI) application", International Organization for Standardization (ISO), 2006



[ISO 18234-6, 2006] "ISO/TS 18234-6:2006 Traffic and Travel Information (TTI) - TTI via Transport Protocol Expert Group (TPEG) data-streams -- Part 6: Location referencing applications", International Organization for Standardization (ISO), 2006

[ISO 18234-7, 2007] "ISO/NP TS 18234-7 Traffic and Travel Information (TTI) -- TTI via Transport Protocol Expert Group (TPEG) data-streams -- Part 7: Packing information (PKI) application (TPEG-PKI_1.0/001)", International Organization for Standardization (ISO), 2007

[ISO 19115, 2003] ”ISO 19115:2003 Geographic information – Metadata”, International Organisation for Standardization (ISO), 2003

[ISO 19133, 2005] "ISO 19133:2005 Geographic information -- Location-based services -- Tracking and navigation", International Organization for Standardization (ISO), 2005.

[ISO 19134, 2007] "ISO 19134:2007 Geographic information -- Location-based services -- Multimodal routing and navigation", International Organization for Standardization (ISO), 2007.

[ISO 24530-2, 2006] "ISO/TS 24530-2:2006 Traffic and Travel Information (TTI) -- TTI via Transport Protocol Experts Group (TPEG) Extensible Markup Language (XML) -- Part 2: tpeg-locML", International Organization for Standardization (ISO), 2006

[ISO 24530-3, 2006] "ISO/TS 24530-3:2006 Traffic and Travel Information (TTI) -- TTI via Transport Protocol Experts Group (TPEG) Extensible Markup Language (XML) -- Part 3: tpeg-rtmML", International Organization for Standardization (ISO), 2006

[ISO 24530-4, 2006] "ISO/TS 24530-4:2006 Traffic and Travel Information (TTI) -- TTI via Transport Protocol Experts Group (TPEG) Extensible Markup Language (XML) -- Part 4: tpeg-ptiML", International Organization for Standardization (ISO), 2006

[ISO 24530-5, 2007] "Traffic and Traveller Information (TTI) -- TTI via Transport Protocol Experts Group (TPEG) Extensible Markup Language (XML) -- Part 5: tpeg-pkiML", International Organization for Standardization (ISO), 2007

[OASIS-DSML, 1999] "Directory Services Markup Language v1.0”, Organization for the Advancement of Structured Information Standards (OASIS), 1999

[OASIS-DSML, 2002] "Directory Services Markup Language v2.0”, Organization for the Advancement of Structured Information Standards (OASIS), 2002



[OASIS-ebXML, 2005a] "ebXML Registry Information Model Version 3.0", Organization for the Advancement of Structured Information Standards (OASIS), 2005.

[OASIS-ebXML, 2005b] "ebXML Registry Services and Protocols Version 3.0", Organization for the Advancement of Structured Information Standards (OASIS), 2005.

[OASIS-SAML, 2005] "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", Organization for the Advancement of Structured Information Standards (OASIS), 2005.

[OASIS-TransWS, 2007] "OASIS Translation Web Services - draft committee specification", Version 1.0.3, Organization for the Advancement of Structured Information Standards (OASIS), 2007.

[OASIS-WSBPEL, 2007] "Web Services Business Process Execution Language Version 2.0", Organization for the Advancement of Structured Information Standards (OASIS), 2007.

[OASIS-WSN-Base, 2006] "Web Services Base Notification 1.3", Organization for the Advancement of Structured Information Standards (OASIS), 2006.

[OASIS-WSN-BN, 2006] "Web Services Brokered Notification 1.3", Organization for the Advancement of Structured Information Standards (OASIS), 2006.

[OASIS-WSN-Topics, 2006] "Web Services Topics 1.3", Organization for the Advancement of Structured Information Standards (OASIS), 2006.

[OASIS-XACML, 2005] "eXtensible Access Control Markup Language (XACML)", Version 2, Organization for the Advancement of Structured Information Standards (OASIS), 2005, Document id: oasis-access_control-xacml-2.0-core-spec-os

[OGC-CAT, 2007] "OpenGIS® Catalogue Services Specification", Version 2.0.2, Corrigendum 2 Release, Open Geospatial Consortium (OGC), 2007-02-23, Ref.No OGC 07-006r1.

[OGC-CATISO, 2007] "OGC® Catalogue Services – ISO Metadata Application Profile", Version 1.0.0, Open Geospatial Consortium (OGC), 2007-05-02, Ref.No OGC 07-045.

[OGC-CT, 2001] "Coordinate Transformation Services", Revision 1.00, Open Geospatial Consortium (OGC), 2001-01-12, Ref.No. OGC 01-009

[OGC-ebRIM, 2005] "OGC® Catalogue Services — ebRIM (ISO/TS 15000-3) profile of CSW", Version 1.0.0,



Open Geospatial Consortium (OGC), 2005-10-17, Ref.No OGC 05-025r3.

[OGC-GeoDRM, 2006] Geospatial Digital Rights Management Reference Model (GeoDRM RM), Open Geospatial Consortium (OGC), 2006-02-28, Ref.No OGC 06-0004r3.

[OGC-GeoXACML, 2005] "Geospatial eXtensible Access Control Markup Language (GeoXACML)", Version: 0.3.0, Open Geospatial Consortium (OGC), Editor: Andreas Matheus, 2007-03-22, Ref. No. OGC 07-026.

[OGC-GML, 2004] "OpenGIS® Geography Markup Language (GML) Encoding Specification", Version 3.1, Open Geospatial Consortium (OGC), 2004-02-07, Ref.No OGC 03-105r1.

[OGC-OpenLS, 2005] "OpenGIS® Location Service (OpenLS) Implementation Specification: Core Services", Version 1.1, Open Geospatial Consortium (OGC), 2005-05-02, Ref.No OGC 05-016.

[OGC-WCS, 2006] "OpenGIS® Web Coverage Service (WCS) Implementation Specification / OGC WCS", Version 1.1.0, Open Geospatial Consortium (OGC), 2006-10-17, Ref.No OGC 06-083r8.

[OGC-WCTS, 2005] "Web Coordinate Transformation Service (WCTS) draft Implementation Specification", Version 0.3.0, Open Geospatial Consortium, 2005-01-31, Ref.No OGC 05-013.

[OGC-FE, 2005] "OpenGIS® Filter Encoding Implementation Specification", Version 1.1.0, Open Geospatial Consortium (OGC), 2005-05-03, Ref.No OGC 04-095.

[OGC-SE, 2006] "OpenGIS® Symbology Encoding Implementation Specification", Version 1.1.0, Open Geospatial Consortium (OGC), 2006-07-21, Ref.No OGC 05-077r4.

[OGC-SLD, 2007] "OpenGIS® Styled Layer Descriptor profile of the Web Map Service Implementation Specification", Version 1.1.0, Open Geospatial Consortium (OGC), 2007-01-05, Ref.No OGC 05-078r3.

[OGC-WFS, 2005] "OpenGIS® Web Feature Service (WFS) Implementation Specification", Version 1.1.0, Open Geospatial Consortium (OGC), 2005-05-03, Ref.No OGC 04-094.

[OGC-WFS-G, 2006] "OGC Best Practices Document: Gazetteer Service - Application Profile of the Web Feature Service Implementation Specification", Version 0.9.3, Open Geospatial Consortium (OGC), 2006-06-05, Ref.No OGC 05-035r2.

[OGC-WMS, 2006] "OpenGIS® Web Map Service (WMS) Implementation Specification", Version 1.3.0, Open



Geospatial Consortium (OGC), 2006-03-15, Ref.No OGC 06-042.

[OGC-WNS, 2006] "Draft OpenGIS® Web Notification Service Implementation Specification", Open Geospatial Consortium (OGC), 2006-11-18, Ref.No OGC 06-095.

[OGC-WPOS, 2002] "Pricing & Ordering Service (WPOS), XML Configuration & Pricing Format (XCPF)", Open Geospatial Consortium (OGC), 2002-10-18, Ref.No. 02-029r1.

[RAILML, 2004] "Specification of railML® partial scheme 'timetable'", Joachim Rubröder / railML.org, 2004.

[SDEP, 2006] "SDEP Phase1 release 060109 description", SDEP Group, 2006.

[TRANSMODEL, 2001] "Reference data model for Public Transport", TRUST, 2001.

[TRB, 2007] "TransXML: XML Schemas for Exchange of Transportation Data", Transportation Research Board of the National Academies, 2007.

[TRL, 2000] "Development of Safety Principles for Invehicle Information and Communication Systems", Transport Research Laboratory, 2000

[TSO, 2003] "Annual Report & Accounts 2001-02", The Stationary Office UK - Ordered by the House of Commons, 2003.

[W3C-PLS, 2006] "Pronunciation Lexicon Specification (PLS)", Version 1.0, W3C Working Draft, 2006.

[W3C-POIX, 1999] "POIX: Point Of Interest eXchange Language Specification", Version 2.0, W3C Note developed by Hiroyuki Kanemitsu and Tomihisa Kamada, 1999.

[W3C-SMIL2, 2005] "Synchronized Multimedia Integration Language (SMIL 2.1)", W3C Recommendation, 2005.

[W3C-SMIL3, 2007] "Synchronized Multimedia Integration Language (SMIL 3.0)", W3C Working Draft, 2007.

[W3C-SSML, 2004] "Speech Synthesis Markup Language (SSML) Version 1.0", W3C Recommendation, 2004.

[W3C-SOAP, 2007] ”SOAP Version 1.2”, W3C Recommendation, 2007.

[W3C-VoiceXML, 2004] "Voice Extensible Markup Language (VoiceXML) Version 2.0", W3C Recommendation, 2004.

emotion system – analysis of technical...

Documents