100 likes | 117 Views
This session provides an overview of functional and technical aspects of setting up a DATEX link, including data exchange, standardization, service guarantees, and legacy system integration. The importance of a strict data model, semantics, and location referencing is emphasized. Participants will gain insights into making DATEX more inclusive and interoperable. Join us for a detailed discussion on optimizing data exchange for traffic and transport policies.
E N D
Day 1 Closing Plenary Session Christer Karlsson(Swedish National Road Administration)25 January 2001
Overview of Stream on Functional AspectsSteve Morello(ISIS)Session: Day 1 Closing Plenary Session26 January, 17:15 - 18:30
Overview of Stream on Functional AspectsSession 1A&1C Setting up a DE link - 1 • Main issues for the private sector: • How will a DE link work? • What information will be available? • How to predict the costs? • How to guarantee service? • Need to standardise interfaces and protocols when and where possible • Datex proved to be useful in NL and elsewhere • Service providers are interested in DE and TI
Overview of Stream on Functional AspectsSession 1A&1C Setting up a DE link - 2 • Different versions of DATEX can communicate (CORVETTE) • Filter mechanisms are necessary • Implementing into legacy systems is an important issue • Need for service level agreements • Added value of data exchange is important for traffic and transport policies
Overview of Stream on Technical AspectsJonathan Booth(MVA)Session: Day 1 Closing Plenary Session26 January, 17:15 - 18:30
Overview of Stream on Technical AspectsSession 1B & 1D Technical Aspects • Understanding the data • Semantics - need for a strict data model • Location Referencing problems • Need an addition to RDS-TMC • Need to work with TMC Loc. Ref. Task Force • Need to look at end to end functions • Not just the data exchange link • Helpful profiles…reducing choices
Overview of Stream on Technical AspectsSession 1B & 1D Technical Aspects • Need to make “DATEX” • include PT, freight • more strictly defined • use a strict data model for better semantics • but FULLY backwards compatible