Système d'information de la gestion des routes et du trafic

Dimension: px
Commencer à balayer dès la page:

Download "Système d'information de la gestion des routes et du trafic"

Transcription

1 ASTRA OFROU Système d'information de la gestion des routes et du trafic Code B SE Projet partiel: Système de base Cahier des charges système de base Traduction partielle (dès chap. 6) Seule la version allemande fait foi pour la réalisation du système de base MISTRA. Version 4.1 Datum 30. September 2005 E:\MISTRA\Cahier des charges SB V4.1.doc / Techdata AG Projekt- und Baumanagement Effingerstrasse 13, Postfach, 3001 Bern Tel , Fax

2 MISTRA -Pflichtenheft Basissystem Impressum Erstelldatum 29. August 2003 Ausgabedatum :29 Autor(en)/Autorin(nen) Th. Mahrer, Chr. Kaeser, E. Bernard, J. Landolt, A. Peyinghaus, M. Cremosnik Verzeichnis/Dateiname Cahier des charges SB V4.1 Anzahl Seiten 122 Dokumentenverwaltung Version Datum Autor Bemerkungen EB Ergänzungen nach internem Review EB Überarbeitung nach Review ELCA + Erweiterungen EB Korrekturmarkierung entfernt EB Entwurf Version EB Überarbeitung aufgrund Review ELCA und DWH EB Diverse Anpassungen nach internem Review EB Änderungen nach Steuerungssitzung eingebaut EB Korrekturen und Ergänzungen von Korrekturlesungen EB Freigegeben für Offertstellung Basissystem und DWH EB Korrekturmarkierung entfernt EB Begriffe mit Dokument Geschäftsprozesse abgeglichen EB Neuer Inhalt Projektauftrag in Kap 2 bis 5 eingearbeitet, Bemerkungen EBP eingebaut, Kap 7 Datenintegration ergänzt, weitere geringfügige Korrekturen rbo Korrekturmarkierung entfernt

3 MISTRA - Pflichtenheft Basissystem Inhaltsverzeichnis Seite 0 ALLGEMEINES Einleitung Grundlagen Literaturhinweise ZWECK DES DOKUMENTS AUSGANGSLAGE Auftrag Abgrenzung Organisation Marktanalyse GIS, Web-Technologie, Standards IST-ZUSTAND Neugestaltung des Finanzausgleiches und der Aufgabenteilung (NFA) Geschäftsprozesse ISA, KOFINAS, Projektkosten-Controlling STRADA-DB, KUBA-DB, UH-PERI Verkehrsunfälle Verkehrsmonitoring Langsamverkehr, GIS-LV, DM-LV Inventar der historischen Verkehrswege der Schweiz (IVS) Sonderbewilligungen Erhaltungsmanagement ZIELE UND LÖSUNGEN Vision Unterhaltsstrategie Ausbauprojekte Ausnahmetransporte Verkehrssicherheitspolitik (Via Sicura) Systemziele Übergeordnete Ziele Oberziele Hauptziele Systembezogene Ziele ANFORDERUNGEN MUSSKRITERIEN EXIGENCES ENVERS LE SYSTÈME DE BASE Système de base : exigences relatives à sa réalisation Structure et limites du système Architecture du système MISTRA Architecture du système de base Produits et technologies de base Structure modulaire du système Liaison d applications métier MISTRA Fonctions du système de base destinées à supporter les applications métier Exigences de base que doivent remplir les applications métier Liaison d applications externes Répartition des instances MISTRA, configurations types du système Authentification et droits Mode multiutilisateur, unités de traitement Interface de service...41 a

4 MISTRA - Pflichtenheft Basissystem Interface standardisée (Interlis2) Exportation Web GIS COSIG Importation de données d intervenant Importation de données dans des documents Importation de données de navigation Importation de données d information routière Exportation de métadonnées COSIG Autres interfaces Outil de sélection Clients, interface utilisateur Cas d application (use cases) Application de base SIG Application d administration Application axe tendu Plurilinguisme Sécurité Documentation Exigences de performance, délais de réponse Système de base : exigences introduction OFROU Concept d introduction Réception du système Installation Formation Système de base : Exigences d exploitation Gestion de la configuration Maintenance Gestion des versions Support (Gestion des problèmes) INTÉGRATION DES DONNÉES Intégration des données de base Interface STRADA Interface UH-PERI Reprise des données Préparation des données Intégration d autres données de base Intégration des données de navigation Intégration des données d information routière Intégration des données généralistes Interface tracés Intégration des ouvrages d art avec valeurs numériques Intégration des données relatives aux accidents Intégration des données du trafic Intégration de la locomotion douce Intégration des données des voies de communication historiques Intégration de la comptabilité d exploitation EXIGENCES ENVERS LE SYSTÈME DE DATA WAREHOUSE Data Warehouse : exigences de réalisation Introduction Architecture Exigences conceptuelles Requêtes et états Exigences fonctionnelles Cas d application (use cases) Exigences envers le logiciel ou l outil Protection et sécurité des données Exigences techniques b

5 MISTRA - Pflichtenheft Basissystem Structure quantitative Documentation Planification du projet Data Warehouse : exigences introduction OFROU Concept d introduction Réception du système Installation Formation Data Warehouse : Exigences d exploitation Gestion de la configuration Maintenance Support (gestion des problèmes) PLANIFICATION ET ORGANISATION Gestion de projet Manuel, plan de projet Echéancier approximatif Assurance de la qualité AQ Gestion des risques GR Gestion de la configuration GC Abbildungsverzeichnis Abbildung 1: Systemabgrenzung MISTRA...6 Figure 3 : Architecture conceptuelle du système global MISTRA...23 Figure 4 : Architecture logique du système...24 Figure 5 : Variantes que permet la structure modulaire du système...28 Figure 6 : Liaison avec application métier en ligne vs hors ligne...29 Figure 7 : Liaison d applications externes...34 Figure 8 : Variantes de configuration du système...35 Figure 9 : Disposition de l écran des clients SIG...49 Figure 10 : Carte des processus du système de base (niveau macro)...50 Figure 11 : Transformation de modèle de STRADA à MISTRA...76 Figure 12 : Insertion du DWH dans l architecture logique du système...83 Figure 13 : Architecture interne du DWH...84 Figure 14 : Processus itératif d implémentation du DWH...87 Figure 15 : Modification de relations spatiales et temporelles dans le DWH...89 Figure 16 : Exemple de rapport combiné du DWH...94 Figure 17 : Disponibilité du DWH Figure 18 : Echéancier réalisation et introduction Tabellenverzeichnis Tabelle 1: Kerneigenschaften MISTRA...5 Tableau 2 : Produits et technologies de base...27 Tableau 3 : Fonctions du système de base destinées à supporter une application métier...32 Tableau 4 : structure quantitative des grandes installations...37 Tableau 5 : Structure quantitative des installations petites à moyennes...38 Tableau 6 : Types de client...48 Tableau 7 : Use cases et attribution aux clients...58 c

6 MISTRA - Pflichtenheft Basissystem Tableau 8 : Interface STRADA...77 Tableau 9 : Requêtes du DWH...91 Tableau 10 : Rapports standard du DWH...93 Tableau 11 : exigences fonctionnelles du DWH...96 Tableau 12 : Use cases du DWH et attribution aux clients...98 Tableau 13 : Types d utilisateurs du DWH (* selon [2]) Tableau 14 : Fréquence des accès au DWH Tableau 15 : Structure quantitative du DWH Tableau 16 : Calendrier des modules d intégration du DWH Tableau 17 : Délais détaillés pour le module données fondamentales du DWH Tableau 18 : Délais pour modules données spécialistes du DWH d

7 0 Allgemeines 0.1 Einleitung Das vorliegende Dokument beinhaltet das Pflichtenheft für die Realisierung, die Einführung und den Betrieb des Basissystems MISTRA. Das Basissystem bildet die Informations- und Kommunikationsplattform aller Beteiligten für die Unterstützung der Steuerung der Aufgaben des ASTRA und umfasst folgende Teile: Sockeldatenbank mit Basis- und Generalistendaten GIS-Basisapplikation zur Bearbeitung von Basisdaten, Bau- und Erhaltungsprojekten, Fachnetzen, Bauwerken u.a.m. Schnittstellen für den Datenaustausch mit Fach- und Fremdapplikationen Data Warehouse für Auswertungen (Fachanalysen und Fachreports, Managementinformationen) Achsbandapplikation für grafische Auswertung auf der Abwicklung von Achsen Werkzeuge zur Administration der Daten Migrationstools für die Übernahme von Daten aus STRADA, UH-PERI, VECTOR25 u.v.a.m. Die Spezialistendaten, welche meist in aggregierter Form von weiteren Fachapplikationen benötigt werden, stehen als Generalistendaten im Basissystem zur Verfügung, werden aber i.d.r. in der Fachapplikation verwaltet. Es gibt einzelne Fachbereiche, für welche das Basissystem temporär und im Sinne einer Übergangslösung bis zur Fertigstellung entsprechender Fachapplikationen Funktionalität zur Verwaltung von Generalistendaten zur Verfügung stellt. Dies betrifft: Streifen, Schichteinbau Deckschicht, Langsamverkehr, Rapportstrecken, Kosten, Bauwerke, Projekte, evtl. weitere. 0.2 Grundlagen [1] HERMES, Führen und Abwickeln von Projekten der Informations- und Kommunikationstechnik", Ausgabe 2003 [2] ASTRA, "Geschäftsprozesse Basissystem", Version 4.3 [3] ASTRA, "Datenkatalog Sockeldaten", Version 4.0 [4] ASTRA, "MISTRA Basissystem, UseCase-Diagramm", Version 1.0 [5] ASTRA, "Beschreibung der Testdaten", [6] ASTRA, "MISTRA Teilprojekt Daten, Vorgehen Datenintegration", Version 1.0 [7] Ecole Polytechnique Lausanne, Projet SYRROU, Rapport final 1

8 [8] VSS-Normen gemäss Ausschreibung zur Teilnehmerauswahl, Absatz 7.2, in der jeweils gültigen Version [9] STRADA: Leitfaden für den Aufbau und Betrieb, Version 1.0 vom [10] "INTERLIS 2 Referenzhandbuch", bzw. download_f.php [11] KOGIS "geocat.ch: Metadatenkatalog für Geodaten", August [12] KOGIS "Metadatenmodell GM03", Version 2.0 [13] ISB Informatikstrategieorgan Bund, I007 Basisstandards Interoperabilität [14] ISB Informatikstrategieorgan Bund, I013 Interoperabilitätsstandards für Web Services [15] Open GIS Consortium Inc. "Catalog Services Specification", Version 2.0 [16] Open GIS Consortium Inc. "Simple Features Specification for SQL", Version 1.1 [17] Open GIS Consortium Inc. "Simple Features Specification for OLE/COM", Version 1.1 [18] ISO/TC211 ISO/DIS "Geographic Information Web map server interface", [19] Open GIS Consortium Inc. "Web Feature Service Implementation Specification", V 1.0 [20] [21] [22] 0.3 Literaturhinweise [23] Open GIS Consortium Inc. "OpenGIS Reference Model" OGC , Version [24] ESRI "Linear Referencing and Dynamic Segmentation in ArcGIS", Mai [25] ESRI "Modeling and Using History in ArcGIS", Technical Paper, Mai [26] MISTRA, Teilprojekt Verkehrsunfälle, Bericht Voranalyse Version 1.1 vom

9 1 Zweck des Dokuments Das Pflichtenheft beschreibt die Ziele und Anforderungen an das zukünftige System, die mit der angestrebten Lösung zu erreichen sind. Es bildet die Grundlage für Preisangebot und Realisierung des Basissystems MISTRA entsprechend den Vorgaben von Hermes Der Bericht Geschäftsprozesse Basissystem [2] bildet die zentrale Grundlage für das Projekt, indem es Rollen, Aktivitätenreihenfolgen und Ergebnisse unmissverständlich darlegt. Der Datenkatalog Sockeldaten [3], das Use-Case-Diagramm [4] und die Testdaten [5] sind Bestandteile dieses Pflichtenhefts. Das Pflichtenheft dient als Grundlage für die Realisierung. Gleichzeitig dient das vorliegende Pflichtenheft als Rahmen für Integrationsarbeiten, welche es bei der Realisierung von MISTRA- Fachappliaktionen und Fremdapplikationen des ASTRA zu leisten gilt. 2 Ausgangslage 2.1 Auftrag Die Geschäftsleitung des ASTRA erteilt der Projektleitung MISTRA folgenden Auftrag: Das ASTRA erstellt ein Management-Informations-System Strasse und Strassenverkehr (MISTRA) zur Unterstützung der strategischen, konzeptionellen und operativen Steuerung der ASTRA-Aufgabenbereiche Netzkonzipierung, Netzbereitstellung (Planung, Bau, Ausbau, Unterhalt, Betrieb) und Netznutzung sowie sinngemässer Aufgaben professioneller Strasseneigentümer und strassenbezogener Netzbetreiber. Dieses geographische Informations- und Kommunikations-System (IKS) wird in Zusammenarbeit mit Kantonen, Agglomerationen und verschiedenen Bundesämtern sowie einschlägigen Fachorganisationen erstellt. MISTRA zeichnet sich durch folgende Kerneigenschaften aus: betriebswirtschaftlich effizient Ermöglicht einfache, kundenorientierte Auswertungen zu generieren, wie Fachanalysen und -reports und möglichst automatisches Generieren von Netzkennziffern im Sinne von Management- Informationen für das ASTRA. Unterstützung der georeferenzierten ASTRA-Geschäftsprozesse. Abschöpfung des erheblichen Nutzen-Potenzials für das ASTRA durch den breiten Integrationsansatz. schweizweit Für alle professionellen, öffentlichen Strasseneigentümer und strassenbezogenen Netzbetreiber. Für alle Belange der Strasseninfrastruktur und des Strassenverkehrs, welche direkt oder indirekt von nationaler Bedeutung sind. Flächendeckende, durchgängige Applikationen und Webservices. 3

10 objektorientiert kundenorientiert Beinhaltet Daten, Strassen-Objekte und Netze als statische, räumliche Infrastrukturinformationen, die zugewiesen werden können für: Nationalstrassen Hauptstrassen Kantonsstrassen Gemeindestrassen Übrige Strassen Velowege (national, regional) Fuss- und Wanderwege (national, regional, lokal) Historische Verkehrswege (national, regional, lokal) Ausrichtung der Wertschöpfung des ASTRA auf die Bedürfnisse der Zielgruppen: Öffentlichkeit und Mobilitätsteilnehmende Kantone und kantonale Organisationen Agglomerationen, Städte, Gemeinden Professionals Fachdienstleister Bund, ASTRA, diverse Bundesämter integriert Standardisierung gemäss Vorgaben des Bundes und der strategischen IT-Vorgaben des ASTRA. Wiederverwendung bestehender Datensätze. Einfache Wiederverwendung von Webservices und Applikationen. Mitbenutzung der Geodienste von swisstopo und KOGIS. Berücksichtigung der VSS-Normen soweit möglich und sinnvoll. volkswirtschaftlich effizient Leistungserstellung erfolgt auf der Wertschöpfungskette im Sinne der NFA und im Rahmen des FLAG-Amtes ASTRA (Lieferant ASTRA Kunde) weitgehend ohne Medienbrüche. Offene, erweiterbare, flexible IKS-Lösung, welche stark von der Weiterentwicklung von Standard-Software profitieren kann. Die zur Verfügungstellung von Informationen, Daten, Webservices und Applikationen des MISTRA-Basissystems hat für die Kunden keine Kostenfolgen. Einfache und breite Daten- und Applikationsnutzung. Optimierung der Aufgaben-Zuständigkeiten nach Massgabe des volkswirtschaftlichen Aufwands (p. ex. Entwicklung von Applikationen durch den Bund oder freien Markt). 4

11 effektiv Geschäftsprozesse, Applikationen, Web-Services und Daten sind gut und klar spezifiziert sowie auf die Zielgruppen von MISTRA ausgerichtet. Tabelle 1: Kerneigenschaften MISTRA MISTRA-Lösung funktioniert mit grosser Kontinuität, hoher Stabilität und Zuverlässigkeit. Das Kosten-Nutzen-Verhältnis ist angemessen. Mit der Aufbauphase ( ) von MISTRA werden folgende Ergebnisse angestrebt: 1. Voranalyse und Konzept des Gesamtsystems mit zeitlicher Priorisierung der Fachapplikationen 2. Aufbau des MISTRA-Basissystems 3. Integration der Sockeldaten aus STRADA, UH-PERI, KUBA-DB und weiteren Datenbanken 4. Realisierung der für den Systembetrieb erforderlichen Basisapplikationen mit den Webservices 5. Sicherstellung einer ausbaufähigen IT-Funktion mit klarem Service Level Agreement des ASTRA mit dem Systembetreiber. 6. Definition der zentralen Geschäftsprozesse des ASTRA Mit der Betriebsphase I ( ) von MISTRA werden folgende Ergebnisse angestrebt: 1. Bedarfsgerechter Ausbau des Datenmodells und des Datenkatalogs 2. Weiterentwicklung des Basissystems aufgrund der ersten Erfahrungen der Benutzer 3. Starkes Vorantreiben der Webservices auf einer Web-browser-basierten Technologie Mit der Betriebsphase II ( ) von MISTRA werden folgende Ergebnisse angestrebt: 1. Definition weiterer Geschäftsprozesse für die Fach- und Fremdapplikationen des ASTRA 2. ansonsten dito Betriebsphase I Normalbetrieb von MISTRA (ab 2012): Inkrementelle Anpassung und Weiterentwicklung des Informations- und Kommunikationssystems MISTRA bezüglich allen Belangen nach Vorgaben der oben stehenden Kerneigenschaften des Systems. Stufenweise Ablösung STRADA-DB (ab 2007): Sobald die Daten aus STRADA-DB migriert sind und der einwandfreie Betrieb von MISTRA sichergestellt und gewährleistet ist, kann STRADA-DB stufenweise in das neue System von MISTRA überführt werden. Im Rahmen der Überführung ist ein Parallelbetrieb vorgesehen. Die definitive Abschaltung, d.h. die Sistierung der Finanzierung der Wartungs- und Supportleistungen, erfolgt nach Abschluss der Datenübergabe der Kantone an das ASTRA im Zuge der NFA, voraussichtlich per

12 2.2 Abgrenzung Gemäss den Kerneigenschaften behandelt MISTRA ausschliesslich statische Infrastrukturdaten. Diese Daten können maximal tagesaktuell gehandhabt und mutiert werden. Die Anwendungen der Finanz- und Betriebsbuchhaltung (Kostenmanagement), der Strassenverkehrstelematik sowie Applikationen zu NFA wie p. ex. Immobilienmanagement oder Landerwerb sind deshalb nicht Bestandteil von MISTRA. MISTRA wird hingegen so offen konzipiert, dass diese Applikationen über klar spezifizierte Standardschnittstellen angebunden werden und Sockeldaten beziehen bzw. liefern können. Die folgende Grafik stellt explizit die Abgrenzung der verschiedenen Systeme nochmals vereinfacht dar. Sie gilt in diesem Sinne auch für weitere Fremdsysteme (Fremdapplikationen) wie IDM, Verkehrsnavigation, Verkehrsinformation, etc. Abbildung 1: Systemabgrenzung MISTRA 2.3 Organisation Die Organisation und der Rollenbeschrieb sind in [2], Dokumente Nr. 211 und 220 detailliert beschrieben. 2.4 Marktanalyse Die Ausschreibung MISTRA-Studienauftrag hat ergeben, dass keine Standardlösung auf dem Markt existiert, welche die Systemziele befriedigend erfüllen kann. Deshalb wird sich die Lösung auf die Entwicklung eines neuen Softwaresystems auf der Basis eines GIS und weiterer Fertigprodukte konzentrieren. Nur in Ausnahmefällen und bei gutem Kosten-Nutzen-Verhältnis können zusätzlich vollständige Eigenentwicklungen veranlasst werden. 6

13 2.5 GIS, Web-Technologie, Standards Die Verbreitung von geografischen Informationssystemen GIS hat in den vergangenen Jahren stark zugenommen und ist bei den Verwaltungen zu einem wichtigen Bestandteil der IT-Infrastruktur geworden. Mit der Verbreitung der Hilfsmittel hat sich auch die Datenlage stark verbessert. Diese Entwicklung hat die Nachfrage nach einem integralen Ansatz bei der Verwaltung raumbezogener Daten stark erhöht. Eine weitere sehr bedeutende Entwicklung stellt das Aufkommen von WebGIS-Anwendungen auf der Basis von Web-Services dar. Diese Technologie ermöglicht eine sehr einfache und kostengünstige Verbreitung von Geodaten. Während die Web-Technologie heute primär noch als eine Grundlage für Betrachter-Werkzeuge angesehen wird, zeichnet sich ein starker Trend hin zu Nachführungsfunktionen via Web (Web Feature Services) ab. Es ist anzunehmen, dass in den nächsten 2 bis 3 Jahren auch die Nachführung von Daten verstärkt über Web-Technologien (im Intranet) aktuell wird. Kapitel beschreibt inwiefern diese Entwicklung beim Aufbau des Basissystems zu berücksichtigen ist. Durch intensive Standardisierungsbemühungen insbesondere durch das Open GIS Consortium, in Zusammenarbeit mit den GIS-Herstellern, sind die Systeme zur Verarbeitung von Geodaten sehr viel offener geworden. Hierdurch hat sich die Interoperabilität der Systeme, d.h. die Verwendung eines einheitlichen Datenbestands durch verschiedene Systeme, bereits heute verbessert. Die Benutzung einstmals komplexer GIS-Werkzeuge ist ebenfalls wesentlich einfacher geworden und hat sich an einen quasi-standard angeglichen. Die früher oft intensiv diskutierte Frage nach dem strategischen GIS-Werkzeug hat dadurch an Bedeutung verloren. Die Koordinationsstelle GIS des Bundes KOGIS hat mit ihren Standardisierungen in den Bereichen Metadaten [11] und Datenaustausch über Interlis2 [10] wichtige Grundlagen für die effiziente und verbesserte Nutzung vorhandener Daten beigetragen. Diese Grundlagen sind beim Aufbau des Basissystems MISTRA zu berücksichtigen. 3 Ist-Zustand Neugestaltung des Finanzausgleiches und der Aufgabenteilung (NFA) Die Neugestaltung des Finanzausgleichs und der Aufgabenteilung zwischen Bund und Kantonen (NFA) ist eine zentrale Umfeldentwicklung für MISTRA. Die Landschaft der Zuständigkeiten wird sich entsprechend dem NFA-Ansatz erheblich verändern. Grob lassen sich folgende Aussagen machen: Nationalstrassennetz fertig stellen in Zusammenarbeit mit Bund und Kantonen Ausbau und Erweiterung Nationalstrassennetz als Bundesaufgabe Unterhalt und Betrieb Nationalstrassennetz als Bundesaufgabe Ausbau Agglomerationsverkehrsnetze als Verbundaufgabe Verkehrsmanagement auf Nationalstrassen und Transitachsen (VM-CH) als Verbundaufgabe 7

14 Teilentflechtung im Subventionsbereich Hauptstrassennetz Bau und Unterhalt übrige Strassennetze als Kantonsaufgabe Nationale Velo- und Wanderwege als Verbundaufgabe; übrige Wege als Kantonsaufgabe Historische Verkehrswege nationaler Bedeutung als Verbundaufgabe; übrige als Kantonsaufgabe MISTRA ist so aufzubauen, dass die neue Zuständigkeitsordnung in jedem Falle ohne Neugestaltung der Geschäftsprozesse und der dementsprechenden Fachapplikationen durch die Betroffenen und Beteiligten wahrgenommen werden kann Geschäftsprozesse Die ASTRA-Geschäftsprozesse (= Vorgehen zur Leistungserstellung) dienen als zentrale Grundlage für die weiteren Arbeiten. MISTRA wird so aufgebaut, dass künftig die mit den Geschäftsprozessen definierte Leistungserstellung im Führungsrahmen des FLAG-Amtes ASTRA erbracht werden kann. Dementsprechend ist bei der Realisierungsphase des MISTRA-Basissystems eine vollständige Kongruenz der Geschäftsprozesse durch Abgleich mit den Arbeiten zum FLAG-Amt ASTRA und zur NFA zu erzielen. Die Geschäftsprozesse für das Basissystem wurden bis auf die Mikroebene und Gebrauchsfälle definiert und bilden die Grundlage für die Realisierung, Einführung und den Betrieb des Basissystems sowie des Data Warehouses. Die Geschäftsprozesse der Fachapplikationen Fahrbahn und Nebenanlagen, Kunstbauten und Tunnel, Verkehrsunfälle, Verkehrsmonitoring, Langsamverkehr und Historische Verkehrswege werden zurzeit erarbeitet. Gleichzeitig werden die Grundsätze für die entsprechenden Fachprozesse definiert und mit dem aktuellen Führungssystem des ASTRA abgeglichen ISA, KOFINAS, Projektkosten-Controlling Die Verwaltung der Finanzdaten zur Strasseninfrastruktur ist heute im ASTRA mit dem System ISA (Informatiksystem Amt), gelöst. Dank der ständig vorgenommenen Weiterentwicklungen erfüllt dieses System von der Technik und der Leistungsfähigkeit her die gestellten Anforderungen. Einzig die Benutzeroberfläche entspricht nicht mehr dem heutigen Bürostandard und sollte angepasst werden. Für einen Teil des ISA-Systemes wurde im Projekt KOFINAS (Kosten- /Finanzmanagement ASTRA) seit Anfang 2003 ein entsprechendes Ablösungskonzept erarbeitet. Da mit KOFINAS die erwünschten Ergebnisse nicht erzielt werden konnten, wurde das Projekt abgebrochen. Es wurde deshalb eine neue Voranalyse für ein Investitionscontrolling-Tool erstellt. 8

15 3.1.4 STRADA-DB, KUBA-DB, UH-PERI STRADA-DB wird in ca. 17 Kantonen und im ASTRA für die Erhaltungsplanung der Strassen eingesetzt. Es werden keine weiteren Entwicklungsarbeiten mehr, sondern nur noch die betriebsnotwendigen Massnahmen ausgeführt (Wartung, Support). Als Basis für die Unterhaltsprojekte der Nationalstrassen wurde das Projekt UH-PERI NS erstellt. Es stellt ein vollständiges Verzeichnis der Nationalstrassenobjekte dar. Die entsprechende, integrative Informatikanwendung wird vollständig in das Basissystem integriert und zweckmässig weiterentwickelt. Des weiteren ist die Integration der betrieblichen Abschnittsverzeichnisse (Rapportstrecken) vorgesehen. Dank der Zusammenarbeit mit swisstopo/kogis werden die Objektverzeichnisse über den WEB-GISServer von KOGIS breit zur Verfügung gestellt. Basissystem Die Basisdaten aus STRADA-DB und die Daten von UH-PERI werden ins Basissystem integriert. Für die Konzeption und Realisation des Basissystems wurden 2003 aus 30 Teilnahmeanträgen 5 Kandidaten für die Ausarbeitung der Voranalyse, des Konzeptes, eines Prototypen und Preisangebotes, im Rahmen eines Studienauftrages, ausgewählt. Dieser wurde Anfang 2004 gestartet. Im Frühjahr 2004 präsentierten die Kandidaten ihre Voranalysen und einen ersten Prototypen. Im November 2004 wurden die Konzepte und weiterentwickelten Prototypen vorgestellt. Diese wurden evaluiert und bewertet. Im Juni 2005 erfolgte die Gesamtbewertung für die Vergabe. Der Realisierungsbeginn ist für Oktober 2005 geplant. Das System soll Anfang 2007 im ASTRA eingeführt und betriebsbereit sein. Fahrbahn und Nebenanlagen Fachdaten über den Strassenaufbau und die Erhaltungsplanung wurden bis heute mit STRADA- DB bewirtschaftet. Für die Ablösung muss eine entsprechende Fachapplikation verfügbar sein. Dies kann sowohl mit einer bestehenden, an MISTRA angekoppelten Fachapplikation erfolgen oder, falls die Anforderungen nicht erfüllt werden, durch eine Neuentwicklung. Heute liegen die ersten Ergebnisse der Voranalyse (Situationsanalyse und Zielsystem) vor. Im Dezember 2005 soll der vollständige Voranalysebericht vorliegen. Kunstbauten und Tunnel Im Rahmen der neusten Entwicklung, wird KUBA-DB, in enger Abstimmung mit MISTRA, bis Ende 2006 um ein Modul Managementsystem für die Unterhaltsplanung und ein Modul zur Verwaltung der Substanzdaten bergmännischer Tunnel ergänzt werden. Die Konzeptphase für die Erweiterung von KUBA-DB mit dem Managementsystem (KUBA-MS) ist abgeschlossen. Die Realisierungsarbeiten und Wartungsleistungen wurden im Frühjahr öffentlich ausgeschrieben und vergeben. Die Realisierung von KUBA 4.0 ist im August 2005 gestartet 9

16 und soll Ende 2007 in allen Kantonen eingeführt sein. KUBA 4.0 beinhaltet die Erweiterung mit den Funktionen für das Management der Kunstbauten (BMS). Die Arbeiten für das IT-Konzept von KUBA 4.1 für die Erweiterung mit den bergmännischen Tunnels und die vollständige Anbindung an das Basissystem MISTRA ist in Arbeit. Das Konzept wird im Herbst 2005 vorliegen Verkehrsunfälle In Zusammenarbeit mit bfu, BFS und den Polizeiorganen der Kantone wurde das neue Unfallerhebungsprotokoll festgelegt. Unter anderem wird dabei zwingend die Georeferenzierung der Unfallstelle verlangt. Das neue Unfallerhebungsprotokoll wurde 2004 getestet und nach positiven Erfahrungen eingeführt. Auf dem Markt existieren bereits verschiedene Applikationen zur Unfallerhebung und Auswertung. Die Massnahmen aus dem Projekt Verkehrssicherheitspolitik des Bundes (VESIPO) sollen im Handlungsprogramm Via Sicura umgesetzt werden. Die Fachapplikation Verkehrsunfälle kann als eine vorgezogene Massnahme davon betrachtet werden. Der Konzeptbericht soll im Frühling 2006 vorliegen, sodass die Realisierung eines Werkzeuges für die Erfassung und Auswertung der Unfalldaten ausgeschrieben werden kann Verkehrsmonitoring Mit dem Teilprojekt Verkehrsmonitoring sind primär Grundlagen quantitativer und qualitativer Art über den Verkehrsfluss zu erfassen und bereitzustellen. Später ist auch vermehrt das Monitoring der Umweltbereiche (Lärm, Luft, Staub, Gewässer) durchzuführen und die erhobenen Daten mit dem Aufkommen des motorisierten Individualverkehrs (MIV) zu verknüpfen. Die bereits Anfangs 2005 abgeschlossenen Arbeiten für die Voranalyse betrafen nur einen Teil des Verkehrsmonitorings (AVZ), weshalb das Projekt auf Antrag der Gesamtprojektleitung hin neu aufgegleist wurde, mit dem Ziel einen erweiterten Ansatz für das Monitoring zu erarbeiten. Die Voranalyse und das Konzept werden entsprechend angepasst. Die ersten Module sollen im Frühling 2006 für die Realisierung ausgeschrieben werden. In der ersten Phase werden Module für die automatischen Verkehrszähler (AVZ), WIM (dynamische Achslasterfassungssysteme), Messstellenverwaltung, und Verkehrsmodell UVEK (in Zusammenarbeit mit dem ARE) umgesetzt. Die Rohdaten aus den einschlägigen Sensoren (Verkehrszähler, WIM-Anlagen u.a.m.), ausgewertete Verkehrsdaten und -informationen, p. ex. DTV, LW-Anteil, Ganglinien sollen alle im MISTRA-Basissystem oder via Data Warehouse (DWH) zugänglich gemacht werden. Der spätere Ausbau in Richtung Verwaltung und Betreuung der Staudaten sowie der Auswirkungen des Strassenverkehrs bezüglich Lärm, Luft und Boden wird in die entsprechenden Arbeiten miteinbezogen. 10

17 3.1.7 Langsamverkehr, GIS-LV, DM-LV Der Bereich Langsamverkehr hat eine Voranalyse GIS-Langsamverkehr (GIS-LV) und das entsprechende Datenmodell (DM-LV) erarbeitet. Eine wesentliche Erkenntnis war, dass zur Bearbeitung des Langsamverkehrs die entsprechenden Grundlagendaten zum Wandern und Velofahren, sowie IVS flächendeckend über die ganze Schweiz vorhanden sein müssen. Aus diesem Grund ist beabsichtigt die spezifischen LV-Grundinformationen auf den Referenzdaten der swisstopo (VECTOR25) aufzubauen. Das Teilprojekt Langsamverkehr wurde im Januar 2005 auf Antrag der Gesamtprojektleitung hin aufgesplittet in einen Teil Datenmodell und Datenkatalog Langsamverkehr und einen Teil IVS für die Webapplikation, welche die historischen Verkehrswege der Schweiz über Intranet/Extranet verfügbar machen sollen. Die Voranalysenphase ist abgeschlossen. Das Datenmodell wird noch an die Anforderungen von MISTRA angepasst. Die Fachapplikation selber wurde zurück gestellt, die Daten sollen jedoch im Basissystem mit den vorhandenen Basisfunktionen erfasst und verwaltet werden. Die Haupttätigkeiten konzentrieren sich ab 2006 auf die Datenerfassung Inventar der historischen Verkehrswege der Schweiz (IVS) Um den enormen Papierberg bei der Publikation und Nachführung des IVS zu vermeiden, ist geplant, die Vernehmlassung der Verordnung zum IVS (VIVS) und das Bearbeiten/Nachführen des IVS selbst mit elektronischen Medien zu unterstützen. Aus diesem Grund ist im WEB-GIS-Projekt von KOGIS die Pilotapplikation WEB-IVS in Vorbereitung. Voraussichtlich gegen Ende 2005 wird der Entwurf des Inventars der historischen Verkehrswege für die ganze Schweiz über diesen digitalen Weg für alle Kundensegmente von MISTRA frei zugänglich sein. Das Inventar der historischen Wege der Schweiz (IVS) wird als eigenständige Fachapplikation geführt. Das Inventar der historischen Verkehrswege Schweiz (IVS) liegt heute im Entwurf vollständig digitalisiert vor und soll mit seinen Kurzbeschreibungen demnächst via Intranet/Internet veröffentlicht und behördenverbindlich werden, als Novum in der Bundesverwaltung. Die Webapplikation dient auch für die vorgesehene Vernehmlassung und als Basis für die Beurteilung von kantonalen Gesuchen um Finanzhilfen sowie für die Nachführung Sonderbewilligungen Für die Ausstellung der Sonderbewilligungen wurde ein Informatikmittel ASTRA mit Bewilligungsformular, Rechnungsstellung, Verbuchung sowie Schnittstelle zu SAP gesucht. Eine Arbeitsgruppe sollte die Informationen zur Fahrstrecke inklusive der sich darauf befindlichen Hindernissen als Grundlage zur Erstellung der Sonderbewilligung eruieren. Die Befragung der Transportfirmen, kantonalen Stellen und der Polizeidienste hat ergeben, dass kein klarer Bedarf bezüglich den Sonderbewilligungen besteht. Das Teilprojekt wurde daraufhin im Januar 2005 auf Antrag der Gesamtprojektleitung sistiert. 11

18 Erhaltungsmanagement Für das Erhaltungsmanagement wurden im Rahmen des Projektes UplaNS strategische Vorgaben festgelegt. Gleichzeitig wurde das Management des Gesamtsystems und diejenigen der Teilsysteme (Fahrbahn, Brücke, Elektromechanik) definiert und die Zusammenarbeit geregelt, damit eine Optimierung auf Stufe Gesamtsystem möglich wird. Die Unterstützung mit einem Informatik- Hilfsmittel wurde nicht realisiert. Die Kantone hingegen haben die strategischen Vorgaben in Unterhaltsabschnitte (Abschnitte UplaNS) umgesetzt. Das Teilprojekt wurde im Januar 2005 auf Antrag der Gesamtprojektleitung hin gestoppt und zurück gestellt. Grobe Überlegungen zum übergeordneten Erhaltungsmanagement werden im Rahmen des Erhaltungsmanagements der einzelnen Teilsysteme Fahrbahn und Kunstbauten angestellt. 4 Ziele und Lösungen 4.1 Vision Integrales, betriebs- und volkswirtschaftlich effektives und effizientes Informations- und Kommunikationssystem Strasse und Strassenverkehr für das ASTRA als Entscheidgrundlage bei Netzkonzipierung, Netzbereitstellung, Netznutzung und zur breiten Nutzung durch alle Partner (Bundesstellen, Kantone, Agglomerationen). Die Vision wird anhand einiger Beispiele in den folgenden Kapiteln umschrieben Unterhaltsstrategie Herr X erhält als Mitarbeiter des ASTRA den Auftrag die umfassende Unterhaltsstrategie für die Nationalstrassen für die nächsten 5 Jahre zu entwickeln. Das heisst, dass er zunächst das gesamte Inventar mit dem Wiederbeschaffungswert der gesamten Nationalstrassen-Infrastruktur in Erfahrung bringt. Dann will er die aktuellsten Strassenzustandsindices der letzten Messkampagnen beiziehen. Mit Hilfe der aktuellsten Mehrjahres-Prognosen zum Verkehrsaufkommen lässt sich der jährliche Wertverlust der Strasse, also die Zustandsentwicklung, ermitteln. Die Zustandsentwicklung der Kunstbauten und der elektromechanischen Anlagen will er ebenfalls mit den Zustandswerten und jährlichem Wertverlust erheben. Anschliessend gilt es die über die nächsten 5 Jahre optimierten Erhaltungsabschnitte zu bilden. Zusätzlich ist dabei der Mindestabstand zwischen den Baustellen zu berücksichtigen. Zudem sind in den festgelegten Erhaltungsabschnitten vorgezogene Unterhaltsmassnahmen zu prüfen, die in den nächsten 5-10 Jahren fällig werden könnten. Als Resultat will Herr X einerseits eine Gesamtübersicht der Schweiz mit den optimierten Unterhaltsabschnitten farblich unterschieden pro Jahr. Pro Unterhaltsabschnitt wird eine Kartenübersicht mit den verschiedenen Objekten und geplanten Massnahmen benötigt. Schliesslich sollen diese Auswertungen auch noch in Listenform mit den genauen Daten pro Unterhaltsabschnitt zusammengestellt werden. 12

19 In Zukunft setzt sich Herr X an seinen Computer, startet den Internet Explorer und die MISTRA- Intranetseite. Er hat sofort die Gesamtübersicht der Schweiz mit dem Nationalstrassennetz vor sich. Über das Objektverzeichnis der Nationalstrassen-Infrastruktur lässt er sich eine Rangliste der zustandkritischen Objekte für das Jahr 2008 anzeigen und hält die 100 wichtigsten Objekte in einer Selektion fest. Nun erfolgt die Definition und Optimierung der Unterhaltsabschnitte für die ausgewählten Objekte. Über die mitgeführte Kostenliste wird die Einhaltung der Budgetvorgaben für 2008 kontrolliert und die endgültige Auswahl getroffen. Abschnitt für Abschnitt ü- berprüft Herr X am Bildschirm die getroffene Auswahl und bringt noch interaktiv Korrekturen an. Anschliessend speichert er bei den ausgewählten Objekten die vorgesehenen Unterhaltsmassnahmen für Die gleiche Prozedur wiederholt Herr X für das Jahr 2009, dann 2010 bis 2012 und erhält in Kürze die erwünschte Unterhaltstrategie. Bemerkenswert ist, dass bei der Definition und Optimierung der Unterhaltsabschnitte zum Beispiel im Jahr 2010 auch die vorgesehenen Unterhaltsmassnahmen für 2008 und 2009 korrekt berücksichtigt werden und nicht mehr als zustandkritische Objekte erscheinen Ausbauprojekte Das ASTRA hat die Planunterlagen zum kantonalen Ausbauprojekt Kantonsstrasse Bern- Schwarzenburg erhalten. Bei der Dossierregistrierung schaut Frau M in die MISTRA- Intranetseite, ob das Projekt schon vom Kanton eingegeben wurde. Dazu gibt sie den Projekttitel "Ausbauprojekt Kantonsstrasse Bern-Schwarzenburg" als Suchkriterium ein. Tatsächlich wird dieses im grafischen Übersichtsfenster angezeigt. Als nächstes werden die zu begrüssenden Verantwortlichen im ASTRA definiert. Ein Standardmenu für die Vernehmlassungen mit einem Vorschlag der zu behandelnden Themen und Zuständigen erscheint dazu am Bildschirm. Das System prüft, ob die vorgeschlagenen Personen anwesend sind und in den nächsten Tagen das Dossier bearbeiten können. Nachdem Dossierbehandlung und Termine festgelegt sind, gibt Frau M es zur Bearbeitung frei. Die Themenverantwortlichen können über die MISTRA-Intranetseite gleichzeitig ihre Stellungnahmen erarbeiten und Änderungsvorschläge als Varianten im Dossier ablegen. Diese sind wiederum allen Themenverantwortlichen zugänglich und können entsprechend mitberücksichtigt werden. Sobald alle Stellungnahmen erarbeitet sind, meldet das System dies dem Dossierverantwortlichen per . Dieser kann nun die Schlusskontrolle durchführen und allfällige vorhandene Widersprüchlichkeiten in den Stellungnahmen oder Unvollständigkeiten bearbeiten lassen. Sind auch diese Arbeiten erfolgreich abgeschlossen, geht das Ausbauprojekt zurück an den Kanton. Da alle Arbeiten im System MISTRA dokumentiert wurden, erhält der Kanton diese nicht nur in Papierform, sondern er kann direkt über das System MISTRA darauf zugreifen. Mit den entsprechenden Zugriffsberechtigungen kann im Kanton das Projekt weiterbearbeitet werden. 13

20 4.1.3 Ausnahmetransporte Der Transporteur A aus Deutschland hat einen Transport von Stuttgart nach Gstaad durchzuführen. Sein Fahrzeug übertrifft das zulässige Gewicht in der Schweiz, folglich muss eine Sonderbewilligung beantragt werden. Der Transporteur A setzt sich an seinen Computer und gelangt über die Internetseite des ASTRA zum Bereich Sonderbewilligungen. Zunächst wird der Transporteur A seinen Ausgangsort und den Zielort eingeben. Anschliessend schlägt das System grenzüberschreitend die optimale Route vor, einerseits als Karte, andererseits als Beschrieb. Zusätzlich erstellt ihm das System auf dieser Grundlage die benötigte Sonderbewilligung aus. Alles ist nun für den Transport bereit. In Folge Unvorhergesehenem und im Einverständnis mit dem Warenempfänger verzögert sich der Transport. Die Fahrt verläuft reibungslos bis zur Schweizer Grenze. Nach der Kontrolle geht es weiter bis nach Bern, dort weist ihn das Verkehrsbeeinflussungssystem darauf hin, dass die Strasse nur bis Zweisimmen für LKWs befahrbar ist, da ein Steinschlag einen Teil der Strasse verschüttet hat und diese nun in Folge der Aufräum- und Unterhaltsarbeiten nur noch für den Personenwagenverkehr geöffnet ist. Der Fahrer setzt sich mit seinem Handy direkt mit dem Transporteur A in Verbindung und fragt nach einer alternativen Route. Der Transporteur A konsultiert nochmals die ASTRA-Internetseite Sonderbewilligungen, gibt den neuen Ausgangsort Bern und Gstaad als Zielort ein und lässt sich die neue Route berechnen. Das System schlägt ihm nun eine Route über Bern-Fribourg-Bulle-Gruyères vor. Die temporäre Strassensperrung Zweisimmen - Gstaad für den Schwerverkehr ist bereits im System nachgeführt. Nachdem er den Routenbeschrieb und die aktualisierte Sonderbewilligung als Textdateien vom System erhalten hat, sendet er diese an seinen Fahrer per SMS. Dieser kann seine Fahrt fortsetzen und die Ware noch am gleichen Tag in Gstaad abliefern Verkehrssicherheitspolitik (Via Sicura) Frau S von der ASTRA-Verkehrssicherheitspolitik hat vom Direktor ASTRA den Auftrag den Erfolg der angeordneten Massnahmen seit der Einführung der neuen Politik vor 3 Jahren zu überprüfen. Sie geht dazu auf die MISTRA-Intranetseite und holt sich die jährlichen Strassenverkehrsunfälle mit Toten und Schwerverletzten der letzten 5 Jahre vor der Umsetzung von VESIPO als Referenzsituation aus dem System. Zusätzlich lässt sie sich die Unfallschwerpunkte grafisch am Bildschirm anzeigen und die wichtigsten Schwerpunkte festhalten. Sie lässt sich auch die von den Kantonen und Gemeinden getroffenen Massnahmen bei den Unfallschwerpunkten anzeigen. Danach erstellt sie die gleiche Auswertung über die letzten 3 Jahre. Nun hat sie die wesentlichen Grundlagen zur Erstellung des Evaluationsberichtes VESIPO, um erste Aussagen machen zu können. 14

21 4.2 Systemziele Übergeordnete Ziele MISTRA hat folgende übergeordneten Ziele: 1. Unterstützung strategischer Entscheide "Wo wirkt der eingesetzte Steuerfranken am meisten?" 2. Unterstützung der täglichen Arbeit mit geografischen Daten 3. Information der Öffentlichkeit Daraus abgeleitet lassen sich die nachfolgenden Ober- und Hauptziele definieren Oberziele 1. Aufbau MISTRA Das Management-Informations-System Strasse und Strassenverkehr unterstützt integral die strategische, konzeptionelle und operative Steuerung der Aufgabenbereiche Netzkonzipierung, Netzbereitstellung (Bau, Ausbau, Unterhalt, Betrieb) und Netznutzung des ASTRA sowie sinngemässer Aufgaben professioneller Strasseneigentümer und strassenbezogener Netzbetreiber. 2. Ablösung technisch überholter Informatiklösungen Die Ablösung der Informatiklösung STRADA-DB erfolgt vollständig und unproblematisch mit Integration der entsprechenden Fachapplikation in MISTRA. Die vorhandenen Sachdaten werden migriert. 4.3 Hauptziele 1. ASTRA-Leistungserstellung Die Leistungserstellung des ASTRA wird im betriebs- und volkswirtschaftlichen Sinne effizienter. 2. ASTRA-Wertschöpfung Die Wertschöpfung des ASTRA ist kundenorientiert, das heisst mit verbessertem Nutzen für den Kunden. 3. Wiederkehrende Kosten Das Kosten/Nutzen-Verhältnis bei den wiederkehrenden Systemkosten für Betrieb, Wartung, Support, muss verbessert werden. 15

22 Zur Erreichung dieser Hauptziele sind die folgenden Rahmenbedingungen zu berücksichtigen: Die bestehenden Daten (Basis- und Fachdaten) sind ohne Verluste zu übernehmen. Die Daten und Fachapplikationen werden Dritten zu den Grenzkosten angeboten. Die internationalen Entwicklungen sind zu berücksichtigen. Die Aufgabenzuständigkeiten sind gemäss dem volkswirtschaftlichen Aufwand zu optimieren Systembezogene Ziele Aus den übergeordneten Zielen ergeben sich die systembezogenen Ziele sowie die Anforderungen an das System. Investitionsschutz 1. Bedeutende Investitionen gut schützen und breiten Gebrauch sicherstellen Einhaltung der Standards von Bund (KOGIS, swisstopo, BIT) und ASTRA Produktestandards ASTRA (MS-Office, GIS usw.) VSS-Normen sind einzuhalten bzw. müssen in begründeten Fällen an MISTRA angepasst werden (p. ex. Raumbezug, Topologie) [8]. Applikationen und Web-Services 2. Stufengerecht einsetzbar (Politik, Leitung, Betrieb und Unterhalt) Einstieg, Bedienung und Funktionsumfang der Lösung müssen stufengerecht ausgeführt werden können. 3. Praxisbezogene, einfache Lösung Für die Mehrheit der Anwender, die nur lesend zugreifen, muss die Bedienung einfach und intuitiv sein, möglichst über einen Web-Client. Für die Anwender, die für die Datenbewirtschaftung zuständig sind, muss sich die Benutzeroberfläche am Look & Feel von Windows-Anwendungen orientieren (Windows-Richtlinien) und in weitverbreitete GIS-Produkte integriert sein. 4. Einfache Ausgabe von Daten&Informationen (Statistiken, Listen, Pläne, Achsband) Der Report Service muss direkt, d.h. ohne Zwischenschritte und Datentransfers möglich sein. Der Arbeitsfluss muss kurz und intuitiv für alle Kundensegmente von MISTRA sein. 5. Mehrsprachig D / F / I / (E) Die Software muss sprachunabhängig konzipiert werden. Die verwendeten Texte für Oberfläche, Meldungen, Reports und Pläne müssen parametrisierbar sein. Die Texte werden in separaten Tabellen gehalten. Handbücher und Online-Hilfe werden mehrsprachig erstellt. 6. Sowohl für grosse, als auch für kleine Strassennetze einsetzbar Die Lösung muss sowohl für den Betrieb grosser Strassennetze in Multi-User-Umgebungen, als auch bei kleinen Netzen im Single-User-Betrieb mit vertretbaren Kosten möglich sein. Dies hat insbesondere Konsequenzen auf die benötigten Lizenzen für Datenbank- und GIS-Software. 16

23 7. Einfache und schnelle Ausbildung der BenutzerInnen Die Schulung für den Rich-GIS-Client muss in 3 bis 5 Tagen möglich sein, inkl. Einführung in die Benutzung der Fertigprodukte. Für die Web-Clients muss eine 1/2 tägige Schulung ausreichen. 8. Leistungserstellung ohne Medienbrüche Durchgehend digitale Arbeitsflüsse für die Haupttätigkeiten. Beizug von analogen Daten nur in Ausnahmefällen und bei sehr ungünstigem Kosten-Nutzen-Verhältnis der digitalen Verarbeitung. Die Daten innerhalb einer Organisation (= MISTRA-Instanz) werden in einer autonomen Datenbank gehalten. Das Schlüsselkonzept muss den Datenaustausch mit anderen Organisationen (p. ex. Kantone) konfliktfrei und ohne Verletzung der Datenhoheit ermöglichen. Informatik-Komponenten 9. Erweiterbare Lösung, d.h. zukünftige Bedürfnisse müssen integriert werden können Zu verwenden sind markgängige Datenbankprodukte (Oracle). Die Datenstrukturen müssen transparent und in 3. Normalform sein. Der Zugriff zu den Daten muss mit ANSI-SQL-Befehlen möglich sein. Die Verwendung von Stored Procedures ist zu minimieren und darf den Grundsatz der Datenbanksystemunabhängigkeit nicht verletzen. Die referentielle Integrität ist ohne Verwendung von Stored Procedures sicher zu stellen. Die Software ist in verschiedenen Applikationen gegliedert, welche nach Bedarf eingesetzt werden können (Skalierbarkeit). Durch die Verwendung von Standards (.NET, ANSI-SQL, ISO/TC211 / opengis 1, Interlis2) muss die Interoperabilität über verschiedene Plattformen so weitgehend wie heute möglich gewährleistet werden. 10. Hohe Verfügbarkeit, Stabilität und Zuverlässigkeit Das System muss eine angemessene Verfügbarkeit, p. ex. 6 x 18, zulassen (präzise Vorgaben sind in Kapitel aufgeführt) Die Daten und Applikationen müssen kontinuierlich gesichert werden können, damit im Fehlerfall ein Systemneustart innert 4 Stunden möglich ist. 11. Zusammenarbeit über verschiedene Plattformen und IT-Komponenten gewährleistet Durch die Einhaltung von Standards und den Einsatz von Web-Services wird die Interoperabilität mit allen Partnerorganisationen zu Strasse und Strassenverkehr weitgehend sichergestellt. 12. Minimierung der Betriebskosten Die Datenbewirtschaftung muss über marktgängige GIS-Produkte möglich sein. Für die Ausgabe von Business-Reports sind einfache Werkzeuge einzusetzen (p. ex. Excel, BI-Tools). Durch einen hohen Anteil von Fertigprodukten müssen die Kosten für die Wartung von Software möglichst tief gehalten werden. 13. Einfache Installation von Datenbank und Applikationen (inkl. Updates) Für die Installation der Software sind Setup-Prozeduren bereit zu stellen. Insbesondere die Business Processes (siehe [2]) müssen möglichst für alle Kundensegmente von MISTRA ohne Installationsaufwand verwendbar sein. Daten und Informationen 1 Die relevanten ISO-Normen und OGC-Spezifikationen sind in [15] bis [19] aufgeführt. 17

24 14. Bestehende Daten soweit wie nötig berücksichtigen Grundsätzlich wird bei der Erstellung der Sockeldatenbank versucht, mit den vorhandenen Daten aus STRADA, KUBA, Kartendaten wie VECTOR25 usw. zu arbeiten Neuerfassungen sind nur in begründeten Ausnahmefällen zulässig Verlustfreie Übernahme von Daten aus den heutigen Systemen 15. Daten und Informationen schweizweit aktuell Der Datenbestand deckt grundsätzlich die gesamte Schweiz flächendeckend ab. Dabei kann die inhaltliche Tiefe der Objekte und Sachinformationen von den nationalen über kantonale zu den lokalen Stellen im definierten Rahmen variieren. 16. Daten und Beziehungen objektorientiert und systemunabhängig beschrieben Erstellung des Datenmodelles als ER- oder UML-Klassendiagramm und Datenbeschreibung Interlis Die in MISTRA enthaltenen Daten sind gemäss dem Metadatenstandard von KOGIS beschrieben. Die Metadaten sind für Suchdienste zugänglich Bereitstellung der Metadaten gemäss ISO19115 (Profil GM03 gem. [12]) Publikation der Metadaten zu Handen von Suchdiensten, p. ex. GeoCat [11] (s. auch Kap. 6.1) 18. Einfacher Austausch von Daten zwischen Bund und Kantonen Die Daten müssen selektiv über Interlis2-Schnittstellen ausgetauscht werden können. Schlüsselverletzungen beim Import müssen in jedem Fall vermieden werden. Die zeitliche und räumliche Konsistenz der Daten muss überprüft werden. Das Eigentum an den Daten muss klar definiert sein. Die singuläre und eindeutige Datenherrschaft (Mutationsrecht) ist vom System sicher zu stellen. 19. Die räumlichen Objekte sind in den gebräuchlichen Referenzsystemen georeferenziert Die Objekte sind in Landeskoordinaten (x, y, z) abgelegt Bei spezifischen Themen (p. ex. Unterhalt, Betrieb) werden zusätzlich linear referenzierte Gebrauchskoordinaten (u, v) geführt 20. Die Nachführung oder Historisierung sowohl der Basisgeometrie (p. ex. VECTOR25) wie, sofern erforderlich, auch der Sachinformationen erfolgen einfach und ohne Verluste. Der Nachführungszyklus ist bedarfsabhängig pro Objektklasse geregelt. Er variiert zwischen täglich und mehrjährig. Organisatorische und finanzielle Gewährleistung der konsistenten Datennachführung über die verschiedenen autonomen Datenherren (ASTRA, Bundesämter, Kantone, Gemeinden) Verkehrszähldaten werden als aggregierte Tageswerte, als Ganglinien oder eventuell auch als Stundenwerte abgelegt. Die Zustandserhebungen der Strassenobjekte erfolgen in einem regelmässigen Mehrjahres- Turnus, welcher in Abstimmung mit den VSS-Normen oder anderen, einschlägigen Praxisleitfäden festgelegt wird. Veränderungen in der Realität werden innert Tagesfrist an den entsprechenden Daten aktualisiert. 18

25 Projekt-Management 21. Das Projekt ist akzeptiert, die Meilensteine sind eingehalten, die Risiken sind bekannt und minimiert, die Ablösung der bestehenden Systeme erfolgt problemlos Kleine überblickbare Einheiten (Module) mit geringem Realisierungsrisiko erstellen. Die Betroffenen (Benutzer, Kunden, insbesondere Kantone und Agglomerationen) werden zu allen wesentlichen Entwicklungsschritten einbezogen. Mittels einer bedarfsgerechten, klaren und offenen Kommunikation sind die Betroffenen gut über den jeweiligen Projektstand im Bilde Die stufenweise Ablösung der bestehenden IT-Systeme erfolgt erst, wenn die entsprechenden MISTRA-Applikationen funktionieren, so dass zumindest ein gleichwertiges Arbeiten für alle Benutzer möglich ist. 5 Anforderungen Musskriterien 1. Der Auftraggeber verlangt für die Realisierungsphase ein iteratives Vorgehen. Die Gründe für das iterative Vorgehen sind: Einflussnahme des Auftraggebers und der mitwirkenden Kantone auf das System Design Die frühzeitige Beherrschung der technischen Risiken Die Möglichkeit der inkrementellen Inbetriebnahme Die Inhalte der Iterationen sind in Kap und die zeitliche Abwicklung in Kap beschrieben. 2. Bei der Realisierung werden drei Pilotkantone (BE, VD, ZH) miteinbezogen. Es muss eine Testumgebung für das ASTRA und die Pilotkantone realisiert werden. 3. Im Rahmen der Realisierung erarbeitet der Auftragnehmer eine Detailspezifikation (Systemdesign nach HERMES), welches die Vorgaben gemäss Datenkatalog [3] und diesem Pflichtenheft konkretisiert und verfeinert. Zum Systemdesign gehören: Geschäftsprozesse des Basissystems gemäss Dokument [2] Verfeinerung der Beschreibung der Use-Cases Detailliertes Objekt- und Datenmodell auf der Grundlage des Datenkataloges [3] Layout des GUI für Rich- und Browser-Client (nur Intranet) Beschreibung der verwendeten Algorithmen und Berechnungsgrundlagen Die Detailspezifikation wird im Rahmen der Iterationen (möglichst strukturiert nach den klar spezifizierten Geschäftsprozessen in den Bereichen Integration Processes, Content Processes, Business Processes sowie IT Operation Processes, vgl. [2]) schrittweise erstellt. Jeder Schritt bedarf der Prüfung und Genehmigung / Freigabe durch den Auftraggeber. Mit der Codierung darf erst nach der jeweiligen Freigabe begonnen werden. 4. Die Leistungen sind in diesem Pflichtenheft, im UseCase-Diagramm [4] und im Preis- / Leistungsverzeichnis beschrieben. 19

26 6 Exigences envers le système de base 6.1 Système de base : exigences relatives à sa réalisation Structure et limites du système Représentation schématique de la limite du système MISTRA : Fournisseurs OFROU, offices fédéraux, cantons, agglomérations et villes, mandataires, professionnels New ASTRA Clients Confédération, OFROU, offices fédéraux, cantons, agglomérations et villes, mandataires, professionnels, public SIC Système de base Légende: AM BCI/SIC AM AM Bruit AM Immeubles AM Cadastre Applications de base: application de base SIG, administration, analyse+état, axe tendu, Data Warehouse) Métadonnées sur les données de base et généralistesg Données généralistes de la route et du trafic: ouvrages, voies, couche de roulement, trafic, accidents, coûts, locomotion douce Données de base de la route et du trafic: axes, géométries d axe, réseaux métier, topologie, intervenants, objets routiers, etc. Autres données de base: réseaux surfaciques, cartes pixel, VECTOR25/200, orthophotos, modèles altimétriques, noms géographiques, etc. Système informatique (matériel, OS), bases de données, Processus soutenus par une application métier Services Web pour les clients Limite du système MISTRA Business Collaboration Infrastructure / Système d information et de communication Communication Métadonnées sur les données spécialistes Applications métier existantes, données de tiers p. ex. KUBA, STRADA, swisstopo, GT-CH, LKC, etc. Ouvrages d art Information routière Données de tiers Figure 2 : Structure et limites du système Données de base swisstopo Données de base Navigation AM AM Accidents de la circulation AM Monitorage du trafic AM Chaussée + équipements AM Ouvrages d art + tunnels AM Locomotion douce AM Voies de coomunicat. hist. Chaussée Navigation Swisstopo COSIG Migration données AM Gestion de l entretien Serveur SIG, Internet, intranet Electromécanique GT-CH GT DETEC AM Entretien courant AM Gestion du trafic AM Evacuation des eaux Données spécialistes de la route et du trafic Gestion de l entretien LKC Etc. AM WEB-GIS: UH-PERI WEB-GIS: IVS Webservice Catalogue de données + modèle de données geocat.ch de COSIG Modèle de données Les relations entre les objets seront définies en fonction des résultats escomptés. Webservice MISTRA, phase I: 1. sans exploitation 2. sans gestion du trafic 3. focalisé sur l infrastructure des routes nationales, la locomotion douce, les accidents de la circulation et le monitorage du trafic La représentation ci-dessus donne un aperçu global de l insertion du projet MISTRA. La définition et la description des prestations de l OFROU (et des processus associés) en fonction des besoins et de la situation des fournisseurs et des clients y revêtent une importance centrale. Ces divers besoins sont représentés de manière approximative et non encore définitive dans les différentes applications métier qui servent à soutenir les processus [2] en fournissant les résultats souhaités. Pour l OFROU, ce sont par exemple les conclusions tirées de l évolution des accidents sur les routes, l évolution du trafic avec indication spécifique des tronçons engorgés et des durées d embouteillage, l évaluation et l accompagnement de projets de construction ou d aménagement, le maintien et le succès de mesures de protection contre le bruit ou la promotion de la locomotion douce. Résultats prioritaires pour les clients : cartes routières avec extensions prévues, cartes 20

27 des accidents avec listes et localisation des points noirs, itinéraires de randonnée ou vues d ensemble des centres d entretien routier actuels et prévus. Les fournisseurs élaborent par exemple des projets détaillés pour des objets spécifiques à entretenir ou relèvent les données des accidents ou du réseau de chemins de randonnée pédestre. Pour que le développement des applications métier puisse être efficace et efficient, toutes les personnes impliquées doivent recourir à un système commun d information et de communication, la Business Collaboration Infrastructure (BCI). Le système de base de MISTRA constitue une BCI et se compose des parties suivantes : systèmes informatiques, bases de données, applications de base, Internet-intranet et données généralistes et de base relatives aux routes et au trafic routier. Les applications (applications métier et externes de spécialistes, fournisseurs et clients ainsi que services Web publics destinés aux utilisateurs finaux) accèdent aux systèmes et aux données par le réseau de transmission de données, donc via la BCI. La BCI reproduit l environnement informatique et réseau des différents participants, ce qui permet une collaboration constructive et efficiente avec tous sans ruptures de la chaîne de l information. Cela signifie que la BCI est structurée de manière hétérogène, en partie centralisée, en partie décentralisée. Grâce au respect des normes convenues (modèle de données, catalogue de données [3], technologie Web, système SIG, bases de données, réseau informatique, etc.), les systèmes informatiques peuvent collaborer avec les applications et les données. Les données socles de la BCI englobent l ensemble des métadonnées, données de base et données issues des applications métier intéressantes pour plusieurs domaines spécifiques (données généralistes). Le modèle de données de la base de données socle fait l objet d une convention ferme, mais il doit être extensible, p. ex. si on veut intégrer les données de nouveaux domaines spécifiques. Les modifications et extensions apportées à la structure des données socles doivent être coordonnées à grande échelle et requièrent l approbation d une instance encore à définir, à l intérieur ou à l extérieur de l OFROU. Les applications de base font partie intégrante de la BCI, du système de base MISTRA et du Data Warehouse. Elles comprennent les cas d application pour l exécution des processus [2] : processus de gestion PG pour les tâches de direction (accès, publication des données) ; processus de prestations PP pour les analyses, l établissement de cartes, rapports et axes tendus et la diffusion de données ; processus de traitement des données PD pour le traitement des données de base (temporairement, le système de base traite aussi certaines données généralistes et spécialistes) ; processus d intégration PI pour l importation de données de base de tiers et de données généralistes d applications métier et externes ; processus d exploitation du système PS pour la gestion des modifications, des droits, etc. L intégration des données fait partie de la réalisation. Les prestations correspondantes sont à offrir en option. La DP MISTRA prendra la décision ultérieurement. 21

28 Les données avec référence spatiale sont gérées par le biais d une interface SIG. Il est prioritaire de mettre rapidement à disposition une application de base pour le Rich GIS Client et le Web GIS Client ainsi qu un outil d analyse (Data Warehouse). Autres applications de base : Axes tendus et Administration des données socles. A plus long terme, plusieurs logiciels, avec ou sans SIG, seront en mesure de gérer les données socles conformément à MISTRA. Les applications de base sont réalisées avec un «look & feel» standard. On entend par applications métier non seulement des outils pour la documentation de la base, mais aussi pour la gestion de l entretien, la planification, la réalisation de simulations, etc. Les applications métier nécessitent des données spécialistes. Elles ne sont pas gérées comme partie de la BCI. D autres applications métier ont besoin de ces données spécialistes le plus souvent sous forme agrégée et le système de base doit les mettre à disposition comme données généralistes. Afin de rendre possible leur intégration dans la BCI, des normes adéquates (catalogue de données [3], modèle de données [4], règles de saisie) sont aussi traitées pour ces données. Les applications métier fonctionneront de façon entièrement autonome, c est-à-dire indépendamment de la base de données socle. Elles disposent donc, indépendamment de MISTRA, d un classement des données géré de façon autonome. Elles entrent en contact avec les données socles quand elles : vont chercher les données de base ou générales d autres applications métier ou enregistrent des données généralistes issues de l application métier dans les données fondamentales. La base de données socle et les applications de base n accèdent en principe pas au classement des données des applications métier (données spécialistes). Les échanges de données relèvent exclusivement des applications métier. Le système de base met à disposition des interfaces standardisées pour l accès aux données (v. ci-dessus). L accès à la base de données socle a lieu par des interfaces standardisées (cf. chap ). Les interfaces sont réalisées en priorité pour l accès hors ligne (transferts Interlis2), mais aussi pour l accès en ligne comme services Web. L intégration réussie et complète des données des collections existantes (STRADA-DB, UH- PERI, etc.) conclura les travaux de mise sur pied du système MISTRA. La conception par applications permet une démarche graduelle (itérative) pour la réalisation, un développement rapide des différents composants ainsi que de la flexibilité par rapport à l évolution technologique. Cette conception permet de construire un système extensible et adaptable en fonction des besoins. S il faut échanger des données non prévues dans le modèle de la base de données socle, il y a lieu d étudier une extension de ce modèle. Toutes les données sont décrites dans des métadonnées et accessibles pour des services de recherche tels que geocat du COSIG. Le modèle de métadonnées est déterminé par la norme internationale ISO/DIS 19115, avec le modèle de métadonnées GM03 d après le COSIG (cf. [11] et [12]). L implémentation spécifique à MISTRA du modèle GM03 est documentée dans le catalogue de données [3]. Les applications de base et les interfaces avec la base de données socle 22

29 doivent garantir la gestion des métadonnées. La base de métadonnées est structurée et exploitée comme élément de la base de données socle Architecture du système MISTRA L'architecture conceptuelle du système global de MISTRA est représente dans la figure 3. AM Chaussée / inst. annexes FA Ouvrages d art / tunnel AM Accidents de la circulation FA Monitorage du trafic Locomotion douce AM voies de comm. Histor. AM... Controlling des investissments IGD: Intervenants, documents Informations routières Navigation routière Agglo A Canton X Commune B Instance MISTRA (OFROU) Canton Y Office fédéral C Internet/Intranet Canton Z Instances MISTRA Applications métier Applications tiers Services Web Cartes pixel VECTOR 25/200 Swissnames WebGIS:IVS WebGIS PeriNS Rés. chem. pédestre Rés. Cacl.Velo/VTT Figure 3 : Architecture conceptuelle du système global MISTRA Le cœur de la solution est le système de base avec la base de données socle (BDS). Le système de base joue le rôle de plaque tournante pour les données et l information entre les différents systèmes et applications, aussi bien en interne que pour les relations avec les fournisseurs (cantons, agglomérations, responsables des services spécialisés) et les clients. Suivant l application (service spécialisé, service Web), on accédera soit seulement à la BDS ou à la base de données métier (KUBA, STRADA, trafic, LD, etc.), soit à des informations qui combinent l une et l autre. En principe, toutes les données interapplications se trouvent dans la BDS. 23

30 Avec différents offices fédéraux, les cantons, les agglomérations et certaines communes (agglomérations), il y aura des échanges de données entre les différentes bases de données. Avec certains services, ils auront lieu directement en ligne si les conditions économiques et techniques sont favorables, sinon hors ligne. Le grand public pourra accéder par Internet à une information prétraitée, via des services Web et des applications Web. Il est prévu de réaliser ces applications et les données correspondantes avec la solution Web GIS du COSIG. A cet effet, les données sont répliquées dans la ZDM de la Confédération Architecture du système de base OFROU / Confédération / Cantons Public Internet Client tier Rich-GIS, -Admin Web-GIS, -DWH, -Admin Web-GIS, -DWH Client métier Client-SIG Data tier Application tier Appl. Serveur AS Data-Access Données métiers GIS-Serveur (Service-Interface) Data Access Layer Données géographiques Map-Server Métadonnées et données métiers Web-Serveur ETL ETL BI-Serveur Data Marts ETL ODS ETL DWH Firewall Geo Service Conf. GIS-Serveur Data-Access Données GEO Web-Serveur Map-Serveur BI-Serveur Data Marts ETL données GEO DWH interne DWH externe Environnement de production Intranet (KOMBV) DMZ Conf. Infrastructure internet Figure 4 : Architecture logique du système La figure ci-dessus montre l architecture logique du système MISTRA. Les encadrés représentent les composants logiciels importants. La répartition des composants n est pas stricte. Suivant les besoins, ils peuvent encore être subdivisés. Pour les petites et moyennes installations, les composants doivent pouvoir être réunis au niveau du matériel. Les flèches montrent la direction du flux de données. 24

31 Les différents domaines comprennent : A. environnement de gestion des données de base, en particulier des géodonnées aux postes de travail SIG par le biais de clients riches ; B. environnement destiné à la gestion de données spécialistes et de géodonnées simples et aux utilisateurs de l intranet, qui accèdent à la version actuelle et productive des données fondamentales (lecture et écriture) et au DWH (lecture seule) ; C. environnement pour les utilisateurs d Internet (lecture seule), qui accèdent à un extrait répliqué des données socles, au DWH et aux géoservices de l administration fédérale (dans la ZDM). Un partenariat de référence entre l OFROU et swisstopo règle les détails de cette collaboration. L élaboration des composants de l infrastructure Internet ne fait pas partie des prestations de réalisation du système de base. D. environnement de gestion des données spécialisées par des applications métier sur clients Web ou riches (en dehors des prestations du système de base). Les domaines A et B font l objet de la réalisation du système de base MISTRA. Remarques sur l architecture du système : 1. L architecture du système est représentée logiquement comme une architecture à trois couches. Une fusion des couches accès aux données et application et à prévoir dans de nombreux cas d application. Pour l entrée de gamme, il doit aussi être possible de l installer sur un poste de travail individuel. Selon les informations actuelles, il n y a pas de version d entrée de gamme prévue. L architecture du système choisie devrait toutefois permettre la réalisation ultérieure d une version d entrée de gamme. Cela signifie qu il n y a qu une version à développer et à entretenir. Il doit rester possible toutefois de réunir les composants logiciels sur un matériel unique. Cf. aussi les trois configurations typiques du système selon chapitre La couche "données" comprend les composants d accès aux données. Ceux-ci incluent le logiciel de base de données ainsi que d éventuels produits finis supplémentaires (ArcSDE, éventuellement d autres ; v. chap ). Autres composants représentés : services d extraction (ETC) pour le DWH et le Web GIS Internet. 3. L intégrité des données doit être garantie. La base de données relationnelle Oracle sera utilisée. MISTRA doit fonctionner tant en mode "multi utilisateur" que "mono utilisateur". En mode "multi utilisateur", il s agit de parer aux conflits d accès ; le dernier état cohérent des données doit pouvoir être restauré en cas d erreurs. Cf. aussi la liaison d applications métier selon chapitre

32 4. L accès à la base de données entre l interface de service et les couches d accès aux données des produits finis doit s effectuer indépendamment du système. Il s agit de réduire au minimum les éléments spécifiques aux éditeurs, en particulier les procédures stockées, et dans tous les cas de les fixer avec le mandant. Il doit être possible de remplacer la base de données sous-jacente à une application par des produits d éditeurs différents. L intégrité référentielle sera garantie sans utiliser de procédures stockées. 5. La couche "application" contient les fonctions de traitement des données. Dans les environnements client riche traditionnels, ces fonctions se trouvent en général dans la couche client. La couche "application" contient aussi l interface de service pour l accès aux données fondamentales, cf. aussi chap En vue d'aléger les clients, de relier des clients mobiles et de réduire le coût des licences ainsi que les frais d installation et d exploitation, MISTRA vise une solution orientée serveur. Les fonctions de l interface de service seront réalisées comme services Web tant pour le client riche que pour le client Web. Les fonctions de visualisation, d analyse, d exploitation et de saisie doivent être assurées autant que possible par des services Web en tenant comptedes possibilités techniques actuelles, p. ex. pour mettre à jour des données spécialistes, tracer des graphiques simples, établir des plans, etc. 7. Les applications métier doivent pouvoir fonctionner de façon autonome, c est-à-dire sans MISTRA. Pour se procurer des données socles et écrire des données généralistes, elles utilisent en priorité l interface Interlis2 (hors ligne) ou, à titre d alternative, les interfaces de service (en ligne). Cf. aussi la liaison d applications métier selon chapitre Pour des raisons de sécurité, l administration fédérale exploite une infrastructure séparée pour l accès par Internet. COSIG a pour mission de coordonner les applications Internet de la Confédération. Une infrastructure intranet-internet centralisée (géoservices de la Confédération) est à disposition des offices fédéraux intéressés. MISTRA doit aussi utiliser cette infrastructure. Les géoservices fournissent des données de base pour MISTRA comme services Web cartographiques. MISTRA met également à disposition une copie des données pour la plate-forme Internet (fonction d extraction au format Interlis2). La collaboration est définie et réglée dans une convention entre l OFROU et swisstopo/cosig. 9. La plate-forme COSIG actuelle ne comporte pas de DWH pour Internet. Le mode de réalisation du DWH Internet n est pas encore défini à l heure actuelle. Seuls les services ETC selon chap. 8 font partie des prestations adjugées dans le cadre de réalisation du système de base. 10. L architecture du système doit être conçue de façon à pouvoir s utiliser conformément aux exigences des différents segments de clientèle et aux processus spécifiés pour le système de base. Cf. aussi les trois configurations types du système selon chap Les cantons sont reliés à l intranet de l administration fédérale par le RC. Cette liaison permet d accéder aux données de l instance MISTRA à l OFROU. Il n est toutefois pas prévu que les cantons mettent à jour des données dans l instance MISTRA par le biais de cette liaison. Les cantons et les agglomérations exploiteront leurs propres instances MISTRA. 26

33 6.1.4 Produits et technologies de base Produits et technologies de base pour le système de base (première unité de réalisation) : Systèmes d exploitation couche données Systèmes d exploitation couche application Réseau Systèmes d exploitation clients Base de données pour base de données socle et DWH Windows 2003 ou Unix/Linux ou plus récent Windows 2003 ou plus récent Liaison serveur à 1 Go/s Liaison client à 100 Mbits/s Windows XP ou plus récent Oracle 10g ou plus récent SIG ESRI ArcGIS-Server 9.1, ArcSDE 9.1, ArcIMS 9.1, ArcEditor 9.1 ou plus récent Navigateur Applications bureautiques Plate-forme de développement Tableau 2 : Produits et technologies de base MS Internet Explorer 6.0 ou plus récent Netscape 7.0 ou plus récent MS Office XP ou plus récent.net En phase d exploitation, il faut toujours maintenir et supporter la version en cours et la dernière version majeure. 27

34 6.1.5 Structure modulaire du système L architecture modulaire du système doit autoriser des installations très différentes en fonction de la taille de l'autorité routière. La figure suivante montre trois exemples : Figure 5 : Variantes que permet la structure modulaire du système Le paquet 1 montre l installation intégrale à l OFROU, avec le système de base, toutes les applications métier et le DWH. L interface SIG, a été développé spécialement pour le système de base et intégré dans les produits ESRI. Elle est utilisée pour gérer les données de base. et se compose d un clinet Rich GIS et d un client Web GIS. Le paquet 2 montre une installation auprès d un office fédéral ou d un service cantonal où l utilisation de certaines applications métier et l utilisation de données par le biais du DWH sont prioritaires. Le système de base est utilisé sans son interface SIG parce que les données de base à référence spatiale sont gérées en externe. Le système de base a «seulement» une fonction intégrative. Le paquet 3 montre une installation comme on peut la trouver dans un service ou un bureau d ingénieurs où seules des données de base sont mises à disposition, p. ex. pour le repérage spatial, puis transmises à une administration, p. ex. du type du paquet 2. 28

35 6.1.6 Liaison d applications métier MISTRA Les applications métier (AM) doivent pouvoir s exploiter indépendamment du système de base (SB). Les AM disposent donc toujours de leur propre classement des données, dont la conception peut aussi être totalement différente de celle du SB. Les AM communiquent avec le SB dans les situations suivantes : 1. pour se procurer des données de base (avec les métadonnées correspondantes) ; 2. pour se procurer des données généralistes d autres AM (avec les métadonnées correspondantes) ; 3. pour mettre ses propres données généralistes à la disposition d autres AM (avec les métadonnées correspondantes) (processus système de base PI2). La communication s effectue en ligne ou hors ligne : En ligne (ou de façon synchrone) lorsque l AM et le SB sont tous deux démarrés et qu une liaison directe est possible. Les données sont échangées par accès direct de l AM au SB. Il n en résulte pas de fichiers de transfert. Hors ligne (ou de façon asynchrone) typiquement lorsque l AM et le SB sont exploités dans des environnements différents et qu un accès direct n est pas possible. L échange de données passe par le module d exportation-importation de l AM et du SB. Un fichier de transfert Interlis2 est produit lors de l exportation. Ce fichier est envoyé au destinataire p. ex. par courriel ou sur CD-ROM pour être importé. La variante hors ligne peut aussi s employer au lieu d un transfert en ligne. Lors des échanges de données dans les deux directions, c est toujours l application métier et jamais le système de base qui est le composant actif. Les deux variantes sont techniquement équivalentes. Comme la variante hors ligne est d usage plus universel, c est elle qui sera réalisée en priorité dans le cadre de la première unité de réalisation du système de base. La figure suivante montre les composants système typiques pour ces deux méthodes : Méthode en ligne Application métier Interface SB Méthode hors ligne Application métier Module import-export Fichier de transfert Interlis2 Interface de service Système de base Module import-export Système de base Figure 6 : Liaison avec application métier en ligne vs hors ligne 29

36 Des composants de logiciels sous forme de services Web seront mis à la disposition des éditeurs des applications métier pour développer l interface en ligne. Ils doivent être paquetés et documentés comme bibliothèque de base (WSDL) et peuvent aussi être mis à disposition en code source. Voir aussi à ce sujet la liste des services selon chap Les échanges de données hors ligne avec les AM doivent être automatisables : Un répertoire d échange pour l importation et un autre pour l exportation sont installés pour chaque AM. Les exportations depuis le système de base doivent pouvoir être lancées automatiquement par le biais d un gestionnaire de tâches. Les importations dans le système de base doivent être automatisées par le biais d une interrogation des répertoires d importation. Pour être validées, les importations s effectuent toujours dans une zone d importation temporaire («zone de validation») de la base de données socle. 30

37 6.1.7 Fonctions du système de base destinées à supporter les applications métier Les applications métier ne disposent parfois pas des structures nécessaires à MISTRA pour enregistrer les données de base et n ont parfois pas d interface SIG pour traiter les géométries. La question des fonctions du système de base dont les AM peuvent partager l utilisation se pose pour beaucoup d AM. C est en principe possible de deux manières : 1. données généralistes traitées dans le système de base au lieu de l être dans l AM ; 2. services requis du système de base appeler depuis l AM. Le tableau suivant donne une vue d ensemble des principales fonctions à disposition. Traitement des données généralistes dans le système de base (riche ou Web) plutôt que dans l AM : Processus de traitement des données : Création et traitement de réseaux métier Processus de traitement des données : Création et traitement de réseaux surfaciques Processus de traitement des données : Création et traitement de types d ouvrages Un réseau métier est un niveau ou thème sous lequel il est possible de classer des faits concernant la route et le trafic, p. ex. tronçons de vitesse, d entretien. Si une AM ne dispose pas de la fonctionnalité SIG pour créer et traiter des réseaux métier, il est possible de les traiter en dehors de l AM dans le système de base. La procédure de création d un réseau métier est alors la suivante : 1. gestion de la configuration : définition des exigences par le domaine spécifique : nom, type de réseau, conditions topologiques, valeurs numériques (attributs) du réseau ; 2. gestion de la configuration : définitions de réseau entrées dans la base de données socle par le GC système de base ; 3. processus de traitement des données : tronçons de réseau créés par l opérateur du domaine spécifique ou par la centrale de gestion MISTRA. Exemples de réseaux métier supplémentaires : tronçons de trafic, tronçons d accidents, tronçons routiers en zone dangereuse, codes de localisation TMC Un réseau surfacique est un niveau ou thème comprenant des objets plans, p. ex. cantons, communes, périmètres de projet. La procédure est la même que pour les réseaux métier. Exemples de réseaux surfaciques supplémentaires : découpages administratifs, zones où les exigences de protection contre le bruit sont plus élevées. Un type d ouvrage est un niveau ou thème comprenant des ouvrages de même nature, p. ex. ponts, tunnels, murs de soutènement. Les ouvrages peuvent être de forme ponctuelle, linéaire ou plane. Procédure de création d un type d ouvrage : 1. gestion de la configuration : définition des exigences par le domaine spécifique : nom du type d ouvrage, type de géométrie, valeurs numériques (attributs) de l ouvrage ; 2. gestion de la configuration : définition du type d ouvrage entrée dans la base de données socle par le GC système de base ; 3. processus de traitement des données : ouvrages créés par un opérateur du domaine spécifique ou par la centrale de gestion MISTRA. Exemples de types d ouvrages supplémentaires : glissières de sécurité, panneaux à messages variables, postes de comptage. 31

38 Exemples d appel, depuis l AM, d une interface de service du système de base : Processus de traitement des données : Attribution d objets de l AM au SRB Processus de prestations : Attribution de données aux réseaux métier Processus de prestations : Attribution de données aux réseaux surfaciques Si les coordonnées XY d objets de l application métier sont connues, le service peut calculer et restituer les coordonnées SRB correspondantes (numéro du point de repère, U, V). L appel s effectue pour chaque objet de l AM. Pour les objets ponctuels, le service restitue un triplet de coordonnées, pour les objets linéaires et plans 2 triplets de coordonnées, l un pour la projection minimale et l autre pour la maximale sur l axe SRB. Comme la détermination n est pas toujours univoque, plusieurs triplets de coordonnées SRB, à choix, doivent être restitués le cas échéant. La façon dont les coordonnées SRB sont enregistrées, p. ex. comme attributs dans la table des objets, est l affaire de l AM. Exemples d objets de l AM dont la référence SRB peut être créée de cette façon : poste de comptage, ouvrage, lieu d accident. Pour l utilisation universelle des données issues des AM, il est nécessaire d attribuer des objets d information aux réseaux spécifiques, p. ex. l agrégation de données d accidents sur des tronçons d accidents, de données de trafic sur des tronçons de trafic, etc. L appel s effectue pour chaque objet d AM. La clé du tronçon de réseau correspondant est restituée pour chaque objet d AM à condition que les coordonnées SRB de l objet d AM soient connues. Exemples d utilisation : attribution de compteurs de la circulation à des tronçons de trafic, attribution d accidents à des tronçons d accidents, attribution de tronçons d accidents au réseau métier état des routes, etc. Au lieu d attribuer manuellement des objets de l AM à des surfaces, il est possible de le faire automatiquement en appelant l interface de service. L appel s effectue pour chaque objet. La clé de la surface correspondante est restituée pour chaque objet d AM, à condition que les coordonnées nationales de l objet d AM soient connues. Exemples d utilisation : attribution d ouvrages aux cantons, communes, etc. Tableau 3 : Fonctions du système de base destinées à supporter une application métier Le chap énumère d autres services que le système de base met à la disposition des applications métier. A titre de solution transitoire, le système de base met temporairement à disposition des fonctions de gestion de données généralistes et spécialistes de différents domaines spécifiques. Classes d objets concernées : voie, pose de la couche de roulement, locomotion douce, tronçons de rapport, coûts, ouvrages, projets. Après la réalisation complète de l AM, ces fonctions du système de base seront mises hors service. 32

39 6.1.8 Exigences de base que doivent remplir les applications métier Pour que les applications métier développées sur mandat de l OFROU puissent être reliées au système de base de façon optimale, elles doivent remplir les exigences suivantes : 1. La gestion des utilisateurs, groupes et droits s effectue via LDAP. Pour chaque AM, on définit dans le répertoire LDAP les groupes nécessaires avec les droits d accès à la base de données socle ainsi que les rôles avec les droits d exécution des services Web. 2. L AM doit disposer d une interface Interlis2 qui transfère des données dans les deux directions conformément au modèle de données du système de base. Le modèle de données est remis comme base à l AM dans le langage de description de données Interlis. 3. L identification d objet du système de base (UUID) doit être intégrée lors des échanges de données dans les deux directions. 4. L identification des objets de l AM ne doit jamais être modifiée Liaison d applications externes Il existe des données de base et généralistes qui ne sont gérées ni par le système de base ni par des applications métier MISTRA, mais par des applications sur la configuration (données et interfaces) desquelles l OFROU n a aucune influence. En font partie : données d applications métier non MISTRA (par exemple ViaPMS) ; données d outils de saisie (par exemple systèmes CAO, feuilles Excel, appareils mobiles) ; données sur les intervenants (adresses) et les documents (SIGD) ; données issues d applications financières (par exemple coûts de construction et d entretien) ; données issues de systèmes en temps réel (par exemple données mesurées) ; etc. Pour ce genre d applications externes, il convient de distinguer : les applications externes avec interface de programmation ou interface de données ouverte (p. ex. MS Outlook, MS Excel, divers outils de CAO) des applications externes sans interface (boîte noire) : on dépend alors de la disponibilité d un fichier de sortie, que l éditeur doit programmer suivant les cas. 33

40 La figure suivante montre comment le transfert de données est possible à partir de ce genre d applications : Application externe avec interface Application externe sans interface Connecteur Système de base Fichier de sortie Connecteur Système de base Figure 7 : Liaison d applications externes Les connecteurs suivants sont prévus dans le cadre du développement du système de base : 1. connecteur à Outlook pour se procurer des données sur les intervenants (adresses) ; 2. connecteur de documents pour référencer des documents externes dans le système de fichiers, dans un DMS ou sur Internet comme URL dans la classe d objets «document», ainsi que pour classer les documents créés dans MISTRA (plans, rapports, fichiers de transfert, etc.). L introduction d un système intégré de gestion des documents (SIGD) est prévue dans le cas concret de l OFROU (instance MISTRA de l OFROU). Le SIGD mettra à disposition un composant logiciel permettant de référencer et d ouvrir des fichiers dans le SIGD (dialogue Fichier). Les échanges de données avec les applications externes sont pour l instant prévus seulement hors ligne par le biais de fichiers de transfert. Les échanges de données avec les applications externes doivent être automatisables : Un répertoire d échange pour l importation et un autre pour l exportation doivent être installés pour chaque application externe. Les exportations doivent pouvoir être lancées automatiquement par le biais d un gestionnaire de tâches. Les importations doivent être automatisées par le biais d une interrogation des répertoires d importation. Les importations s effectuent toujours dans une zone temporaire d importation de la base de données socle (pour être validées). 34

41 Répartition des instances MISTRA, configurations types du système L architecture système ouverte de MISTRA autorise de nombreuses configurations possibles: une instance MISTRA centralisée unique 2 à plusieurs instances individuelles, pour chaque propriétaire (= administration routière). L architecture du système de MISTRA autorise toutes les variantes. Vu les structures fédérales existantes, il convient de supposer que l OFROU, les cantons et les agglomérations disposeront chacun d une instance autonome de MISTRA et qu il existera également suivant la taille plusieurs sous-instances, pour chaque propriétaire (par exemple district). Suivant la taille de l organisation du propriétaire, il faut s attendre à différentes configurations optimales. La figure ci-dessous montre quelques configurations types du système. Variante 2: standard Mandant 2 Serveur d applications MISTRA Client MISTRA Système périphériques KTV Variante 1: OFROU Variante 3: possibilité de desservir plusieurs clients Mandant 3' Mandant 3'' Systèmes périphériques OFROU KOMBV Système périphériques KTV Variante 4: entrée de gamme Variante 5: terminal KTV KTV Figure 8 : Variantes de configuration du système 3 2 Nous entendons par instance une installation de MISTRA autonome, d un propriétaire unique, qui a sa propre base de données socle. Chaque instance peut disposer de plusieurs bases de données socles, p. ex. une base de données principale centralisée et diverses bases de données de travail décentralisées. 3 L entrée de gamme n est pas couverte par une version spéciale allégée, mais par la mise à disposition de la version de base de MISTRA, y compris les licences du logiciel de base (ESRI), à de très bonnes conditions. 35

42 Les variantes 1 à 4 représentent chacune une instance individuelle de MISTRA. Chacune de ces instances fonctionne de manière entièrement autonome. Les liaisons par réseau RC figurées ne sont pas nécessaires pour l exploitation normale. Elles peuvent s utiliser pour l échange de fichiers hors ligne. Une liaison réseau est impérative pour la variante 5. Celle-ci est intéressante si on veut relier des succursales à une instance centralisée de MISTRA. Chacune des variantes doit en outre donner la possibilité de relier des clients mobiles. Des données peuvent être échangées entre diverses instances MISTRA. Chaque propriétaire (administration routière) peut exploiter une ou plusieurs bases de données MISTRA. Il est intéressant d avoir plusieurs bases de données quand : la gestion des données est décentralisée ; on exploite des instances séparées pour les tests et la modélisation ; les bases de données sont exploitées en externe, p. ex. dans des bureaux d ingénieurs. L unicité de la clé des objets MISTRA est garantie par un identificateur universel unique (UUID) selon ISO D autres UUID identifient le propriétaire ainsi que la base de données de MISTRA. La clé et d autres attributs qui régissent la maîtrise des données sont décrits dans le catalogue de données [3], sous «Clé MISTRA, maîtrise des données». Entre bases de données MISTRA, les données s échangent en mode hors ligne, en général par le biais d Interlis2. Scénarios d échange de données à couvrir : 1. échanger des données entre BD MISTRA, sans modification de la maîtrise des données, sans modification du propriétaire ; 2. échanger des données entre BD MISTRA, avec modification de la maîtrise des données, sans modification du propriétaire ; 3. échanger des données entre BD MISTRA, avec modification de la maîtrise des données et modification du propriétaire ; 4. importer de nouvelles données d une AM avec attribution de l identification MISTRA (MID), propriétaire, BDOrig et WriteGrp (cf. catalogue de données [3]) ; 5. importer mise à jour incrémentielle d une AM avec reconnaissance des attributs de clé ; 6. mettre des données à la disposition d une AM. 36

43 Les différentes variantes de la Figure 8 peuvent être décrites de la façon suivante : Variantes 1 et 2 Potentiel Architecture Conservation des données Nombre d applications Plate-forme intranet Plate-forme Internet Exploitant(e) Nombre d enregistrements dans la base de données socle Nombre de transferts de données Interlis2 Structure quantitative Nombre d utilisateurs appl. de base et métier Grandes organisations OFROU, 4 à 8 grands cantons, 1 à 2 grandes agglomérations 3 couches, couches données et application sur des serveurs séparés Répartie sur plusieurs BD MISTRA ou dans une BD centralisée 10 à 15 applications métier, 5 à 10 applications externes Propre plate-forme intranet MISTRA, exploitée de façon centralisée Propre plate-forme Internet, exploitée de façon centralisée Informatique interne ou centralisée (p. ex. OFIT pour l OFROU) à entités principales à entités dépendantes (p. ex. valeurs numériques) Env. 200 à 300 exportations et importations par instance et par an + env. 50 à 100 transferts par instance MISTRA décentralisée Temps de latence entre livraison et importation : 12 h au max. Rich GIS en lecture et écriture 3 à 6 postes de travail Nombre d accès par an à mutations Durée de fonctionnement* Disponibilité pendant la durée de fonctionnement* Tableau 4 : structure quantitative des grandes installations Web GIS en lecture et écriture Lecture : 80 à 120 Ecriture : 10 à accès aux enregistrements Web DWH en lecture Web Admin Rich Admin 80 à à à lancements de programme 500 à 1000 opérations % 99% 99% 98% Variante 3 Potentiel Architecture Conservation des données Nombre d applications Plate-forme intranet Plate-forme Internet Exploitant(e) Nombre d enregistrements dans la base de données socle Nombre de transferts de données Interlis2 Cantons et agglomérations 10 à 15 cantons petits à moyens, 6 à 10 agglomérations petites à moyennes 3 couches, couche données et application Oracle, ArcSDE, serveur ArcGIS, serveur MISTRA au choix sur serveurs séparés ou concentrées sur un serveur Une BD MISTRA centralisée et productive 2 à 10 applications métier, 1 à 5 applications externes Propre plate-forme intranet MISTRA, exploitée de façon centralisée Propre plate-forme Internet, exploitée de façon centralisée Informatique centralisée à entités principales à entités dépendantes (p. ex. valeurs numériques) Env. 20 à 200 exportations et importations par instance et par an Temps de latence entre livraison et importation : 12 h au max. 37

44 Structure quantitative Nombre d utilisateurs appl. de base et métier Rich GIS en lecture et écriture 1 à 4 postes de travail Nombre d accès par an 2000 à mutations Durée de fonctionnement* Disponibilité pendant la durée de fonctionnement* Web GIS en lecture et écriture Lecture : 10 à 80 Ecriture : 5 à accès aux enregistrements Tableau 5 : Structure quantitative des installations petites à moyennes Web DWH en lecture Web Admin Rich Admin 10 à 80 1 à à 8000 lancements de programme 100 à 600 opérations % 99% 99% 98% * La durée de fonctionnement peut être interrompue par 4 périodes de maintenance à un jour par an. Les indications quantitatives se réfèrent au déploiement complet. Les nombres d utilisateurs «SIG intranet» et «DWH intranet» indiquent le nombre des utilisateurs potentiels. L utilisation simultanée est de 20 à 30%. 38

45 Authentification et droits Points que la conception des accès à MISTRA doit garantir : 1. La gestion des utilisateurs et des groupes s effectue via LDAP. Seules peuvent être utilisées les fonctions standard LDAP sans extensions spécifiques à l éditeur. 2. Définition des droits d accès aux données par le biais de groupes d utilisateurs. 3. Droits d accès distingués selon catégories «accès refusé», «lecture» et «écriture». 4. Il doit être possible de différencier les droits d accès à l intérieur d une table en fonction des attributs (sélection de colonnes). 5. Il doit être possible de différencier les droits d accès à l intérieur d une table en fonction des lignes (sélection de lignes), non pas via LDAP, mais par le biais de l attribut maîtrise des données (v. [3]). 6. Définition des droits d exécution des «use cases» (fonctions) par le biais de rôles. 7. Si un utilisateur ou un groupe est attribué à un rôle, les droits d accès nécessaires pour exercer ces rôles doivent être définis automatiquement. 8. Les accès aux données (classes d objets ou tables) sont contrôlés dans la couche d accès aux données ou par le SGBD. 9. Les rôles et les use cases sont gérés par des applications dans MISTRA. MISTRA contrôle les droits d exécution des use cases. 10. Les applications métier accédant en ligne sont reliées au système de base par les mêmes mécanismes. Pour chaque AM, des groupes et rôles propres sont définis et enregistrés dans la base de données socle. C est aussi de cette façon que l AM est enregistrée et que ses droits d accès et d exécution sont définis. Lors de la mise en service d une nouvelle AM, les rôles et groupes correspondants doivent être définis. 39

46 Mode multiutilisateur, unités de traitement Dans MISTRA, le traitement des données s effectue dans des «unités de traitement». La condition pour entrer des données est d ouvrir une unité de traitement. Elle définit un sous-ensemble d une classe d objets et se fonde sur une sélection d objets (cf. chap ). Propriétés de l unité de traitement définies lors de son ouverture : 1. appartenance à la classe d objets (automatique) ; 2. extension géographique comme «bounding box» (automatiquement à partir de la sélection d objets) ; 3. attributs de base MISTRA (automatiques). L unité de traitement est fermée après la fin du traitement. Lors de la fermeture, l unité de traitement est marquée comme fermée et les propriétés suivantes sont déterminées et enregistrées dans les métadonnées : 1. description (manuelle) de l étendue de la mise à jour ; 2. remarques (manuelles) ; 3. indications sur la précision (automatiques à partir des objets individuels) ; 4. date de la dernière mise à jour (automatique à partir des objets individuels). Il importe de garantir : 1. qu un objet MISTRA ne puisse être ouvert que par une unité de traitement à la fois ; 2. qu un objet MISTRA ne puisse être traité sans qu une unité de traitement soit ouverte. 40

47 Interface de service Pour l accès à la base de données socle depuis les applications de base et métier, il y a lieu de développer dans MISTRA une interface de programmation servant d interface de service. Le client doit pouvoir appeler toutes les fonctions serveur de la couche intermédiaire en tant que service Web. Ces interfaces comprennent notamment les fonctions suivantes, importantes pour les applications métier : 1. appel d une identification MISTRA comme UUID pour de nouveaux objets d AM ; 2. services Web cartographiques pour transmettre des extraits de carte ; 3. Web Feature Service pour des requêtes sur des objets ; 4. obtention en ligne de données de base, métadonnées comprises, sélectivement par classes d objets ; 5. obtention en ligne de données généralistes, métadonnées comprises, sélectivement par classes d objets ; 6. dépôt en ligne de données de base, métadonnées comprises, dans la zone d importation, sélectivement par classes d objets ; 7. dépôt en ligne de données généralistes, métadonnées comprises, dans la zone d importation, sélectivement par classes d objets ; 8. transformation XY > UV ; 9. transformation UV > XY ; 10. transformation kilométrage > UV ; 11. transformation UV > kilométrage ; 12. déterminer appartenance d objets MISTRA à des surfaces ; 13. agrégation de données d objets MISTRA par surface ; 14. déterminer appartenance d objets MISTRA à des réseaux métier ; 15. agrégation de données d objets MISTRA par réseau métier ; 16. combinaison de réseaux métier. Le modèle des use cases [4] décrit ces services. Le protocole à utiliser pour implémenter l interface de service est le SOAP [14]. 41

48 Dans le cadre de la spécification détaillée, il y a lieu d examiner dans quelle mesure on prévoit d appliquer de nouveaux standards de services Web en plus des normes OGC. Standards en discussion : WS Adressing 4, pour manipuler des adresses Internet ; WS Security 5, pour l authentification et le cryptage de données ; WS Atomic Transaction 6, pour le traitement de transactions. Cette interface doit être classée par versions. Le système de base doit pouvoir supporter plusieurs versions de l interface à la fois (au moins deux). Le but est que les applications métier qui utiliseront cette interface ne soient pas contraintes à une migration lorsque le système de base sera étendu. 4 La spécification Web Services Addressing a été acceptée par le W3C comme «member submission» en août 2004 [20]. 5 La spécification Web Services Security existe en Version 1.0 comme norme OASIS (OASIS Standard , mars 2004, «Web Services Security : SOAP Message Security 1.0 (WS-Security 2004)». La version 1.1 existe en version "draft" [21]. 6 WS Atomic Transaction et les spécifications y relatives sont mises à disposition telles quelles par Microsoft, BEA et IBM et uniquement pour des rapports et analyses [22]. 42

49 Interface standardisée (Interlis2) Processus PA4 (service d exportation), PI1 (intégration de données de base), PI2 (intégration de données généralistes). Une interface destinée aux importations et exportations de données doit être réalisée pour la base de données socle. Cette interface se fonde sur les interfaces de service selon chapitre Elle est exécutée par les administrateurs de base de données des organisations utilisatrices Exigences générales : 1. L interface supporte aussi bien les échanges de données complets qu incrémentiels au standard Interlis2 (cf. [10]). 2. Les métadonnées doivent être transmises avec le même fichier de transfert. Elles sont décrites dans le catalogue de données [3]. 3. Il doit être possible de transférer des données d une instance MISTRA à une autre par cette interface même si les deux installations ne présentent pas le même niveau de mise à jour (versions de l interface à supporter : celle de la mise à jour principale actuelle et celle de la précédente). 4. Lors de leur transfert, les données doivent être pourvues de l UUID de l instance émettrice. Cet UUID permet de reconnaître l émetteur. L instance émettrice est enregistrée dans la table «Base de données» de la base de données socle. 5. Les échanges de données doivent pouvoir être lancés automatiquement par le biais du gestionnaire des tâches de Windows (scheduler). Ces tâches sont gérées dans la base de données socle. L obtention des fichiers d importation et l enregistrement des fichiers d exportation ont lieu à partir de, respectivement dans des répertoires prédéfinis. 6. Lors des processus d importation et d exportation, le statut (progression) est affiché à l écran (uniquement en cas d exécution interactive) et inscrit dans un fichier journal. Chaque processus ou erreur donne lieu à une inscription dans une table journal. 7. S il y a des données incorrectes, l importation doit toutefois être annulée si possible complètement Divergences par rapport au standard Interlis2 Divergences de MISTRA qui requièrent une attention particulière : 1. La structure de clé est différente (MISTRA utilise des UUID selon ISO 11578). 2. Interlis2 ne supporte pas de systèmes de repérage linéaires. Interlis2 ne peut traiter ces caractéristiques que comme des données spécialistes normales. Les transformations doivent être exécutées par des applications. 3. Interlis2 ne tient pas compte des modifications dans le repérage spatio-temporel. Les adaptations doivent être faites par des applications. 43

50 Déroulement d une importation L importation des données par l interface Interlis2 s effectue en principe par étapes : 1. données importées et : validées par l interface ; corrigées et complétées par l interface ; enregistrées dans une zone de validation de la base de données socle comme version d importation (classement par versions ArcSDE) avec interprétation des différences (données spécialistes modifiées, géométrie modifiée, enregistrement nouveau, supprimé) ; 2. validation graphique interactive par les utilisateurs avec la possibilité d accepter ou de rejeter les différences ; 3. reprise définitive des données (intégration) Validation lors de l importation L interface d importation exécute une validation des données, laquelle comprend : 1. contrôler le système de repérage ; 2. contrôler si les métadonnées sont disponibles et conformes aux règles ; 3. contrôler si les attributs et valeurs numériques obligatoires sont disponibles et conformes aux règles ; 4. contrôler la référence temporelle, p. ex. relations de clé étrangère avec des objets MISTRA qui ne sont plus utilisables parce que leur validité temporelle a pris fin ; 5. contrôler si la référence spatiale (SRB et/ou XY) est disponible et conforme aux règles (étendue) ; 6. contrôler si les autres attributs sont conformes aux règles ; 7. si les données sont pourvues d une clé MISTRA (UUID), contrôler sa validité (concordance). Les résultats de la validation sont inscrits dans un fichier journal Correction et complément lors de l importation Si la validation s est déroulée avec succès, l interface corrige et complète les données. Contenu de ce processus : 1. Transformation du modèle en modèle de données MISTRA 2. Si des données sont livrées dans un autre système de repérage (LV03, WGS84) que celui pour MISTRA (LV95 et LHN95), une transformation doit être réalisée lors de l importation. 3. Clés création des clés MISTRA manquantes remplacement éventuel de relations de clé étrangère 44

51 4. Référence temporelle Attributs temporels manquants complétés Adaptation de la granularité temporelle Lors de la mise à jour incrémentielle, l historique tant de l objet MISTRA lui-même que d objets dépendants (relations de clé étrangère) doit être mis à jour. Si le système fournisseur livre des géodonnées sans référence SRB, alors que la base de données socle les prévoit avec, la référence SRB est créée lors de l importation. 5. Référence spatiale Lors de l importation de données avec référence SRB, celle-ci doit être recalculée si la date SRB des données importées est plus ancienne que le SRB actuel de la base de données fondamentales. Compléter le classement double des coordonnées (linéaire ou planaire) sur la base de la géométrie de référence 6. Autres attributs Transformation d unités de mesure Transformation de références à des listes de choix et catalogues de textes Détermination d attributs calculés Déroulement d une exportation Etapes de l exportation des données par l interface Interlis2 : 1. définition des paramètres d exportation (ces données sont enregistrées dans la base de données socle) : destinataire comme intervenant ; type de l exportation (complète ou incrémentielle) ; paramètres de répétition ; sélection des données selon chap ; historique O/N ; date de référence ; répertoire pour dépôt de données ; date ; support pour envoi ; etc. 2. lancement du processus d exportation interactif ou par le biais d un gestionnaire des tâches (scheduler) ; 3. création des fichiers d exportation, description du modèle comprise ; 4. envoi des données. Lors de l exportation vers des applications métier ou externes qui ne gèrent pas d historique, il faut toujours livrer uniquement l état actuel. 45

52 Exportation Web GIS COSIG Les données socles doivent être transmises périodiquement à la base de données géographiques du COSIG. La fonction d exportation Interlis2 normale du système de base commande le transfert (appelé «ETC géodonnées» dans l architecture du système selon Figure 4) incrémentiel. Comme les modèles de données sont différents, il faut encore exécuter une transformation du modèle. La transformation du modèle comprend : 1. rétention de données non destinées au public ; 2. simplification et dénormalisation des données ; 3. résolution des références de catalogue et des listes de choix ; 4. changement des noms de table et d attribut. Le modèle de données de la base de données cible n est pas encore fixé. La fonction doit pouvoir être définie et exécutée comme traitement par lots (cf. module d importation et d exportation selon chap ) Importation de données d intervenant Pour l importation des données d intervenant, la version minimale à réaliser est un connecteur à Outlook. Celui-ci reprend des données de la base de données Exchange, éventuellement via un fichier intermédiaire.csv. Les données sont déposées dans la zone de validation de la base de données socle, puis validées et intégrées à l aide des fonctions de base du système de base. A moyen terme, il s agit de réaliser pour l OFROU une interface avec la gestion d adresses du SIGD. Cette interface n est pas encore suffisamment spécifiée et ne doit être offerte qu en option Importation de données dans des documents Pour l importation des données dans des documents, la version minimale à réaliser est une liaison avec le système de fichiers. Celle-ci reprend des liens pointant sur des fichiers du système de fichiers dans la base de données socle. A moyen terme, il s agit de réaliser pour l OFROU une interface avec la gestion des documents du SIGD. Cette interface n est pas encore suffisamment spécifiée et ne doit être offerte qu en option. 46

53 Importation de données de navigation Il est prévu d intégrer régulièrement des données de navigation dans la base de données socle. La navigation fournit des données sur la topologie, les réseaux métier et la géométrie. L interface de la base de données du fournisseur selon Interlis2 est réalisée par le fournisseur des données de navigation. L importation dans la BDS passe par l interface Interlis2, avec la description du modèle de la base de données fondamnetales (ce qui veut dire que l importation dans la BDS ne requiert pas de transformation du modèle) Importation de données d information routière Il s agit ici des événements relatifs au trafic de GEWI ou Viasuisse, tels que bouchon, accident, automobiliste à contresens, chantiers ainsi que codes de localisation TMC. L interface n est pas encore spécifiée à l heure actuelle Exportation de métadonnées COSIG Les métadonnées de MISTRA sont gérées selon la norme ISO L OFROU travaille avec le COSIG selon le modèle de partenariat B, ce qui signifie que les données sont gérées localement dans la base de données socle et transférées périodiquement à la base de métadonnées COSIG. Le système de base a besoin à cet effet d une interface d exportation. Exigences que doit remplir cette interface : 1. Le transfert s effectue selon Interlis2. 2. Les données doivent être livrées conformément à la description Interlis du modèle de métadonnées [12]. 3. La fonction doit pouvoir être définie et exécutée comme traitement par lots (cf. module d importation et d exportation selon chap ) Autres interfaces Interfaces de données à offrir en plus d Interlis2 : 1. exportation de données de tables sous forme de fichier Excel et.csv ; 2. exportation et importation de données géométriques au format DXF ; 3. exportation et importation de données géométriques ou spécialistes au format ESRI-Shape ; 4. importation d Interlis1 ; 5. exportation de rapports au format PDF. Le support de GML ne sera requis que dans une unité de réalisation ultérieure. 47

54 Outil de sélection L outil de sélection doit permettre de sélectionner des données de base et généralistes en fonction de critères d objet et/ou spatiaux. Elles servent de base pour : définition du périmètre d unités de traitement ; définition du périmètre d exportations de données et de processus ETC ; sélection d objets pour des fonctions de calcul et de transformation ; sélection d objets pour analyses ; définition des attributs en série ; etc. Exigences que doit remplir l outil de sélection : 1. Les sélections doivent pouvoir être enregistrées comme jeu de requêtes (et non comme ensemble sélectionné) et réutilisées dans l ordre défini. 2. L outil de sélection comprend tous les opérateurs supportés par ArcGIS et ArcMap. 3. L utilisateur doit pouvoir entrer les paramètres de sélection (valeurs des opérations de comparaison) pour le cas d application du moment. 4. Pour l utilisation interactive, il y a lieu d implémenter un formulaire permettant d énumérer et de paramétrer les requêtes appartenant à la sélection. 5. Des traitements par lots doivent aussi pouvoir exécuter les sélections Clients, interface utilisateur Le système de base s utilise par l intermédiaire des clients suivants : Rich GIS Web GIS Web DWH Rich Admin Web Admin Tableau 6 : Types de client Poste sous Windows ou terminal sur lequel les applications Windows nécessaires à MISTRA (ArcGIS, BusinessObjects, Office, etc.) peuvent être lancées avec leurs extensions MISTRA Navigateur sur lequel les applications Web MISTRA peuvent être lancées avec des fonctionnalités SIG Navigateur sur lequel des analyses ont lieu par le biais du DWH, peut être physiquement le même client que Web GIS. Poste sous Windows ou terminal sur lequel on peut exécuter des fonctions d administration complexes qui seraient inefficientes par le biais du Web Admin Client, peut être physiquement le même client que Rich GIS. Navigateur sur lequel on peut exécuter des fonctions d administration complexes, peut être physiquement le même client que Web GIS. La gestion des problèmes Web et des modifications se réalise aussi par le biais de ce type de client. Il importe de maintenir les clients riches aussi petits que possible. Ils accèdent à un «middleware» développé pour MISTRA dans la couche application. 48

55 La configuration des GUI doit être conforme à des directives standard. Les directives de conception et les exigences de détail sont à fixer dans le cadre de la conception du système. La figure suivante montre la disposition de l interface pour le client Rich GIS et Web GIS. Barre de titre Barre de menus Barres d icônes Légende Arborescence Carte Grille de propriétés Navigation Barre d état Figure 9 : Disposition de l écran des clients SIG La grille de propriétés est une implémentation spéciale du masque de données spécialistes où les données spécialistes d objets MISTRA sont affichées comme liste simple de façon analogue à l outil Internet d ArcMap. Comme étiquettes des attributs, il faut utiliser les alias multilingues. Les valeurs venant de catalogues de textes et de listes de choix doivent être représentées sous forme de texte dans la langue en cours. Indications complémentaires : voir chap Dans le Rich GIS, la légende, l arborescence et la grille de propriétés doivent être implémentées comme fenêtres arrimables. L utilisateur doit pouvoir quitter entièrement les différentes fenêtres. Dans le Web GIS, le déplacement entre ces fenêtres peut s effectuer par des onglets. 49

56 Cas d application (use cases) Définition : «Un use case représente une unité discrète d interaction entre un utilisateur (être humain ou machine) et le système. Il est exécuté en bloc ou pas du tout et retourne un résultat à l utilisateur. Exemples d use cases : AddOrder, DeleteOrder, ModifyOrder, ListTrains, ListLocations, etc.» (d après Geoffrey Sparks, 2000) La figure suivante montre la carte des processus [2] : Processus de gestion PG1: Pilotage SB et DWH PG2: Gestion catalogue et modèle de données PG3: Gestion des fonctions de MISTRA GP4: Gestion des droits d accès GP5: Limite entre système SB et AM GP6: Publication des données/métadon. GP7: Acquisition des données Processus de prestations PP1: Service carte PP2: Service axe tendu PP3: Service rapport PP4: Service d exportation de données PP5: Service surfaces et réseaux métier PP6: Service de transformation (xy-uv) PP7: Restauration des données BP8: Transformation Processus de traitement des données PD1: Requête de correct. de données PD2: Traitement d autres données de base PD3: Traitement objets routiers PD4: Traitement données PériRN PD5: Traitement donn. Généralistes (temp.) PD6: Traitement donn. spécialistes (temp.) PD7: Test de cohérence PD8: Statistique des données Processus d intégration PI1: Intégration donn. de base via interface standard PI2: Intégration donn. général. via interface standard PI3: Intégration donn. de navigation PI4: Intégration donn. GEWI/TIC PI5: Intégration données LKC PI6: Intégration modèles du trafic PI7: Intégration donn. swisstopo/cosig Processus d exploitation du système PS1: Planification informatique MISTRA PS2: Gestion des niveaux de service PS3: Sécurité informatique et protection des donn. PS4: Gestion des modifications PS5: Gestion des versions PS6: Relations avec les utilisateurs PS7: Service d assistance Figure 10 : Carte des processus du système de base (niveau macro) Les tableaux suivants montrent le classement des cas d application dans des processus ou groupes de processus. Le classement n est pas univoque. Un processus peut comprendre plusieurs cas d application : il existe p. ex. le processus «Traitement d autres données de base PD2», différencié, à partir des cas d application, selon les types de données «Référence spatiale», «Réseaux métier», etc. et selon la tâche de mutation «Saisir», «Modifier», «Supprimer». Un cas d application peut se rencontrer dans plusieurs processus, p. ex. «Charger légende», «Saisie de métadonnées», ou «Ouverture d une unité de traitement». Il y a aussi des processus qui sont exécutés sans le système de base et n ont donc pas besoin de cas d application, p. ex. «Définition de la limite du système PG5». Le document d accompagnement [4] documente les use cases du système de base. Le tableau suivant montre les use cases utilisés et les clients par le biais desquels ils sont utilisés. N o Use case PP Processus de prestations PP Exploration SIG Rich GIS PP Lancer SIG 1 I I PP Charger légende 1 I I PP Zoomer, panoramiquer 1 I I PP Navigation par fonction de recherche 1 I I PP Navigation par arborescence 1 I I PP Exécuter requêtes 1 I I PP Vue carte 4 I I Web GIS Rich Admin Web Admin Processus Priorité Système 50

57 N o Use case Rich GIS PP Vue formulaire 1 I I PP Vue table 1 I I PP1 Service carte PP1 Préparer, traiter, sortir carte 4 I I PP2 Service axe tendu PP2 Définir axe tendu 4 I PP2 Préparer, traiter, sortir plan d axe tendu 4 I PP3 Service rapport SIG PP3 Préparer, traiter, sortir rapport SIG ad hoc 4, 6 I Web GIS Rich Admin Web Admin PP3 Préparer, traiter, sortir rapport SIG prédéfini 4, 6 I I PP3 Libérer rapport 6 I PP4 Service d exportation de données PP4 Configurer exportation 3 I PP4 Exportation Interlis 3 I PP4 Exportation Excel 3 I O PP4 Exportation CSV 3 I O PP4 Exportation Shape 3 I PP4 Exportation DXF 3 I Service métadonnées PP4 Exporter métadonnées au COSIG 5 I PG6 Publier métadonnées 5 I PP7 Restauration de données PP7 Restaurer données 5 I O PP Sélections PP Créer, modifier, supprimer sélection 3 I O PP Exécuter sélection 3 I I I PP Interface de service pour AM PP1 Préparer service Web cartographique 5 I PP1 Préparer Web Feature Service 5 I PP4 Obtenir données de base à partir de la BDS 5 I PP4 Obtenir données généralistes à partir de la BDS 5 I PP Déposer données de base dans la BDS 5 I Processus Priorité Système 51

58 N o Use case Rich GIS Web GIS Rich Admin Web Admin PP Déposer données de base dans la BDS 5 I PP6 WS transformation UV XY 5 I PP6 WS transformation XY UV 5 I PP5 WS appartenance d objets MISTRA à des surfaces 5 I PP5 WS agrégation d objets MISTRA en surfaces 5 I PP5 WS appartenance d objets MI- STRA à des réseaux métier 5 I PP5 WS agrégation d objets MISTRA en réseaux métier 5 I PP5 WS combinaison de réseaux métier 5 I PP Service UUID 5 I PP6 WS transformation km > UV 5 I PP6 WS transformation UV > km 5 I DP Processus de traitement des données DP1 Requête de correction de données (requête mise à jour) DP1 Saisir, traiter, supprimer requête mise à jour 2 I DP1 Consulter requête mise à jour 2 I DP1 Créer rapport des requêtes mise à jour 2 I DP2 Traitement d autres données de base DP2 Saisir, modifier, supprimer surface 2 I S DP2 Saisir, modifier, supprimer valeur numérique de surface 2 I I DP2 Supprimer intervenant 2 I I DP2 Saisir, modifier, supprimer attribution intervenant à objet MISTRA 2 I I DP2 Saisir, modifier, supprimer document y compris lien dans système de fichiers 2 I I DP2 Saisir, supprimer attribution document à objet MISTRA 2 I I DP2 Saisir, modifier, supprimer remarque 2 I I Processus Priorité Système 52

59 N o Use case Rich GIS Web GIS Rich Admin Web Admin PP51 Appartenance d objets MISTRA à des surfaces 2 I PP51 Agrégation d objets MISTRA en surfaces 2 I DP2 Traitement données de base repérage spatial DP2 Saisir, modifier, supprimer axe 2 I S DP2 Saisir, modifier, supprimer point de repère 2 I S DP2 Saisir, modifier, supprimer géométrie 2 I DP2 Saisir, modifier, supprimer, caler point de calage 2 I DP2 Transformation UV XY 2 I DP2 Transformation XY UV 2 I DP2 Transformation km UV 2 I DP2 Transformation UV km 2 I DP2 Traitement données de base topologie DP2 Saisir, muter, supprimer lieux de nœud 2 I DP2 Saisir, modifier, supprimer nœuds 2 I S DP2 Traiter hiérarchie de nœuds 2 I DP2 Saisir, modifier, supprimer bord 2 I S DP2 Saisir, muter, supprimer obligation ou interdiction d obliquer 2 I S DP2 Générer, compléter réseau topologique 2 I DP2 Saisir, modifier, supprimer jonction 2 I S DP2 Créer, supprimer attribution de nœuds à une jonction 2 I DP2 Créer topologie à partir d objets 2 I DP2 Mettre à jour topologie après modifications 2 I DP2 Traitement données de base réseaux métier DP2 Saisir, modifier, supprimer réseau métier 2 I S DP2 Saisir, modifier, supprimer valeur numérique pour réseau métier 2 I S DP2 Saisir attribution de tronçons à un réseau 2 I Processus Priorité Système 53

60 N o Use case DP2 Supprimer attribution de tronçons à un réseau 2 I Rich GIS DP2 Saisir, modifier, supprimer tronçon de réseau 2 I S DP2 Saisir, modifier, supprimer valeur numérique pour tronçon de réseau 2 I S PP52 Appartenance d objets MISTRA à des réseaux métier 2 I PP52 Agrégation d objets MISTRA en réseaux métier 2 I PP52 Combinaison de réseaux métier 2 I PP52 Créer référence de nœud 2 I PP52 Créer référence de tronçon 2 I PP52 Recherche de l itinéraire optimal 2 I DP3 Traitement objets routiers DP3 Saisir, modifier, supprimer objet routier 2 I DP Traitement métadonnées DP Saisir, modifier, supprimer métadonnées 2 I DP4 Traitement données PériRN DP4 Saisir, modifier, supprimer projet 2 I S DP4 Créer, supprimer attribution d un projet à un objet routier 2 I I DP5 Traitement données généralistes (temporaire) DP5 Saisir, modifier, supprimer ouvrage 2 I S DP5 Saisir, modifier, supprimer valeur numérique pour ouvrage 2 I I DP5 Créer, supprimer attribution d un ouvrage à un objet routier 2 I I DP6 Traitement données spécialistes Tracés (temporaire) DP6 Saisir, modifier, supprimer voie 6 O DP6 Saisir, modifier, supprimer pose d une couche 6 O DP6 Saisir, modifier, supprimer état 6 O O DP6 Traitement données spécialistes Accidents de la circulation (temporaire) Web GIS Rich Admin Web Admin Processus Priorité Système 54

61 N o Use case Rich GIS DP6 Saisir, modifier, supprimer accident 6 O O DP6 Traitement données spécialistes Monitorage du trafic (temporaire) DP6 Saisir, modifier, supprimer poste de comptage 6 O O DP6 Saisir, modifier, supprimer trafic 6 O O DP6 Traitement données spécialistes Locomotion douce (temporaire) DP6 Saisir, modifier, supprimer chemin 6 O DP6 Saisir, modifier, supprimer itinéraire 6 O DP6 Saisir, modifier, supprimer signalisation 6 O DP6 Traitement données spécialistes IVS (temporaire) DP6 Saisir, modifier, supprimer objet IVS 6 O DP6 Saisir, modifier, supprimer objet linéaire 6 O DP6 Saisir, modifier, supprimer objet ponctuel 6 O DP6 Traitement données spécialistes Controlling des investissements (temporaire) DP6 Saisir, modifier, supprimer genre de coûts 6 O DP6 Saisir, modifier, supprimer coûts effectifs 6 O DP6 Traitement Tronçons de rapport, Entretien courant (temporaire) DP6 Saisir, modifier, supprimer tronçon de rapport 6 O DP6 Saisir, modifier, supprimer centre d entretien 6 O DP6 Saisir, modifier, supprimer valeur numérique d entretien 6 O DP6 Traitement données spécialistes Information routière (temporaire) DP6 Saisir, modifier, supprimer événement routier 6 O Web GIS Rich Admin Web Admin Processus Priorité Système 55

62 N o Use case DP6 Traitement données spécialistes Gestion de l entretien (temporaire) Rich GIS DP6 Saisir, modifier, supprimer tronçon d entretien 6 O DP6 Saisir, modifier, supprimer mesure optionnelle d entretien 6 O DP Unités de traitement, sessions d édition DP Ouvrir, fermer unité de traitement 1 I I DP Lancer, enregistrer, quitter session d édition 1 I O PI Processus d intégration PI7 Intégration géoservices de la Confédération PI7 Obtenir service Web cartographique 1 I I PI7 Supprimer service Web cartographique 1 I I PI1 Intégration intervenants Web GIS Rich Admin PI1 Importer intervenants nouveaux ou mis à jour (connecteur à Outlook) 3 I PI1 Valider intervenants importés 3 I I PI1 Intégrer intervenants validés 3 I I PI1-2 Intégration de données via une interface standardisée (Interlis) Web Admin PI1-2 Importer données (Interlis2) 3 I PI1-2 Valider données 3 I S PI1-2 Reprendre données 3 I S PI1-2 Importer données (Interlis1) 6 I PI Extraction, transformation, chargement ETC PI Créer, modifier configuration ETC SIG Internet 3 O I PI Exécuter ETC SIG Internet 3 I PG2 Gestion maîtrise des données PG2 Créer ID de propriétaire 1 O I PG2 Modifier, supprimer propriétaire 1 O I PG2 Importer propriétaire 5 O I PG2 Exporter propriétaire 5 O I PG2 Modifier propriété des données 5 O I Processus Priorité Système 56

63 N o Use case Rich GIS Web GIS Rich Admin PG2 Modifier maîtrise des données 5 O I PG4 Gestion utilisateurs et droits d accès PG4 Créer, modifier, supprimer utilisateur 1 O I PG4 Créer, modifier, supprimer groupe 1 O I PG4 Gérer droits d accès groupe 1 O I PG4 Créer, supprimer attribution utilisateur à groupe 1 O I PG4 Inscrire, modifier, supprimer rôle 1 O I PG4 Gérer droits d exécution rôle 1 O I PG4 Créer, supprimer attribution groupe à rôle 1 O I PG1 Poste de pilotage PG1 PS2 Créer rapport sur le système 5 O I PG1 DP8 Créer rapport sur les données 5 O I DP7 Vérifier et réparer DP7 Vérifier cohérence 5 O I DP7 Corriger incohérences 5 O I PS4 GC Edit Dictionary PS4 Saisir, modifier, supprimer types de surfaces 5 O I PS4 Importer types de surfaces 5 O I PS4 Exporter types de surfaces 5 O I PS4 Saisir, modifier, supprimer types de réseaux métier 5 O I PS4 Importer types de réseaux métier 5 O I PS4 Exporter types de réseaux métier 5 O I PS4 Saisir, modifier, supprimer types d ouvrage 5 O I PS4 Importer types d ouvrages 5 O I PS4 Exporter types d ouvrages 5 O I PS4 Saisir, modifier, supprimer catalogue 5 O I PS4 Saisir, modifier, supprimer entrée de catalogue 5 O I Web Admin Processus Priorité Système 57

64 N o Use case Rich GIS Web GIS Rich Admin PS4 Importer catalogue avec entrées 5 O I PS4 Exporter catalogue avec entrées 5 O I PS4 Saisir, modifier, supprimer types de valeurs numériques 5 O I PS4 Attribuer, supprimer types de valeurs numériques à types d ouvrages, de surfaces et de réseaux métier 5 O I PS4 Importer types de valeurs numériques 5 O I PS4 Exporter types de valeurs numériques 5 O I PS4 Saisir, supprimer unités 5 O I PS2 GC Gestion de base de données PS2 Générer ID de base de données 1 O I PS2 Saisir, modifier, supprimer base de données 1 O I PS2 Importer ID de base de données 5 O I PS2 Exporter ID de base de données 5 O I PS4 Gestion des modifications PS4 Saisir, modifier, supprimer requête de modification 5 I I PS4 Consulter requêtes de modification 5 I I PS4 Créer rapport des requêtes de modification 5 I I PS7 Service d assistance PS7 Saisir, modifier, supprimer problème soumis 5 I I PS7 Consulter problèmes soumis 5 I I Web Admin PS7 Créer rapport des problèmes soumis 5 I I I = impératif, O = optionnel, S = uniquement données spécialistes PG = processus de gestion ; PP = processus de prestations ; PD = processus de traitement des données ; PI = processus d intégration ; PS = processus d exploitation du système Tableau 7 : Use cases et attribution aux clients Processus Priorité Système La colonne Priorité se réfère aux itérations pendant la réalisation. La colonne Système contient les use cases exécutés par lots en arrière-plan. 58

65 Application de base SIG La GUI de SIG dépend du produit fini utilisé, ArcGIS d ESRI, et doit y être intégrée complètement. Cette interface doit permettre de gérer toutes les données de base. Il s agit de développer à cet effet les fonctions et masques de données spécialistes adéquats. La fonctionnalité de base offerte par le SIG doit en outre être disponible sans restriction pour les utilisateurs. L utilisation de fonctions de base ne doit toutefois pas compromettre l intégrité de la base de données socle. L application de base SIG supporte en premier lieu les processus de traitement de données selon [2], mais aussi les processus d entreprise et d intégration. Les fonctionnalités de la GUI de SIG se répartissent entre le client Rich GIS et Web GIS. Le Tableau 7 de la section renseigne sur la répartition. Pour les éléments non associés à un use case, la liste suivante complète les indications (R+W = riche + Web). Eléments importants de la GUI de SIG : 1. Authentification (automatique via LDAP) 2. Création automatique de légendes sur la base du catalogue de données [3] (R+W) Cette fonction doit permettre, à partir d une sélection de thèmes, de charger la légende désirée avec les réglages de niveaux désirés. Ces réglages des légendes sont enregistrés comme fichiers de configuration (p. ex..mxd) dans le système de fichiers. L utilisateur doit avoir la possibilité de définir de nouvelles légendes et de les rendre accessibles au chargeur de légendes. La disposition définie par défaut des fenêtres, des menus et des barres de symboles doit aussi être rétablie lors du chargement d une légende. 3. Menus et barres de symboles complémentaires pour lancer les fonctions spéciales MISTRA (R+W) 4. Gestion des fonds en pixels pour les différents ouvrages cartographiques (R+W) L OFROU achètera l ouvrage cartographique en pixels (cartes pixel, VECTOR25/200, photos aériennes, etc.) comme service Web cartographique aux géoservices de la Confédération. 5. Auxiliaire de navigation (R+W) pour recherche, positionnement, zoom, panoramique rapide par : a. canton, route, tronçon d entretien ; b. route, kilomètre de/à ; c. canton, centre d entretien, tronçon de rapport ; d. canton, nom de l objet routier (recherche en plein texte) ; e. feuille CN ; f. commune. Lorsqu une première clé de recherche (p. ex. canton) est sélectionnée, le choix de la prochaine clé de recherche (p. ex. route) est automatiquement limité aux éléments disponibles. Il n est pas impératif de remplir complètement les clés de recherche vers l arrière. Si on veut zoomer seulement sur un canton, il suffit d entrer le canton dans la première sélection, puis d entrer la commande de zoom. 59

66 6. Arborescence avec différentes hiérarchies (R+W) : a. canton, route nationale, tronçon d entretien, objet routier ; b. canton, centre d entretien, tronçon de rapport ; c. axe, point de repère ; d. type de réseau métier, réseau métier (hiérarchique), tronçon ; e. projet, objet routier ; f. route nationale, jonction. Il doit être possible de lancer différentes fonctions à partir de l arborescence : a. zoom sur le sous-arbre ou l objet MISTRA sélectionné ; b. sélection d éléments dans l arborescence (sous-arbres ou objets MISTRA) ; c. ajout à ou retranchement de l ensemble sélectionné ; d. affichage des données spécialistes sur l objet MISTRA choisi. L extrait de carte et la constitution de l image dans la fenêtre carte ne change pas implicitement quand on clique dans l arbre, mais seulement explicitement quand on clique sur l icône ad hoc de la barre de fonctions de l arborescence (pour minimiser le rafraîchissement d image). 7. Fonctions d édition (R+W) a. Ouverture et fermeture d une unité de traitement b. Lancement, fermeture, enregistrement, rejet de sessions d édition Toutes les modifications sont exécutées à l intérieur de sessions d édition. Les sessions d édition doivent être quittées à l intérieur d une séance. Les sessions d édition permettent aux utilisateurs d annuler des modifications faites par inadvertance. c. Création de nouveaux objets MISTRA Préréglage automatique du niveau, des paramètres de capture, des niveaux sélectionnables, etc. Détermination automatique des références spatiales quand c est nécessaire (p. ex. appartenance à un canton, coordonnées nationales et SRB, attribution à des tronçons d entretien, etc.). En cas d'ambiguïté, l utilisateur doit pouvoir intervenir de façon corrective. Données du repérage spatial complétées automatiquement par des coordonnées planaires et, si c est prévu, linéaires. Lors de la création d objets géographiques, on commence toujours par établir le jeu de données techniques, puis on saisit la géométrie correspondante. La saisie de la géométrie peut aussi s effectuer plus tard. L objet MISTRA reste accessible par le biais de l arborescence et de la table des attributs. d. Modification des objets MISTRA (R+W) Modification de la géométrie avec fonctions standard du SIG Modification des données spécialistes par le biais de la grille de propriétés MISTRA Création automatique de l historique quand c est nécessaire (cf. catalogue de données [3]) Il doit aussi être possible de modifier plusieurs objets MISTRA sélectionnés à la fois (définition des attributs en série). 60

67 e. Supprimer des objets MISTRA (notamment avec la touche Delete) (R+W) Permettre la suppression notamment avec la touche Delete Egalement applicable sur des sélections multiples Avertissement avant suppression (malgré session d édition) Création automatique de l historique 8. Masques de données spécialistes comme grille de propriétés (cf. aussi pour classes d objets MISTRA) (R+W), avec : a. affichage par la grille de propriétés des attributs de l objet MISTRA choisi ; b. textes des masques en fonction de la langue sélectionnée (titres, étiquettes, listes de choix, messages) ; c. obtention automatique d attributs d autres classes d objets par le biais de clés étrangères, p. ex. indication sur l axe dans le masque points de repère ; d. préréglage dynamique de valeurs par défaut judicieuses pour les nouveaux objets MISTRA ; e. contrôles combinés pour listes de choix (remplies à partir de catalogues de textes) avec sélection par le biais de dénominations (ce sont les codes qui sont stockés, mais l utilisateur ne voit que les dénominations) ; f. contrôles de plausibilité lors de l entrée ; g. onglet spécial ou formulaire pour entrer les intervenants, documents, remarques et valeurs numériques (ces dernières pour les surfaces, ouvrages, réseaux métier) ; h. onglet spécial ou formulaire pour afficher le métaenregistrement correspondant ; 9. Gestion de métadonnées (R+W) : a. formulaires pour créer un nouveau métaenregistrement au niveau de l instance, du thème ou de la classe d objets (hiérarchie de métadonnées) ; b. saisie de données concernant des unités de traitement ; c. formulaires de gestion des métadonnées (modifier, supprimer). 10. Recalcul des références spatiales (R+W) Les objets MISTRA contiennent des références spatiales de toute nature et les enregistrent en général sous forme de clés étrangères. Exemples de références spatiales : coordonnées SRB, coordonnées linéaires, code de localisation TMC, attribution à un tronçon d entretien, appartenance cantonale ou communale, etc. Là où c est nécessaire, les clés étrangères s inscrivent automatiquement lors de la saisie de l objet. Les données de base peuvent toutefois changer sans que les objets MISTRA subissent eux-mêmes des modifications de position. C est pour cette raison qu il doit être possible de recalculer ces références spatiales. En cas de non-unicité, l utilisateur doit pouvoir intervenir de façon corrective. Ce recalcul doit répondre aux exigences suivantes : a. Tout recalcul doit s effectuer à l intérieur d une session d édition. b. Il doit être possible de sélectionner le type de données de base de la référence spatiale à recalculer, p. ex. SRB, appartenance cantonale. c. Il doit être possible d appliquer le recalcul, au choix, à un objet individuel, à un ensemble sélectionné d objets MISTRA d une classe (v. chap ) ou à tous les objets d une classe. 61

68 11. Autres fonctions (R+W) a. Conversion de la référence spatiale du système de repérage planaire au linéaire et viceversa sur la base de la géométrie de référence (fonction de base). Le document [7] donne des indications importantes pour la conversion. Les données relevées, selon champ Mode de détermination dans le catalogue de données sous référence spatiale, ne doivent toutefois pas être écrasées par un processus automatique. 12. Aide à l utilisateur : a. fichier d aide sensible au contexte (R+W) ; b. fonction d aide directe (R+W) ; c. textes d infobulle pour toutes les icônes et tous les champs de masque (R) ; d. informer l utilisateur des actions attendues dans la ligne d état (R) ; e. afficher systématiquement un sablier lors d activités du système (R+W) ; f. invites, messages d erreur, informations d état, etc. en fonction de la langue (R+W). 13. Créer carte (R+W) a. Masque de sélection pour modèle de carte, flèche indiquant le nord, échelle, légende, titre, numéro de plan, grille de coordonnées, données de base et spécialisées à représenter, options d inscription b. Positionnement interactif du tronçon souhaité sur la vue carte, y compris rotation c. Modèles pour différents formats de carte d. Des orientations non septentrionales (inclinées) doivent être possibles. e. Sélection de l imprimante ou du plotter f. Il doit être facile d agrandir ou de réduire les modèles de carte par pas A4. g. Les cartes doivent indiquer la précision et la date de la dernière mise à jour pour chaque niveau conformément aux indications des métadonnées. h. La conception du système doit spécifier la mise en page utilisée et la symbologie. 15. Requêtes, rapports et cartes thématiques du Web GIS (W) Requêtes à prédéfinir : L utilisateur doit pouvoir indiquer les paramètres de sélection. a. Liste d objets routiers par RN, canton, tronçon d entretien comme table b. Liste d ouvrages par RN, canton, tronçon d entretien avec valeurs numériques sélectionnables à partir d une table comme table c. Liste de tronçons de réseaux métier par RN, canton avec valeurs numériques sélectionnables à partir d une table comme table d. Etat de la chaussée par RN, canton, tronçon d entretien à une date au choix avec sélection du paramètre d état dans une table de valeurs numériques comme table et carte thématique 62

69 e. Variation de l état des chaussées par RN, canton, tronçon d entretien sur une période au choix avec sélection du paramètre d état dans une table de valeurs numériques comme table et carte thématique f. Etat des ouvrages d art par RN, canton, tronçon d entretien à une date au choix avec sélection du paramètre d état dans une table de valeurs numériques comme table et carte thématique g. Variation de l état des ouvrages d art par RN, canton, tronçon d entretien sur une période au choix avec sélection du paramètre d état dans une table de valeurs numériques comme table et carte thématique h. Trafic par poste de comptage par RN à une date au choix avec sélection du paramètre de trafic dans une table de valeurs numériques comme table et carte thématique i. Variation du trafic par poste de comptage par RN sur un intervalle au choix avec sélection du paramètre de trafic dans une table de valeurs numériques comme table et carte thématique j. Trafic par tronçon de trafic par RN à une date au choix avec sélection du paramètre de trafic dans une table de valeurs numériques comme table et carte thématique k. Variation du trafic par tronçon de trafic par RN sur une période au choix avec sélection du paramètre de trafic dans une table de valeurs numériques comme table et carte thématique l. Fréquence des accidents par tronçon d accidents par RN sur une année civile au choix avec sélection du paramètre de trafic dans une table de valeurs numériques comme table et carte thématique m. Variation de la fréquence d accidents par tronçon d accidents par RN entre 2 années civiles avec sélection du paramètre de trafic dans une table de valeurs numériques comme table et carte thématique n. Fréquence des bouchons par tronçon de bouchons et par RN sur une année civile au choix avec sélection du paramètre de bouchon dans une table de valeurs numériques comme table et carte thématique o. Variation de la fréquence des bouchons par tronçon de bouchons et par RN entre 2 années civiles avec sélection du paramètre de bouchons dans une table de valeurs numériques comme table et carte thématique 63

70 Application d administration L application d administration doit être réalisée en majeure partie comme application Web. Certains use cases, à forte composante spatiale, peuvent être implémentés dans le client riche. L application comprend : 1. gestion des utilisateurs, groupes et droits d accès ; 2. gestion des rôles et droits d exécution ; 3. gestion multilingue des catalogues de textes et de valeurs numériques ; 4. importations et exportations (Interlis2) automatisables comme traitement par lots via un gestionnaire ; 5. interface de publication de géodonnées ETC pour l application Web Internet (Interlis2) ; 6. processus ETC dans le DWH intranet et Internet ; 7. fonctions de vérification de la cohérence des données et fonctions de réparation ; 8. visualisation et analyse de l historique, le cas échéant fonctions de suppression pour les données désormais inutiles ; 9. saisie, visualisation et analyse des entrées de journal. Divers processus doivent procéder à des inscriptions dans le journal : ouverture et fermeture de sessions en écriture (connexions et déconnexions de l utilisateur), importations et exportations de données, publications sur le Web, modifications et extensions des structures de données de la base de données socle. Les entrées de journal sont en grande partie saisies automatiquement. Le document [4] décrit les use cases. 64

71 Application axe tendu L'axe tendu permet de représenter des données routières sous la forme de profils longitudinaux et transversaux. Ce mode de représentation est important surtout pour les professionnels de la route. Le guide STRADA [9], au chapitre 2, présente brièvement le principe de l axe tendu. L application axe tendu en tant que application Web autonome doit communiquer directement avec la base de données socle. Les sources de données et les graphes doivent être paramétrables. L application axe tendu se compose de deux parties : 1. Définition de l axe tendu : partie où l on peut définir les différents axes tendus. Cette partie s adresse à des utilisateurs expérimentés, p. ex. au gestionnaire de données. Définition de la source de données (classe d objets, réseau métier), p. ex. indice I1 de l état des routes du réseau métier avec indices agrégés Largeur de l axe en mm et attribution du domaine de valeurs à représenter, p. ex. 20 mm pour la représentation linéaire d indices entre 0 et 5 Mode de représentation (point, ligne avec ou sans pointes de flèche, histogramme à graduation latérale), p. ex. représentation comme surface (histogramme) avec bordure noire Symbologie de la représentation (symboles, styles de ligne, remplissage de surface), p. ex. remplissage de toute la surface Inscription fixe et variable du nom de l axe tendu à partir d un attribut, p. ex. partie fixe «Etat couche de roulement :», partie variable «date de mesure» Inscriptions fixes de côté (graduation) et sur l axe avec indication de position, p. ex. graduation des indices de 0 à 5, à gauche et à droite Inscription de valeurs d attribut (variables) sur l axe avec indication de position, p. ex. indice numérique en bas Couleurs des symboles (contour et remplissage), lignes, surfaces (contour et remplissage) fixes ou en fonction de valeurs d attribut, p. ex. couleur variable en fonction de l indice selon échelle de couleurs xxx Désignation de la définition d axe tendu, p. ex. «Indice I1 agrégé 20 mm» 2. Définition du plan : partie où l on peut créer des représentations d axe tendu et qui utilise les définitions d axe tendu de la première partie. L utilisateur doit avoir les possibilités d entrée suivantes : Taille du plan (longueur hauteur en mm), p. ex mm Echelle dans le sens de la longueur, p. ex Position du plan, p. ex. en bas à gauche 65

72 Titre du plan, p. ex. «Evolution de l état de la couche de roulement de l A1 de 2000 à 2004» Organisation, créateur, date, échelle, p. ex. «Office fédéral des routes OFROU», «M. Martin», 30 avril 2005 (par défaut : date du jour), 1: (automatique) Sélection de l axe à représenter et de la position sur cet axe (numéro d axe, km au début), p. ex. «A1», point de départ au km 25.0 Sélection des axes tendus à représenter avec indication de la période à représenter p. ex. «Indice I1 agrégé 20 mm», période «2000», «Indice I1 agrégé 20 mm», période «2002», «Indice I1 agrégé 20 mm», période «2004» Autres exigences : 1. Comme premier axe, on représente toujours l axe déroulé avec les points de repère. 2. Les différentes définitions d axe tendu et les définitions de plan doivent pouvoir être enregistrées dans la base de données ou comme fichiers XML. 66

73 Plurilinguisme Exigences concrètes en matière de plurilinguisme : 1. Déclinaison en autant de langues que l on veut 2. La première unité de réalisation doit implémenter une version complète en français, allemand et italien. 3. La variabilité linguistique se rapporte à tous les textes, notamment des légendes, menus, icônes, titres et étiquettes dans les formulaires, infobulles, catalogues et listes de choix, aide en ligne, messages du programme (erreurs, état, etc.). 4. La langue des valeurs d attribut entrées librement par l utilisateur, telles que noms, remarques, etc. n est pas variable. 5. Les exigences linguistiques de la documentation sont décrites sous Le catalogue de données [3] décrit l organisation des structures de données pour les catalogues de données et listes de choix multilingues. 7. Le choix de la langue est fixé dans la configuration du système de Windows. L utilisateur n a pas besoin d intervenir pendant le traitement. 8. Le changement de langue des produits finis et des modules développés pour MISTRA peut s effectuer indépendamment Sécurité Exigences en matière de sécurité : Confidentialité Intégrité La base de données socle MISTRA ne contient pas de données qui requièrent des mesures particulières en matière de protection des données. La base de données socle est exploitée exclusivement sur l intranet (réseau fédéral KOMBV). Il y a lieu d empêcher les accès depuis la ZDM ou l extérieur (Internet). L accès à la base de données doit être protégé par nom d utilisateur et mot de passe. L intégrité des données doit être garantie à terme par des mesures appropriées : 1. en premier lieu par l utilisation de l intégrité référentielle dans les structures de données ; 2. par des applications qui vérifient les conditions de cohérence ; 3. par des applications qui recalculent immédiatement les redondances repérées après des mutations, p. ex. conservation double des coordonnées linéaires et planaires, attributs dérivés. 67

74 L intégrité des données doit pouvoir être vérifiée par des fonctions de contrôle, journalisée et, en cas d erreur, restaurée sans perte de données par des fonctions de réparation (v. use cases Administration sous ). Lors de pertes de données, la base de données du dernier jour ouvrable clôturé doit pouvoir être restauré. Disponibilité Contrôle des accès Authentification Justificatif d activité La disponibilité requise des différents composants du système est décrite au chap L accès à toutes les données doit pouvoir être réglementé clairement. Les exigences sont décrites aux chap et Les exigences en matière d authentification sont décrites au chap La date de modification et le nom d utilisateur de la personne qui a exécuté la mutation doivent être enregistrés pour chaque modification des données. Les données de base référencées par d autres données de base ou spécialisées doivent être historisées. Les traitements par lots ou processus d arrière plan doivent par principe inscrire les résultats et erreurs dans des fichiers journaux. Planification des cas d urgence En cas d urgence, la base de données du dernier jour ouvrable complet doit pouvoir être restaurée. La restauration doit être possible en moins de 4 heures. 68

75 Documentation Lors de la phase de réalisation et d introduction, les documents selon Hermes [1] sont nécessaires, en particulier : 1. conception du système en allemand et français (non en version mixte) avec : architecture du système (fonctionnelle, logique, physique) ; plan d intégration du système ; modèle logique de données avec descriptions des tables et attributs ; descriptions d applications et cas d utilisation des applications ; projet de mise en forme de la GUI ; interface de service, services Web : description du fonctionnement et de l interface ; interfaces importation, exportation, migration ; gestion des utilisateurs, droits d accès, sécurité ; autres compléments nécessaires pour une documentation complète du système, soussystèmes compris ; index ; 2. manuel d exploitation en allemand, français, italien (option) avec : structure technique du système ; conditions ; installation, configuration ; mise en service, interruption, mise hors service ; description de tous les cas d application du point de vue de l administration, copies d écran comprises ; mesures de surveillance requises ; indications pour optimiser l exploitation du système ; erreurs système possibles avec numéro d erreur, description, mesures ; gestion des groupes, rôles, utilisateurs, droits d accès et d exécution ; sauvegarde, restauration des données ; autres compléments nécessaires pour l exploitation correcte ; index ; 3. manuel de support en allemand, français, italien (option) avec : description structure du système, composants, interfaces ; objectifs et fonctions principales des applications ; erreurs d application possibles avec numéro d erreur, description, mesures ; autres compléments nécessaires pour un support correct ; index ; 4. manuel de l utilisateur pour chaque application (SIG, axe tendu, Admin) en allemand, français, italien (option) avec : description structure du système et applications avec fonctions principales ; description de tous les cas d application du point de vue de l utilisateur, copies d écran comprises ; cas d erreur possibles avec numéro d erreur, description, mesures ; 69

76 explications techniques : structures de données et algorithmes ; index ; 5. guide de référence rapide pour chaque application en allemand, français, italien, anglais avec une brève description pour les utilisateurs et utilisatrices sur quatre pages A4 au maximum par application ; 6. vue d ensemble du produit MISTRA en allemand, français, italien, anglais ; 7. documents de formation pour chaque type de cours avec exemples d exercices en allemand et français ; 8. aide en ligne pour chaque application et plate-forme en allemand et français, sensible au contexte. Les documentations (sauf aide en ligne) seront remises sous forme de fichiers Word et PDF Exigences de performance, délais de réponse Les exigences de performance suivantes se réfèrent à un environnement système soumis à des conditions de charge faibles à normales. Leur satisfaction doit être démontrée dans l environnement de l éditeur pour autant qu il corresponde en grande partie à celui de l OFROU en termes de technologie et de performance. 1. Exploitation multiutilisateur (ne concerne pas les systèmes monopostes d entrée de gamme) : accès en lecture par un nombre quelconque d utilisateurs ; accès de plusieurs utilisateurs en écriture à des objets d une classe d objets. 2. Disponibilité : voir section ; sauvegarde des données en cours d exploitation (sauf pour les systèmes monopostes). 3. Délais de réponse application Rich GIS et Rich Admin : lancement de l application, authentification comprise : < 60 secondes ; fermeture de l application : < 30 secondes ; affichage après zoom avant ou panoramique : < 3 secondes ; affichage après zoom arrière : < 5 secondes ; absence de rafraîchissements d écran inutiles ; lancement création d un nouvel objet MISTRA : < 1 seconde ; première ouverture d un masque de données spécialistes : < 3 secondes ; ouverture répétée d un masque de données spécialistes : < 1 seconde ; premier enregistrement d une mutation : < 3 secondes ; enregistrement répété d une mutation : < 1 seconde. 4. Délais de réponse Web GIS : lancement de l application, authentification comprise : < 20 secondes ; affichage après zoom ou panoramique : < 5 secondes ; absence de rafraîchissements d écran inutiles ; première ouverture d un masque de données spécialistes : < 3 secondes ; 70

77 ouverture répétée d un masque de données spécialistes : < 1 seconde ; premier enregistrement d une modification : < 3 secondes ; enregistrement répété d une modifcation : < 1 seconde. 5. Délais de réponse applications d administration Rich Admin et Web Admin : lancement de l application, authentification comprise : < 10 secondes ; lancement création d un nouvel objet MISTRA : < 1 seconde ; première ouverture d un masque de données spécialistes : < 3 secondes ; ouverture répétée d un masque de données spécialistes : < 1 seconde ; premier enregistrement d une modifcation : < 3 secondes ; enregistrement répété d une modifcation : < 1 seconde. 6.2 Système de base : exigences introduction OFROU Concept d introduction Dans le cadre de l introduction, un concept d introduction selon Hermes [1] doit être établi pour l OFROU, avec : 1. description de l organisation et des procédures d introduction ; 2. mise en service du système de base MISTRA : catalogues de textes ; types d ouvrages, types de surfaces et de réseaux métier et leurs valeurs numériques ; propriétaires, bases de données, applications métier ; 3. modalités d intégration de l ancien système dans le nouveau : exploitation en parallèle ; intégration de l inventaire d ouvrages et des ouvrages d UH-PERI ; intégration des axes, points de repère, géométries, réseaux (topologiques et géographiques), jokers, trafics de STRADA ; mise hors service de l ancien système ; 4. processus mise à disposition de données de base : fond de carte pixel (PK25, PK100, PK200, PK500, PK1000, photos aériennes, etc.) ; mise en place de réseaux surfaciques ; mise en place de réseaux métier (tronçons de vitesse, catégories de routes, etc.) ; 5. ressources nécessaires ; 6. information ; 7. concept de formation (v ). 71

78 6.2.2 Réception du système La réception du système s effectue en plusieurs phases (cf. échéancier 9.1.2) : 1. réceptions partielles après chaque itération ; 2. réception globale du logiciel ; 3. réception du système productif OFROU. Les réceptions s effectuent sur les systèmes de l OFROU. Des représentants de l OFROU sont présents lors de toutes les réceptions. Les réceptions se réfèrent au fonctionnement des composants logiciels et à l exploitation du système. La documentation est contrôlée dans le cadre de révisions séparées. L organisation et le contenu précis de la réception seront décrits dans le plan de test selon chap Installation Un script d installation séparé sera créé pour chacune des applications et chacun des produits finis utilisés. Ces scripts doivent englober toutes les étapes d installation. L installation manuelle de fichiers et les adaptations manuelles de fichiers de configuration ne sont pas autorisées. Le manuel d exploitation doit décrire intégralement la procédure d installation. Etendue des travaux d installation : 1. installations de test à l OFROU pour chaque des 6 itérations (2 clients) ; 2. installation pour réception du logiciel global à l OFROU (serveur + 2 clients) ; 3. installation de l environnement de production de l OFROU (serveur de BD, serveur ArcSDE, modules serveur système de base, 2 Rich GIS Clients) Formation Dans le cadre de l introduction, un concept de formation selon Hermes [1] doit être élaboré, avec : 1. description de l organisation de la formation ; 2. description des exigences envers la formation ; 3. description de l offre de formation (description des cours, objectifs pédagogiques, public cible) ; 4. ressources nécessaires ; 5. analyses. 72

79 Offre de formation en allemand et français : 1. introduction à ArcGIS Desktop pour MISTRA (2 jours) ; 2. opérateurs système de base (2 jours) ; 3. requêtes et utilisation via Web GIS (3 heures) ; 4. administrateurs système de base (3 jours). 6.3 Système de base : Exigences d exploitation Gestion de la configuration Pendant la phase d exploitation, la gestion de la configuration doit être mise à jour avec chaque version du logiciel Maintenance Gestion des modifications Les fiches de modification sont saisies systématiquement comme FM et gérées jusqu à la finalisation. Les FM sont discutées 1 fois par mois avec les représentants de l OFROU (centrale de gestion MISTRA) et leur traitement ultérieur fait l objet d une décision. Pour traiter la gestion des modifications, il faut mettre à disposition une plate-forme Web à laquelle ont accès toutes les personnes chargées de la maintenance (organisation de maintenance, responsables MISTRA, «super users»). Exigences que doit remplir cette plate-forme Web : 1. exploitation par Internet ; 2. authentification par nom d utilisateur et mot de passe spécifiques à l utilisateur ; 3. masque de saisie des fiches de modification FM avec : ID, titre, personne signalant le problème, module concerné, description, erreur ou CR, urgence, délai souhaité, etc. ; 4. masque pour la suite du traitement des FM : état de traitement, solution proposée, travail et coûts estimés, date résolution du problème, commentaires, documents liés, version pour libération, etc. ; 5. possibilité de joindre des annexes aux FM ; 6. droits d accès aux champs différenciés en fonction du rôle ; 7. établissement d états GM : état vue d ensemble et état détails GM Option maintenance du logiciel de base Pour la maintenance du logiciel de base (Oracle, ESRI, etc.), un contrat de licence sera conclu entre l OFROU et les cantons et les éditeurs (à offrir comme option). 73

80 Maintenance des modules développés Pour la maintenance des composants développés pour MISTRA, un contrat de maintenance est conclu pour une durée de 5 ans. Contenu de ce contrat : 1. Maintenance de base (en dehors de la procédure de GM) : mise à disposition de personnel qualifié ; mise à disposition de l environnement de développement ; gestion et entretien du code du programme et classement par versions ; mesures de prévention des conflits avec le matériel et les systèmes d exploitation ; adaptations mineures aux nouvelles versions des systèmes d exploitation, des bases de données et du logiciel de base SIG ; corrections d erreurs et adaptations de programme mineures ; adaptations mineures de la documentation. La maintenance de base est indemnisée sous la forme d un forfait annuel payable par mois. 2. Maintenance principale : celle-ci est budgétisée et traitée dans le cadre de la gestion des modifications. Sa facturation est mensuelle, aux coûts déterminés dans la procédure de GM Mise à jour de la documentation La documentation selon chap doit être adaptée constamment à l évolution du produit. Les frais sont indemnisés par le biais de la maintenance Gestion des versions Les versions doivent être planifiées de façon à ce que les nouveautés importantes paraissent dans des versions majeures env. tous les 1 à 2 ans, tandis que des versions intermédiaires sont distribuées env. tous les 6 à 12 mois. Pour corriger les erreurs, le site Web MISTRA doit mettre des correctifs à disposition. La gestion des modifications sert d entrée à la planification des versions. Dans ce processus, les modifications et extensions du système de base en suspens sont coordonnées et un échéancier est établi pour que les différentes FM soient prises en considération. Le classement par versions du logiciel est une condition importante pour leur gestion. Il y a donc lieu d utiliser des auxiliaires pour la gestion des versions et celle du code source. La possibilité de supporter et d entretenir les deux dernières versions majeures de MISTRA doit être garantie. 74

81 6.3.4 Support (Gestion des problèmes) Mise à disposition d un service d assistance téléphonique Exigences que doit remplir le support téléphonique : 1. bilingue allemand et français ; 2. accessibilité lundi à vendredi de 8 h 00 à 18 h 00 ; 3. après entrée de la demande, le demandeur reçoit par courriel une confirmation de l annonce du problème de la part du service d assistance ; 4. délai de réaction de 4 heures au maximum ; pendant ce temps, une personne compétente s attelle à la résolution du problème ; 5. délai de résolution de problèmes simples et moyens par un support de deuxième niveau : 2 jours ouvrages au maximum Option : Support de premier niveau Le support de premier niveau reçoit les demandes directement des utilisateurs MISTRA. Ce support est normalement couvert en interne par des super users et des administrateurs chez le mandant et ne fait pas partie des prestations du mandataire Support de deuxième niveau Si le support de premier niveau ne peut pas résoudre le problème, il le transmet au support de deuxième niveau. Les demandes sont adressées exclusivement par les personnes responsables du support de premier niveau (super users). Le support de deuxième niveau fait toujours partie des prestations du mandataire Support de troisième niveau Les demandes adressées au support de troisième niveau passent en principe par le support de deuxième niveau du mandataire. Le support de troisième niveau comprend le soutien plus large fourni par les éditeurs des logiciels de base. 75

82 7 Intégration des données Le document [6] contient une description approfondie de l intégration des données. Les travaux d intégration à exécuter dans le cadre de la réalisation du système de base se limitent à l instance MISTRA de l OFROU. 7.1 Intégration des données de base Interface STRADA L interface STRADA sert au transfert unique des données d une base de données STRADA à une base de données MISTRA. Des mises à jour incrémentielles ne sont pas prévues. Mais il se peut que chaque thème (repérage spatial, topologie, réseaux métier, chaussée, PMS, trafic, etc.) soit transféré à un moment distinct. L'intégration des données STRADA se déroulera par étapes selon le planning avec chaque canton concerné et le concept établi. L interface doit supporter la version 3.02 de STRADA. Le modèle de données STRADA remis avec les données de test est déterminant. STRADA dispose d une interface d exportation au format Interlis1. Toutes les données de la BD STRADA sont importées dans la base de données MISTRA par le biais de l interface Interlis selon chap La reprise des données implique de créer, dans le cadre de la réalisation, le modèle de données dans le langage de description d Interlis1. Etant donné les différences structurelles des modèles de données STRADA et MISTRA, une transformation de modèle doit avoir lieu pour le transfert de données. L outil logiciel nécessaire à cet effet fait également partie des prestations de la réalisation. Modèle STRADA.ili Modèle MISTRA.ili STRADA-DB STRADA Export Fichier de transfert Transformation de modèle Fichier de transfert MISTRA Import MISTRA-DB Figure 11 : Transformation de modèle de STRADA à MISTRA Comme STRADA contient aussi des fonctions et des données d applications métier (p. ex. PMS, trafic), les données spécialistes correspondantes doivent pouvoir être enregistrées et gérées temporairement, c est-à-dire jusqu à ce qu elles soient reprises par une application métier remplaçante, dans la base de données socle lors de la mise en service du système de base. Le système de base doit par conséquent mettre à disposition des tables de données adéquates. 76

83 L interface doit être conçue pour les données suivantes venant de STRADA : Thème Référence spatiale Points de repère Axes Géométrie, calage Géométrie Points de calage Segments horizontaux Eléments horizontaux Réseaux métier Lieux de nœud Nœuds Jonctions, carrefours Bords Topo-réseaux Réseaux géographiques Secteurs Catalogues de textes Catalogues Textes de catalogues Listes de choix Propriétaires Projets Chaussée Profils transversaux Voie, usage Trafic Jokers Tableau 8 : Interface STRADA Table STRTB_REFERENCE_PS STRTB_AXES GEOMETRIES HOR_CAL_POINTS HOR_SEGMENTS HOR_ELEMENTS STRTB_NODE_LOCS STRTB_NODES STRTB_JUNCTIONS STRTB_LINKS STRTB_LINK_GROUPS STRTB_GEO_NETS, STRVE_GNE_REPV STRTB_GEO_SEGMENTS STRTB_CATALOGS, STRTB_CAT_TITLES, STRTB_CAT_COLUMNS, STRTB_COL_TITLES STRTB_CAT_TEXTKEYS, STRTB_CAT_TEXTS, STRTB_ELEM_TXTKEYS, STRTB_ELEM_TEXTS, STRTB_COMPRULES STRTB_CODES, STRTB_CODETYPES STRTB_OWNERS, STRTB_DATAOWNERS, STRTB_OWNER_NAMES Pour les propriétaires, des UUID doivent être générés et utilisés pour les relations de clé étrangère correspondantes. STRTB_PROJECTS STRTB_CROSS_SECTS, STRTB_CR_S_USAGES STRTB_LAT_LANES Diverses tables Diverses tables Attribution à des réseaux métier Les données relatives aux intervenants, documents, accidents et chantiers n ont pas besoin d être reprises de STRADA. 77

84 7.1.2 Interface UH-PERI UH-PERI est un ensemble de données unique à reprendre. Il s agit d une base de données Access. La manière de reprendre les données est libre. Des mises à jour incrémentielles ne sont pas prévues. Il importe de faire attention aux différences structurelles des modèles de données UH-PERI et MISTRA (cf. [6]). L application actuelle UH-PERI SIG sera entièrement remplacée par l application de base SIG (traitement des objets routiers) et par des fonctions temporaires respectivement des applications métier (mise à jour ouvrages). Les use cases correspondants sont définis Reprise des données La reprise des données pour l OFROU englobe les données suivantes : 1. liaison du serveur WMS swisstopo avec cartes (PKxx), VEKTOR25 et photos aériennes ; 2. intégration de l inventaire d ouvrages d UH-PERI ; 3. intégration des données STRADA à partir de l instance STRADA de l OFROU Préparation des données Données à préparer pour la première mise en service de MISTRA à l OFROU : 1. constitution des catalogues de textes ; 2. constitution des catalogues de valeurs numériques ; 3. traitement ultérieur des données d objets routiers et d ouvrages ; 4. préparation de réseaux métier des routes nationales : réseau des numéros de routes nationales comme réseau de tronçons ; catégories de routes comme réseau de tronçons ; catégories de routes TERN comme réseau de tronçons ; tronçons d entretien comme réseau de tronçons (importation depuis STRADA) ; tronçons d exploitation comme réseau de tronçons (importation depuis STRADA) ; réseau d appartenance cantonale comme réseau de tronçons ; codes de localisation TMC comme réseau de tronçons ; 5. préparation de réseaux surfaciques : cantons ; districts ; communes. Les use cases du système de base (chapitre , use cases 20600) contiennent ceux du traitement des réseaux métier. 78

85 7.2 Intégration d autres données de base Intégration des données de navigation Importation des données de navigation de Navteq ou TeleAtlas. Les données sont livrées au format Interlis2. Le logiciel d interface pour l exportation depuis la base de données de navigation est développé par le fournisseur. Les données sont utilisées comme entrée pour : topologie (nœuds, bords, obligations ou interdictions d obliquer) ; géométrie (comme alternative à celle de swisstopo) ; réseau métier vitesse signalisée ; réseau métier nombre de voies ; réseau métier restrictions applicables aux poids lourds (hauteur, largeur, charge). Les données sont importées, validées et reprises par le biais de l interface standardisée pour le système de base (chapitre , use cases 30300) dans la zone de validation Intégration des données d information routière Importation des données d information routière de GEWI ou ViaSuisse. Les données sont livrées au format Interlis2. Les données sont utilisées comme entrée pour des événements relatifs au trafic (bouchon, automobiliste à contresens, accidents, chantiers, etc.) et attribuées aux codes de localisation. Ces derniers sont préparés comme réseau métier (voir 7.1.4). Les données sont importées dans la zone de validation, validées et reprises par le biais de l interface standardisée pour le système de base (chapitre , use cases 30300). 7.3 Intégration des données généralistes Interface tracés Le chapitre et le document [6] décrivent l importation des données généralistes sur la chaussée depuis STRADA (voies, profils transversaux, trafic, jokers) Intégration des ouvrages d art avec valeurs numériques Les ouvrages d art des routes nationales sont intégrés complètement en reprenant les données venant d UH-PERI selon La mise à jour, la reprise d ouvrages d art des routes cantonales et l intégration de valeurs numériques (p. ex. portée des ponts) ne s effectueront que lorsque l interface Interlis2 sera réalisée du côté de KUBA (KUBA 4.1, env. mi-2007) Intégration des données relatives aux accidents Pour l intégration des données sur les accidents, il existe aujourd hui deux ensembles de données, à savoir la base de données OFS des accidents de 1994 à 2004 et les bases de données décentralisées des polices cantonales. Le premier doit être intégré par le mandataire de la réali- 79

86 sation du système de base, le second après l achèvement de l interface standard par le biais de l AM Accidents de la circulation, dès La base de données OFS est structurée en fonction du procès-verbal d accident. La localisation géographique n est faite qu en partie et de façon très hétérogène. La procédure exacte doit être discutée dans le cadre de la spécification détaillée. Les accidents de la circulation sont relevés sur l ensemble du réseau de transport et doivent être repris intégralement dans la base de données socle. La police effectue la saisie dans les bases de données d accidents cantonales. 17 cantons utilisent le logiciel de PTV Swiss, les autres utilisent d autres logiciels (voir [26]). L application métier Accidents de la circulation AM AC est développée parallèlement à la réalisation du système de base MISTRA. L AM AC reprend les données aujourd hui hétérogènes dans la base de données des accidents centralisée de l OFROU. De là, les données généralistes sont transmises à la base de données socle au format Interlis Intégration des données du trafic Une partie des données du trafic est reprise une fois pour toutes avec l intégration des données de STRADA (v ) et fait partie des prestations du mandataire de la réalisation du système de base. L intégration ultérieure régulière s effectue par le biais de l application métier Monitorage du trafic AM MT, développée parallèlement à la réalisation du système de base. Les données des postes de comptage sont reprises par l AM MT dans la base de données centralisée du trafic de l OFROU. Depuis là, les données généralistes sont transmises à la base de données socle au format Interlis Intégration de la locomotion douce Les données concernant la locomotion douce sont préparées et mises à disposition par swisstopo. Pour le moment, elles comprennent les thèmes : chemins, itinéraires pédestres, signalisation ; routes, itinéraires cyclistes, signalisation ; pistes, itinéraires de VTT, signalisation. Les données sont mises à disposition au choix sous forme de fichiers Shape ou au format Interlis1. Le mandataire de la réalisation du système de base doit les transférer une fois pour toutes dans la base de données socle. La mise à jour s effectue par le biais de l interface standard MISTRA. 80

87 7.3.6 Intégration des données des voies de communication historiques Les données des voies de communication historiques sont gérées sur mandat de l OFROU dans une base de données personnelle ESRI auprès de Basler & Hofmann. Le mandataire de la réalisation du système de base reprend les données dans la base de données socle MISTRA sans transformation de modèle. Les données comprennent les classes de fonctions suivantes : objets IVS ; objets linéaires ; objets ponctuels ; matériel iconographique et documents Intégration de la comptabilité d exploitation Les données de la comptabilité d exploitation (entretien courant) sont aujourd hui gérées dans la base de données de benchmarking. Elles comprennent actuellement les chiffres d exploitation du service hivernal, du nettoyage, de l entretien des espaces verts, des services techniques et de l éclairage. Les valeurs numériques se réfèrent à des tronçons d exploitation. La saisie du réseau métier tronçons d exploitation est couverte par le chap Les chiffres d exploitation sont mis à disposition de la base de données socle à partir de la base de données de benchmarking par le biais de l interface Interlis2. 81

88 8 Exigences envers le système de Data Warehouse 8.1 Data Warehouse : exigences de réalisation Introduction Le texte qui suit décrit les exigences pour le sous-système Data Warehouse de MISTRA. Elément complémentaire du système de base MISTRA, le Data Warehouse est donc soumis par principe à ses directives et exigences. Dans le cadre de la solution de Data Warehouse prévue, il convient de distinguer deux composants fondamentaux : 1. Data Warehouse interne Le Data Warehouse interne est prévu pour être utilisé par des utilisateurs ou clients internes. L accès s effectue dans ce cas par des clients Web intranet ou par un logiciel client installé. C est le Data Warehouse interne qui fait l objet du présent cahier des charges. 2. Data Warehouse externe Le Data Warehouse externe est prévu pour l accès public (public access). L accès s effectue dans ce cas par des clients Web Internet. Les données et fonctions contenues (analyses et états) ne correspondent qu à un sous-ensemble du Data Warehouse interne. Le Data Warehouse externe ne fait pas partie du présent cahier des charges. 82

89 8.1.2 Architecture Systèmes périphériques, interfaces Dans le cadre de la première phase de développement, la base de données socle du système de base MISTRA représente l unique source de données pour le Data Warehouse. Des données spécialisées et d autres sources de données ne sont prévues que pour des phases de développement subséquentes. La reprise de données doit pouvoir être automatisée. La mise en œuvre doit faire appel à un outil ETC courant (p. ex. Ascentant ou Informatica). Un «write-back» de données du Data Warehouse au système de base MISTRA n est pas prévu. Une instance externe du Data Warehouse est prévue pour l accès public par Internet. Elle se base entièrement sur des données intégrées de l instance interne ou de l Operational Data Store interne. Comme l instance externe se distingue toutefois de l instance interne par la quantité des données et la granularité, un composant ETC est également nécessaire pour le transfert des données. Le schéma suivant montre les systèmes voisins du Data Warehouse. Il représente le Data Warehouse de façon simplifiée. Le chapitre suivant fournit une description détaillée. OFROU / Confédération / Cantons Public Internet Client tier Rich-GIS, -Admin Web-GIS, -DWH, -Admin Web-GIS, -DWH Client métier Client-SIG Data tier Application tier Appl. Serveur AS Data-Access Données métiers GIS-Serveur (Service-Interface) Data Access Layer Données géographiques Map-Server Métadonnées et données métiers Web-Serveur ETL ETL BI-Serveur Data Marts ETL ODS ETL DWH Firewall Geo Service Conf. GIS-Serveur Data-Access Données GEO Web-Serveur Map-Serveur BI-Serveur Data Marts ETL données GEO DWH interne DWH externe Environnement de production Intranet (KOMBV) DMZ Conf. Infrastructure internet Figure 12 : Insertion du DWH dans l architecture logique du système 83

90 Architecture du Data Warehouse La solution de Data Warehouse à implémenter ne devrait pas être limitée aux données et processus MISTRA, mais offrir la possibilité d intégrer dans le futur d autres domaines au niveau de l OFROU (p. ex. MOFIS, FABER, ISA, GT-CH, etc.), du département ou de l administration fédérale. Il est donc essentiel d utiliser une architecture de Data Warehouse ouverte et extensible à volonté. Pour atteindre cet objectif, il faudrait utiliser l architecture de référence représentée ciaprès, qui a fait ses preuves pour des projets de Data Warehouse au niveau international et interdisciplinaire. Source de données Présentation Figure 13 : Architecture interne du DWH Sources de données Les systèmes sources livrent les données brutes pour le Data Warehouse. En principe, n importe quel système interne ou externe à l office peut être utilisé comme source de données. Le Data Warehouse sert de plate-forme d intégration et a pour but d homogénéiser des données hétérogènes et incohérentes et ainsi de les rendre comparables ou connectables. Les données nécessaires au Data Warehouse peuvent être lues directement, suivant la plateforme du système source et la stratégie choisie, ou mises à disposition par des processus d extraction via des fichiers non structurés. 84

91 Processus ETC La gestion du Data Warehouse est garantie par des processus ETC. Le texte qui suit décrit les fonctions et caractéristiques principales des processus ETC. Fonctions : extraction de données à partir de différents systèmes sources ; nettoyage des données (identification des données manquantes, inexactes et incorrectes) ; traduction et attribution (p. ex. affectation de codes uniformes 0/1 pour masculin/féminin) ; intégration des données ; agrégation et résumé (p. ex. tri et sommation des enregistrements pour former des résumés de catégories de données) ; calcul et dérivation (p. ex. dérivation de nouveaux types ou valeurs sur la base d algorithmes, de méthodes quantitatives ou de mesures). Caractéristiques : implémentation du chargement complet ou d une stratégie de mise à jour ; implémentation de chargements initiaux et périodiques ; processus automatisable et répétable qui peut être planifié par le biais d un gestionnaire de tâches ; possibilité de suivi et annonce automatique de l avancement du processus aux super users responsables. Les processus ETC sont utilisés tant pour la gestion de l ODS que des Data Marts. Aux deux niveaux, la situation en matière d extraction et de chargement est analogue puisque des données sont en principe lues dans une source et écrites dans un système cible. En matière de transformation, les deux niveaux ETC se distinguent toutefois notablement l un de l autre en raison des propriétés fondamentalement différentes des systèmes source et cible. La gestion de l ODS consiste en premier lieu à intégrer des données hétérogènes à partir des différents systèmes sources et donc en fonctions telles que nettoyage des données, traduction et attribution. Comme il n est pas possible de corriger toutes les erreurs de données à la machine, une gestion des erreurs bien conçue est également essentielle. Pour gérer les Data Marts, on utilise en revanche avec l ODS une source de données qui dispose déjà de données intégrées, cohérentes et sans erreurs. A ce niveau d ETC, il s agit donc non pas d intégrer ou de nettoyer, mais de transférer les données d une structure relationnelle à une structure multidimensionnelle. Les données de l ODS granulaires sont transformées par des fonctions telles que l agrégation, le calcul et la dérivation en les sommes et valeurs numériques voulues pour les Data Marts. 85

92 Operational Data Store L ODS est le coeur de l architecture du Data Warehouse. Il contient des données granulaires intégrées qui ont été générées par les processus ETC en amont. Les contenus de l ODS peuvent être utilisés directement comme base de données pour des applications analytiques comme p. ex. le «data mining» ou aussi pour le reporting opérationnel et le «drill through» détaillé (outil OLAP). L ODS constitue la source de données pour la population des Data Marts encore davantage agrégés et segmentés et peut aussi s utiliser comme «staging area». Les données enregistrées dans l ODS sont par définition neutres au plan fonctionnel et interinstitutionnel et sont représentées par un modèle de données relationnel normalisé Data Marts Les Data Marts (appelés aussi Dimensional Data Stores) représentent la base d applications analytiques telles qu OLAP et sont aussi optimisés techniquement pour cette fonction. Ils contiennent des niveaux sommaires précalculés ainsi que des vues segmentées prédéfinies des données de l ODS et supportent ainsi des fonctionnalités «drill» et «slice». La performance des accès aux données très lourds pour le système est améliorée par des index et un partitionnement hautement optimisés. Les données enregistrées dans des Data Marts sont par définition agrégées et orientées sujet et fonction et sont représentées par le biais d un modèle de données multidimensionnel dénormalisé. Suivant la solution, on peut utiliser comme plate-forme système aussi bien une base de données relationnelle que multidimensionnelle Présentation Le terme «Présentation» englobe en principe l ensemble des applications et outils utilisés pour la sortie des données du Data Warehouse et qui représentent donc le point de contact des utilisateurs avec le système. Il s agit pour l essentiel d applications de reporting, d OLAP (On-Line Analytical Processing) et de «data mining», que l on désigne souvent aussi sous le nom d outils de «Business Intelligence». Ces applications sont implémentées presque exclusivement par le biais de logiciels standard Métadonnées Les métadonnées décrivent la définition, l utilisation, la gestion et la structure des objets du Data Warehouse. Chaque composant de l architecture du Data Warehouse peut aussi bien produire lui-même des métadonnées qu accéder aux métadonnées d autres composants de l architecture. Les métadonnées opérationnelles se rapportent aux informations sur les structures de sources de données et de modèles cibles. Ces métadonnées contiennent des spécifications pour la transformation, l extraction, le nettoyage (cleansing), l intégration et la synchronisation de données utilisées pour la gestion du Data Warehouse. 86

93 Les métadonnées orientées utilisateur se rapportent en revanche aux règles opératoires et aux utilisations prévues des données appliquées dans des outils Business de Intelligence ou des applications de présentation Processus d implémentation itératif Le schéma suivant explicite comment l architecture décrite garantit un processus d implémentation itératif ou la modularité de la solution. Les données des domaines spécifiques caractérisés par des couleurs différentes sont intégrées successivement dans le Data Warehouse et constituent ensuite une base de données globale qui permet aussi une utilisation interthématique au niveau de l analyse et du reporting. Figure 14 : Processus itératif d implémentation du DWH La phase 1 fait l objet de la première unité de réalisation. 87

du 9 décembre 2013 vom 9. Dezember 2013 ALLGEMEINE BESTIMMUNGEN

du 9 décembre 2013 vom 9. Dezember 2013 ALLGEMEINE BESTIMMUNGEN Recueil systématique..8 Règlement cadre Rahmenreglement du 9 décembre 0 vom 9. Dezember 0 sur l assurance qualité à l Université de Fribourg über die Qualitätssicherung an der Universität Freiburg Le Sénat

Plus en détail

Schnittstelle A V2.4 für SOMED V2.4.1 Anhang für kantonale Daten. Interface A V2.4 pour SOMED V2.4.1 Annexe pour données cantonales

Schnittstelle A V2.4 für SOMED V2.4.1 Anhang für kantonale Daten. Interface A V2.4 pour SOMED V2.4.1 Annexe pour données cantonales Schnittstelle A V2.4 für SOMED V2.4.1 Anhang für kantonale Daten Interface A V2.4 pour SOMED V2.4.1 Annexe pour données cantonales V2.4 / 28.09.2015 A 1 / 7 Inhaltsverzeichnis / Table des matières Grundlegender

Plus en détail

Réserve Personnelle. Persönliche Reserve. Emprunter et épargner en fonction de vos besoins. Leihen und sparen je nach Bedarf

Réserve Personnelle. Persönliche Reserve. Emprunter et épargner en fonction de vos besoins. Leihen und sparen je nach Bedarf crédit épargne Réserve Personnelle Emprunter et épargner en fonction de vos besoins Persönliche Reserve Leihen und sparen je nach Bedarf Réserve Personnelle Vous voulez disposer à tout moment des moyens

Plus en détail

Swiss Map Mobile. Landeskarten neu im preiswerten Abo Cartes Nationales nouveau en abonnement avantageux. wissen wohin savoir où.

Swiss Map Mobile. Landeskarten neu im preiswerten Abo Cartes Nationales nouveau en abonnement avantageux. wissen wohin savoir où. Swiss Map Mobile Landeskarten neu im preiswerten Abo Cartes Nationales nouveau en abonnement avantageux wissen wohin savoir où swisstopo Schweizerische Eidgenossenschaft Confédération suisse Confederazione

Plus en détail

VSS Online Shop. Kurze Gebrauchsanweisung

VSS Online Shop. Kurze Gebrauchsanweisung VSS Online Shop Kurze Gebrauchsanweisung Inhaltsverzeichnis 1. Die VSS Startseite... 3 1.1 Die Kundenanmeldung... 4 2. Das Benutzerkonto... 5 2.1 Allgemeine Einstellungen... 5 2.2 Adressbuch... 6 2.3 Einstellungen...

Plus en détail

Modèle de formation aux compétences informationnelles. Document d accompagnement

Modèle de formation aux compétences informationnelles. Document d accompagnement Modèle de formation aux compétences informationnelles Document d accompagnement Sommaire 1 Zusammenfassung... 1 2 Introduction... 2 3 Méthodologie... 3 4 Utilisation du référentiel... 4 5 Répartition des

Plus en détail

L archivage numérique aux Archives fédérales Vers des solutions

L archivage numérique aux Archives fédérales Vers des solutions L archivage numérique aux Archives fédérales Vers des solutions Colloque à swisstopo sur le thème "Geodaten für die Ewigkeit" Dr. Krystyna W. Ohnesorge / Jérémie Leuthold Berne, le 6 mars 2009 En guise

Plus en détail

NewCity. Box Storage Container & Caddy

NewCity. Box Storage Container & Caddy NewCity NewCity NewCity überzeugt auf der ganzen Linie. Eine klare Organisation, ein optimales Preis-Leistungs- Verhältnis und viel Spielraum für Individualität zeichnen dieses Konzept aus. Bringen Sie

Plus en détail

MISTRA - Système d information pour la gestion des routes et du trafic

MISTRA - Système d information pour la gestion des routes et du trafic Bundesamt für Strassen ASTRA MISTRA - Système d information pour la gestion des routes et du trafic Geo-forum Ouchy 2 novembre 2005, Lausanne Christoph Käser, CP adj. MISTRA Office fédéral des routes,

Plus en détail

Assemblée des délégués du PEV. Delegiertenversammlung der EVP. Neuchâtel - 5 avril 2008. Nello Castelli Membre de la direction de santésuisse

Assemblée des délégués du PEV. Delegiertenversammlung der EVP. Neuchâtel - 5 avril 2008. Nello Castelli Membre de la direction de santésuisse Assemblée des délégués du PEV Delegiertenversammlung der EVP Neuchâtel - 5 avril 2008 Nello Castelli Membre de la direction de santésuisse Projekt: Article constitutionnel sur la santé Datum: 05.04.2008

Plus en détail

Fachgruppe BiG Positionspapier Nr 5

Fachgruppe BiG Positionspapier Nr 5 Fachgruppe BiG Positionspapier Nr 5 Stammdaten Übergangslösung für Produkte die kein GS1 GTIN zugeordnet haben Hintergrund Die Fachgruppe Beschaffung im Gesundheitswesen (BiG) setzt sich aus namhaften

Plus en détail

Medienmitteilung zur Konferenz Opendata.ch 2015 am 1. Juli an der Universität Bern

Medienmitteilung zur Konferenz Opendata.ch 2015 am 1. Juli an der Universität Bern Opendata.ch info@opendata.ch 8000 Zürich 7. Juni 2015 Medienmitteilung zur Konferenz Opendata.ch 2015 am 1. Juli an der Universität Bern Communiqué de presse à propos de la conférence Opendata.ch/2015

Plus en détail

Belinda Richle, Zürich

Belinda Richle, Zürich Chère Madame Märkli, J ai vraiment aimé apprendre à calculer grâce à vous. C était tellement bien que j aurais aimé rester un peu plus longtemps avec vous. Hannah Belinda Richle, Zürich Laura Richle, 3.

Plus en détail

Principes et outils de communication II

Principes et outils de communication II Page 1 / 5 Titre Principes et outils de communication II Filière Domaine Année de validité Information documentaire Service et communication 2015-2016 N o Obligatoire Semestre de référence 733-1n S3 Prérequis

Plus en détail

SB2T. Allgemeines. Généralités. Gestaltung. Configuration SB2T

SB2T. Allgemeines. Généralités. Gestaltung. Configuration SB2T Allgemeines SB2T Mit dem Gimatic Multi Sensor Prüfgerät können Analoge und Digitale Sensoren auf deren Funktion geprüft werden. Zudem bietet der integrierte Cronometer die Möglichkeiten, Verfahrzeiten

Plus en détail

Base de données du radon en Suisse

Base de données du radon en Suisse Base de données du radon en Suisse 1 Stratégie du programme radon Locaux d habitation et de séjour Secteurs de travail Valeurs légales: Bâtiments existants: 1000 Bq/m 3 (valeur limite) Bâtiments neufs

Plus en détail

Zusätzliche Krankenversicherung. Mutuelle d entreprise : les obligations de l employeur. Neue Verpflichtungen für den Arbeitgeber

Zusätzliche Krankenversicherung. Mutuelle d entreprise : les obligations de l employeur. Neue Verpflichtungen für den Arbeitgeber Zusätzliche Krankenversicherung Neue Verpflichtungen für den Arbeitgeber (Veröffentlichung der Abteilung für rechtliche und administrative Informationen der französischen Regierung vom 15.09.2015) Ab 1.

Plus en détail

FOD JD PROMO AFBJ/FV BJ Übungen und Spielen / exercices et jeux 2013

FOD JD PROMO AFBJ/FV BJ Übungen und Spielen / exercices et jeux 2013 FOD JD PROMO AFBJ/FV BJ Übungen und Spielen / exercices et jeux 2013 Echauffement TE et déplacements (TA) courses et rythmes Aufwärmung (TE) Läufe und Tempo (TA) 1 Analytisch - 20 Minuten 2 Mannschaften

Plus en détail

Faire une révision rapide des moyens de transport utilisables pour se rendre dans un pays étranger. a) Documents Fahrkarten

Faire une révision rapide des moyens de transport utilisables pour se rendre dans un pays étranger. a) Documents Fahrkarten L évaluation culturelle ne fait pas l objet de la mise en place d unités spécifiques. Elle s inscrit dans l acquisition linguistique et ne peut pas être dissociée de l évaluation linguistique (que ce soit

Plus en détail

Médias NVS, documentation 2014

Médias NVS, documentation 2014 Médias NVS, documentation 2014 Association Suisse en Naturopathie Associazione Svizzera di Naturopatia NVS Schützenstrasse 42 CH-9100 Herisau T +41 71 352 58 50 F +41 71 352 58 81 nvs@naturaerzte.ch www.naturaerzte.ch

Plus en détail

Messages clefs de la Société Suisse des Officiers (SSO) à la Développement

Messages clefs de la Société Suisse des Officiers (SSO) à la Développement Messages clefs de la Société Suisse des Officiers (SSO) à la Développement de l armée (DEVA) Saint-Gall, 23 septembre 2014 La Société Suisse des Officiers (SSO) est toujours convaincu que l armée suisse

Plus en détail

Transparence dans la qualité des soins Le patient n est pas un facteur de coûts

Transparence dans la qualité des soins Le patient n est pas un facteur de coûts DVSP Dachverband Schweizerischer Patientenstellen Transparence dans la qualité des soins Le patient n est pas un facteur de coûts Journée de travail de la Politique nationale de la santé, 17 novembre 2011,

Plus en détail

Infrastructure fédérale de données géographique (IFDG)

Infrastructure fédérale de données géographique (IFDG) armasuisse Infrastructure fédérale de données géographique (IFDG) «Utilisations Webmapping et géoservices» Colloque swisstopo / 23 mars 2007 Alain Buogo / Rolf Buser Programme Accueil et introduction Alain

Plus en détail

Le projet MISTRA Les bénéfices pour les communes

Le projet MISTRA Les bénéfices pour les communes Département fédéral de l environnement, des transports, de l énergie et de la communication DETEC Office fédéral des routes OFROU Journée d information 21 avril 2010 à Morges Le projet MISTRA Les bénéfices

Plus en détail

Lecteur de codes barres CS3000 Installation et utilisation. Table des matières. Raccorder le lecteur... 2. Lire le lecteur... 3. Lecteur CS3000...

Lecteur de codes barres CS3000 Installation et utilisation. Table des matières. Raccorder le lecteur... 2. Lire le lecteur... 3. Lecteur CS3000... 1 Lecteur de codes barres CS3000 Installation et utilisation Table des matières Raccorder le lecteur............... 2 Raccordement USB 2 Raccordement USB avec Dockingstation....... 2 Lire le lecteur...................

Plus en détail

REISE NACH QUÉBEC REISEBERICHT VON SIGRID, MICHAEL UND ANNE SUSSMANN VOYAGE AU QUÉBEC RÉCIT DE VOYAGE DE SIGRID, MICHAEL ET ANNE SUSSMANN MONTRÉAL

REISE NACH QUÉBEC REISEBERICHT VON SIGRID, MICHAEL UND ANNE SUSSMANN VOYAGE AU QUÉBEC RÉCIT DE VOYAGE DE SIGRID, MICHAEL ET ANNE SUSSMANN MONTRÉAL REISE NACH QUÉBEC REISEBERICHT VON SIGRID, MICHAEL UND ANNE SUSSMANN VOYAGE AU QUÉBEC RÉCIT DE VOYAGE DE SIGRID, MICHAEL ET ANNE SUSSMANN Im Rahmen des Noël au Québec (Weihnachten in Québec) in den Galeries

Plus en détail

Neu: Tool Box System. Das modulare System für kontrolliertes Tool-Management

Neu: Tool Box System. Das modulare System für kontrolliertes Tool-Management Neu: Tool Box System Das modulare System für kontrolliertes Tool-Management Warum unser modulares System für Tool-Management auch ein Geldautomat ist... Neu: Tool Box System Ihre Vorteile: Geordnete und

Plus en détail

Nouveau centre de recyclage au Cactus Howald!

Nouveau centre de recyclage au Cactus Howald! Nouveau centre de recyclage au Cactus Howald! Simple, pratique et écologique, le centre de recyclage «Drive-in» du Cactus Howald est un nouveau service pour nos clients. Il a été mis en place par le Ministère

Plus en détail

Valais excellence Netzwerk

Valais excellence Netzwerk Valais excellence Netzwerk Ausbildungstage Einleitung 20 Introduction à Valais excellence 21 Valais excellence Einführung 23 Mit der Marke Wallis und dem Label 25 Valais excellence kommunizieren Communiquer

Plus en détail

Wie können meine Abschlüsse in Frankreich anerkannt werden?

Wie können meine Abschlüsse in Frankreich anerkannt werden? Wie können meine Abschlüsse in Frankreich anerkannt werden? Trotz der mittlerweile in Kraft getretenen europäischen Regelungen der beruflichen Anerkennung von Ausbildungen und Hochschuldiplomen, liegt

Plus en détail

Sehr geehrter Herr alt Regierungsrat und neuer Bundesrat

Sehr geehrter Herr alt Regierungsrat und neuer Bundesrat B u n d e s v e r s a m m l u n g A s s e m b l é e f é d é r a l e A s s e m b l e a f e d e r a l e A s s a m b l e a f e d e r a l a Es gilt das gesprochene Wort Der Generalsekretär CH-3003 Bern Grussbotschaft

Plus en détail

Hauswartungen Service de conciergerie. Liegenschaftsunterhalt Entretien de propriétés. Reinigung Nettoyage. Shop Boutique

Hauswartungen Service de conciergerie. Liegenschaftsunterhalt Entretien de propriétés. Reinigung Nettoyage. Shop Boutique Hauswartungen Service de conciergerie Liegenschaftsunterhalt Entretien de propriétés Reinigung Nettoyage Shop Boutique Reinigung ist nicht gleich Reinigung! Jeder Kunde hat individuelle Wünsche & Ansprüche.

Plus en détail

printed by www.klv.ch

printed by www.klv.ch Zentralkommission für die Lehrabschlussprüfungen des Verkaufspersonals im Detailhandel Lehrabschlussprüfungen für Detailhandelsangestellte 2006 Französisch Leseverständnis und gelenkte Sprachproduktion

Plus en détail

INTRANET: outil de Knowledge management au sein de l entreprise

INTRANET: outil de Knowledge management au sein de l entreprise ARIEL RICHARD-ARLAUD INTRANET: outil de Knowledge management au sein de l entreprise Ariel Richard-Arlaud I. Le Knowledge management L avènement de la technologie INTERNET bouleverse les habitudes et mentalités:

Plus en détail

Wirtschaftsmonitoring Stand der NGDI eine Sicht von aussen. Observatoire de l économie Etat de l INDG d un point de vue externe

Wirtschaftsmonitoring Stand der NGDI eine Sicht von aussen. Observatoire de l économie Etat de l INDG d un point de vue externe Dr. Bastian Graeff, SOGI FG Koordination Wirtschaftsmonitoring Stand der NGDI eine Sicht von aussen Dr. Bastian Graeff, OSIG Groupe de coordination Observatoire de l économie Etat de l INDG d un point

Plus en détail

ACHATS SANS FRONTIÈRES AVEC BPM

ACHATS SANS FRONTIÈRES AVEC BPM ACHATS SANS FRONTIÈRES AVEC BPM Marie, 34 secrétaire utilise la BPM Parcel-Station de Howald. NEW BPM PARCEL STATION PLUSIEURES LOCATIONS À LUXEMBOURG Réceptionnez vos colis de tous services postaux et

Plus en détail

Kappa Image Base Software

Kappa Image Base Software Kappa Image Base Software Control, Metreo & Noah Ryf AG, Bettlachstrasse 2, CH-2540 Grenchen www.ryfag.ch tel. 032 654 21 00 fax 032 654 21 09 1 a) Kappa Image Base Software Control Plattform / module

Plus en détail

Regelwerksstrategie des ENSI Stratégie réglementaire de l IFSN ENSI s Regulatory Framework Strategy

Regelwerksstrategie des ENSI Stratégie réglementaire de l IFSN ENSI s Regulatory Framework Strategy ENSI-AN-9171 ENSI, Industriestrasse 19, 5200 Brugg, Switzerland, Phone +41 56 460 84 00, E-Mail Info@ensi.ch, www.ensi.ch Regelwerksstrategie des ENSI März Mars March 2015 Regelwerksstrategie des ENSI

Plus en détail

Administration des abonnements...2. Outil de configuration...5. Installation Outlook 2003...7. Configuration Outlook 2003...10

Administration des abonnements...2. Outil de configuration...5. Installation Outlook 2003...7. Configuration Outlook 2003...10 Outlook 2003 INDEX Administration des abonnements...2 Outil de configuration...5 Installation Outlook 2003...7 Configuration Outlook 2003...10 Date de création 22.02.09 Version 1.0 Administration des abonnements

Plus en détail

T1IF. Enseignement secondaire technique Régime de la formation de technicien. Date: 21.07.2015 COSER

T1IF. Enseignement secondaire technique Régime de la formation de technicien. Date: 21.07.2015 COSER Date: 21.07.2015 Enseignement secondaire technique Régime de la formation de technicien T1IF COSER Configuration de services réseau d'un poste de travail Division informatique Section informatique - Technicien

Plus en détail

2. Quel est votre degré de satisfaction concernant le lieu et les horaires? Waren Sie mit dem Austragungsort und dem Zeitplan zufrieden?

2. Quel est votre degré de satisfaction concernant le lieu et les horaires? Waren Sie mit dem Austragungsort und dem Zeitplan zufrieden? Analyse des données du feedback général du Symposium 1. Qu'avez vous pensé de l'organisation en générale du symposium? Was haben Sie generell von der Organisation des Symposiums gehalten? Diversité Affichage

Plus en détail

Fachgruppe BiG Positionspapier Nr. 2. Partneridentifikation: Einsatz der Global Location Number GLN

Fachgruppe BiG Positionspapier Nr. 2. Partneridentifikation: Einsatz der Global Location Number GLN Hintergrund Fachgruppe BiG Positionspapier Nr. 2 Partneridentifikation: Einsatz der Global Location Number GLN Die Fachgruppe Beschaffung im Gesundheitswesen (BiG) setzt sich aus namhaften Schweizer Spitälern

Plus en détail

www.mobiliteit.lu / novabus Mobilitéitszentral: 2465 2465

www.mobiliteit.lu / novabus Mobilitéitszentral: 2465 2465 carte d invalidité Type B / TYPe C Invalidenausweis www.mobiliteit.lu / novabus Mobilitéitszentral: 2465 2465 Offre de transport pour personnes atteintes d une infirmité permamente et réduites dans leur

Plus en détail

Spannungsfelder zwischen Vision und Realität im neuen Rahmenlehrplan Zones de tension entre vision et réalité dans le nouveau plan d études cadre

Spannungsfelder zwischen Vision und Realität im neuen Rahmenlehrplan Zones de tension entre vision et réalité dans le nouveau plan d études cadre Spannungsfelder zwischen Vision und Realität im neuen Rahmenlehrplan Zones de tension entre vision et réalité dans le nouveau plan d études cadre Dr. Erich Wyler, Berner Fachhochschule Technik und Informatik

Plus en détail

Le PSN et la TIDN à l ASDD NCP und IDNT im SVDE

Le PSN et la TIDN à l ASDD NCP und IDNT im SVDE Nutridays 2014 Le PSN et la TIDN à l ASDD NCP und IDNT im SVDE Florine Riesen Membre du comité de l ASDD et membre du groupe de pilotage PSN/TIDN de l ASDD Vorstandsmitglied SVDE und Mitglied der Steuergruppe

Plus en détail

Verordnung über Sitzungsgelder und Honorare. Ordonnance concernant les indemnités et les honoraires. Ausgabe/Edition 04/07

Verordnung über Sitzungsgelder und Honorare. Ordonnance concernant les indemnités et les honoraires. Ausgabe/Edition 04/07 Verordnung über Sitzungsgelder und Honorare Ordonnance concernant les indemnités et les honoraires 2007 Ausgabe/Edition 04/07 I. Allgemeine Bestimmungen Art. 1 Geltungsbereich Diese Verordnung gilt für

Plus en détail

B1 FRANZÖSISCH EINSTUFUNGSTEST Forum eventuell Anmeldung für DELF B1

B1 FRANZÖSISCH EINSTUFUNGSTEST Forum eventuell Anmeldung für DELF B1 B1 FRANZÖSISCH EINSTUFUNGSTEST Forum eventuell Anmeldung für DELF B1 Unsere Tests helfen Ihnen dabei, das Niveau Ihrer Sprachkenntnisse gemäss den Kriterien des Gemeinsamen Europäischen Referenzrahmens

Plus en détail

Lösungen Lesen Französisch (4j/B1) (AHS) HT 2012/13, 8. Mai 2013

Lösungen Lesen Französisch (4j/B1) (AHS) HT 2012/13, 8. Mai 2013 Lösungen Lesen Französisch (4j/B1) (AHS) HT 2012/13, 8. Mai 2013 Hinweise zur Korrektur Bei der Korrektur werden ausschließlich die Antworten auf dem Antwortblatt berücksichtigt. Korrektur der Aufgaben

Plus en détail

KMK-FREMDSPRACHENZERTIFIKAT

KMK-FREMDSPRACHENZERTIFIKAT ...... KMK-FREMDSPRACHENZERTIFIKAT Zertifikatsprüfung Französisch für Wirtschaft und Verwaltung KMK-Stufe II (Threshold) Schriftliche Prüfung Musterprüfung 2 Zeit: 90 Minuten Hilfsmittel: Allgemeines zweisprachiges

Plus en détail

POSITION DE L UNES FACE AUX NOUVELLES TECHNOLOGIES DE L INFORMATION ET DE LA COMMUNICATION (NTIC)

POSITION DE L UNES FACE AUX NOUVELLES TECHNOLOGIES DE L INFORMATION ET DE LA COMMUNICATION (NTIC) POSITION DE L UNES FACE AUX NOUVELLES TECHNOLOGIES DE L INFORMATION ET DE LA COMMUNICATION (NTIC) Remarques préliminaires L Union Nationale des EtudiantEs de Suisse (UNES) estime que l enseignement traditionnel

Plus en détail

<praxisnahe software /> <logiciels fondés sur la pratique /> Brunner Informatik AG Im Oktober 1985 wurde der Grundstein zur heutigen Brunner Informatik AG gelegt. Damals, als

Plus en détail

Bundesamt für Energie 3003 Bern anna.baumgartner@bfe.admin.ch. Bern, 26. Juni 2013 sgv-sc. Vernehmlassungsantwort Kernenergiehaftpflichtverordnung

Bundesamt für Energie 3003 Bern anna.baumgartner@bfe.admin.ch. Bern, 26. Juni 2013 sgv-sc. Vernehmlassungsantwort Kernenergiehaftpflichtverordnung Dachorganisation der Schweizer KMU Organisation faîtière des PME suisses Organizzazione mantello delle PMI svizzere Umbrella organization of Swiss SME Bundesamt für Energie 3003 Bern anna.baumgartner@bfe.admin.ch

Plus en détail

Théories et pratiques dans les yogas de Suisse. Yogatheorien und Yogapraxis in der Schweiz

Théories et pratiques dans les yogas de Suisse. Yogatheorien und Yogapraxis in der Schweiz Avec le support du FNS, le Département interfacultaire d histoire et de sciences des religions (Université de Lausanne) et l Abteilung für Indologie (Université de Zürich) organisent un colloque sur :

Plus en détail

Anmeldung / Inscription

Anmeldung / Inscription BERNEXPO AG Telefon +41 31 340 11 11 Suisse Public Fax +41 31 340 11 44 Mingerstrasse 6 E-Mail suissepublic@bernexpo.ch Postfach Internet www.suissepublic.ch 3000 Bern 22 Anmeldung / Inscription Anmeldefrist

Plus en détail

Agglomerationsverkehr eine Herausforderung für den

Agglomerationsverkehr eine Herausforderung für den Agglomerationsverkehr eine Herausforderung für den Bund Hans Werder, Generalsekretär UVEK Referat an der Fachtagung des VCS Agglomerationsvekrehr im Stau vom 13. Januar 2006 in Bern 1. Agglomerationsverkehr

Plus en détail

MINERGIE une première dans le canton de Fribourg

MINERGIE une première dans le canton de Fribourg Conrad Lutz Architecte dipl. ETS cpg EPFL Architecte S.à.r.l., Fribourg MINERGIE une première dans le canton de Fribourg Exemple et synthèse d une construction à ossature bois respectant les critères du

Plus en détail

Berufs-/Fachmittelschulen Aufnahmeprüfung 2008. Bitte auf jedes Blatt die Prüfungsnummer schreiben!!! Punkte. Wortschatz (15 Punkte)

Berufs-/Fachmittelschulen Aufnahmeprüfung 2008. Bitte auf jedes Blatt die Prüfungsnummer schreiben!!! Punkte. Wortschatz (15 Punkte) Bitte auf jedes Blatt die Prüfungsnummer schreiben!!! Französisch A Wortschatz (15 Punkte) Punkte 1. Verben 2. Nomen 3. Weibliche Form 4. Gegenteil 5. Wohnbereich B Grammatik (45 Punkte) 6. Text ergänzen

Plus en détail

Wir sind ein Team mit langjähriger internationaler Erfahrung. im Flughafenbereich sowie auf dem Gebiet der Kommunaltechnik und im Strassenbau.

Wir sind ein Team mit langjähriger internationaler Erfahrung. im Flughafenbereich sowie auf dem Gebiet der Kommunaltechnik und im Strassenbau. Unternehmen L entreprise Wir sind ein Team mit langjähriger internationaler Erfahrung in der Entwicklung und Herstellung von Reinigungsfahrzeugen im Flughafenbereich sowie auf dem Gebiet der Kommunaltechnik

Plus en détail

Contenu. L entreprise se présente/service 3-7. Boîtiers de dérivation DK 8-131 1,5 à 240 mm 2, IP 54-67

Contenu. L entreprise se présente/service 3-7. Boîtiers de dérivation DK 8-131 1,5 à 240 mm 2, IP 54-67 Contenu L entreprise se présente/service 3-7 Boîtiers de dérivation DK 8-131 1,5 à 240 mm 2, IP 54-67 Petits distributeurs KV 132-175 3 à 54 éléments de, IP 54-65 Système de boîtiers combinables, avec

Plus en détail

Contrôleur d étanchéité VPS 504 S01-S02 Vanne VGG(F)/MBVEF Dichteprüfgerät VPS 504 S01-S02 Ventil VGG(F)/MBVEF

Contrôleur d étanchéité VPS 504 S01-S02 Vanne VGG(F)/MBVEF Dichteprüfgerät VPS 504 S01-S02 Ventil VGG(F)/MBVEF Notice d emploi Betriebsanleitung Contrôleur d étanchéité VPS 504 S01-S02 Vanne VGG(F)/MBVEF Dichteprüfgerät VPS 504 S01-S02 Ventil VGG(F)/MBVEF Informations générales Übersicht Description et fonctionnement

Plus en détail

TISSOT GRAND PRIX DE BERNE WELTCUPTURNIER DER DEGENFECHTER 23. / 24. / 25. OKTOBER 2015 IN DER SPORTHALLE WANKDORF WWW.GP-BERN.CH

TISSOT GRAND PRIX DE BERNE WELTCUPTURNIER DER DEGENFECHTER 23. / 24. / 25. OKTOBER 2015 IN DER SPORTHALLE WANKDORF WWW.GP-BERN.CH 52 TISSOT GRAND PRIX DE BERNE WELTCUPTURNIER DER DEGENFECHTER 23. / 24. / 25. OKTOBER 2015 IN DER SPORTHALLE WANKDORF WWW.GP-BERN.CH TISSOT PRC 200 FENCING TISSOT.CH 2 Programme Jeudi, 22 octobre 2015

Plus en détail

Lösungen Bewertungen. printed by www.klv.ch. Französisch. Zentralkommission für die Lehrabschlussprüfungen des Verkaufspersonals im Detailhandel

Lösungen Bewertungen. printed by www.klv.ch. Französisch. Zentralkommission für die Lehrabschlussprüfungen des Verkaufspersonals im Detailhandel Zentralkommission für die Lehrabschlussprüfungen des Verkaufspersonals im Detailhandel Lehrabschlussprüfungen für Detailhandelsangestellte 007 Französisch Leseverständnis und gelenkte Sprachproduktion

Plus en détail

Lösungen Französisch (AHS) Lesen (B1)

Lösungen Französisch (AHS) Lesen (B1) Lösungen Französisch (AHS) Lesen (B1) 15. Jänner 2015 Hinweise zur Korrektur Bei der Korrektur werden ausschließlich die Antworten auf dem Antwortblatt berücksichtigt. Korrektur der Aufgaben Bitte kreuzen

Plus en détail

VKF Brandschutzanwendung Nr. 11109

VKF Brandschutzanwendung Nr. 11109 Vereinigung Kantonaler Feuerversicherungen Auskunft über die Anwendbarkeit gemäss den erischen Brandschutzvorschriften VKF Brandschutzanwendung Nr. 11109 Gruppe 302 Gesuchsteller Raumheizer für feste Brennstoffe

Plus en détail

Die Magie der asiatischen Genüsse. La Magie des saveurs asiatiques

Die Magie der asiatischen Genüsse. La Magie des saveurs asiatiques Service Traiteur Catering Service La Magie des saveurs asiatiques Die Magie der asiatischen Genüsse Sushi Mania SA Sushi Mania AG Installée depuis 2002 à Vuadens, en plein cœur de la Gruyère, Sushi Mania

Plus en détail

11. November 2014, NH Hotel Freiburg

11. November 2014, NH Hotel Freiburg Info-Lunch ros Abschluss des Modellversuchs «Sanktionenvollzug» (ROS) Kurzpräsentation der Ergebnisse und erste Aussagen über die Bedeutung von ROS als ein mögliches Modell des Risikomanagements. 11. November

Plus en détail

Elektrischer Seifenspender Bedienungsanleitung

Elektrischer Seifenspender Bedienungsanleitung Elektrischer Seifenspender Bedienungsanleitung Bitte lesen Sie diese Bedienungsanleitung vor dem ersten Einsatz des Geraetes! Bestandteile Anwendung Hinweise! Verwenden Sie keine Akkus! Beachten Sie beim

Plus en détail

T2IF. Enseignement secondaire technique Régime de la formation de technicien. Date: 15.07.2014 WSERS1. Web Server Side Scripting 1

T2IF. Enseignement secondaire technique Régime de la formation de technicien. Date: 15.07.2014 WSERS1. Web Server Side Scripting 1 Date: 15.07.2014 Enseignement secondaire technique Régime de la formation de technicien T2IF WSERS1 Web Server Side Scripting 1 Division informatique Section informatique Nombre de leçons: 6 Semestre:

Plus en détail

Französisch. Lesen (B1) AHS 8. Mai 2015. Korrekturheft. Standardisierte kompetenzorientierte schriftliche Reifeprüfung / Reife- und Diplomprüfung

Französisch. Lesen (B1) AHS 8. Mai 2015. Korrekturheft. Standardisierte kompetenzorientierte schriftliche Reifeprüfung / Reife- und Diplomprüfung Standardisierte kompetenzorientierte schriftliche Reifeprüfung / Reife- und Diplomprüfung AHS 8. Mai 2015 Französisch Lesen (B1) Korrekturheft Hinweise zur Korrektur Bei der Korrektur werden ausschließlich

Plus en détail

ROHRSTRUKTUR FIRMENPROFIL STRUCTURE EN TUBULAIRE L ENTREPRISE

ROHRSTRUKTUR FIRMENPROFIL STRUCTURE EN TUBULAIRE L ENTREPRISE FIRMENPROFIL Die im Jahre 1955 gegründete Firma produziert und installiert seit mehr als fünfzig Jahren ein breites Sortiment von Jacquardanlagen verschiedener Art und Grössen. Unsere mehr als vierzig

Plus en détail

APPEL A CANDIDATURE PASSEURS D HISTOIRES STUTTGART SÉMINAIRE DE TRADUCTEUR TRICE S FRANCO-ALLEMANDS AUTOUR DE LA LITTÉRATURE JEUNESSE

APPEL A CANDIDATURE PASSEURS D HISTOIRES STUTTGART SÉMINAIRE DE TRADUCTEUR TRICE S FRANCO-ALLEMANDS AUTOUR DE LA LITTÉRATURE JEUNESSE APPEL A CANDIDATURE STUTTGART PASSEURS D HISTOIRES SÉMINAIRE DE TRADUCTEUR TRICE S FRANCO-ALLEMANDS AUTOUR DE LA LITTÉRATURE JEUNESSE Du 9 au 14 novembre 2014 Financé par la DVA-Stiftung L organise du

Plus en détail

230 V, 50 Hz Tension Pour mazout, diesel, pétrole ATTENTION: Mazout flocule dès 0ºC, ajoutez 10% pétrole svp.

230 V, 50 Hz Tension Pour mazout, diesel, pétrole ATTENTION: Mazout flocule dès 0ºC, ajoutez 10% pétrole svp. Ölheizgeräte Die mobile Heizung für Neubau, Umbau, Hallen etc. Zum Heizen und Trocknen. Automatische Zündung, enorme Heizleistung, günstige Betriebskosten! Durch Vorschalten eines Thermostats wird das

Plus en détail

SUNTIME PERGOLA R127 R140 R200 R130 T500

SUNTIME PERGOLA R127 R140 R200 R130 T500 SUNTIME PERGOLA R127 R140 R200 R130 T500 1 Das südliche Lebensgefühl hat längst auch hierzulande Einzug gehalten Outdoor-Living pur. Gerne sitzt man auch abends noch draussen am Tisch. Nur das Wetter

Plus en détail

Ferienkurse mit Meister Chu 5. 9. August 2015 in Spiez am Thunersee

Ferienkurse mit Meister Chu 5. 9. August 2015 in Spiez am Thunersee TAI CHI CHUAN Ferienkurse mit Meister Chu 5. 9. August 2015 in Spiez am Thunersee Stage d automne avec Maître Chu Du 5 au 9 août 2015 À Spiez au bord du Lac de Thoune Der alte authentische Yang Stil Style

Plus en détail

HALTES ÉNERGIE À BAELEN

HALTES ÉNERGIE À BAELEN HALTES ÉNERGIE À BAELEN Jeudi 24 mars 2011 à Lontzen Se chauffer, bientôt un confort impayable? Face à la hausse du prix des énergies, les factures de chauffage sont de plus en plus élevées. Pour certains

Plus en détail

Französisch. Hören (B1) HUM 8. Mai 2015. Korrekturheft. Standardisierte kompetenzorientierte schriftliche Reifeprüfung / Reife- und Diplomprüfung

Französisch. Hören (B1) HUM 8. Mai 2015. Korrekturheft. Standardisierte kompetenzorientierte schriftliche Reifeprüfung / Reife- und Diplomprüfung Standardisierte kompetenzorientierte schriftliche Reifeprüfung / Reife- und Diplomprüfung HUM 8. Mai 01 Französisch Hören (B1) Korrekturheft Hinweise zur Korrektur Bei der Korrektur werden ausschließlich

Plus en détail

Montageanleitung Rotationsaustragung Seite 2-4

Montageanleitung Rotationsaustragung Seite 2-4 D Montageanleitung Rotationsaustragung Seite 2-4 FR Instructions de montage du dispositif d alimentation rotatif pages 5-8 Wolf GmbH Postfach 1380 84048 Mainburg Tel. 08751/74-0 Fax 08751/741600 Internet:

Plus en détail

GE Money Bank. Simple et claire.

GE Money Bank. Simple et claire. GE Money Bank CRÉDITS CARTES LEASING ÉPARGNE Simple et claire. La facture mensuelle de votre Cumulus-MasterCard. GE imagination at work Cumulus-MasterCard Tout ce que vous avez toujours voulu savoir sur

Plus en détail

Employés du secteur public Suisse

Employés du secteur public Suisse Employés du secteur public Suisse AZB CH-9001 St. Gallen P.P./Journal ZV Info / juin 2010 Personnel public suisse Nouvelle image et nouvelles prestations Urs Stauffer Président Employés du secteur public

Plus en détail

T2IF. Enseignement secondaire technique Régime de la formation de technicien. Date: 21.07.2015 COREL. Conception de réseaux locaux

T2IF. Enseignement secondaire technique Régime de la formation de technicien. Date: 21.07.2015 COREL. Conception de réseaux locaux Date: 21.07.2015 Enseignement secondaire technique Régime de la formation de technicien T2IF COREL Conception de réseaux locaux Division informatique Section informatique - Technicien en informatique Nombre

Plus en détail

Feuille de données du système BASWAphon Base. Edition 2012 / 2

Feuille de données du système BASWAphon Base. Edition 2012 / 2 Feuille de données du système BASWAphon Be Edition 2012 / 2 Sommaire 1 Application 2 Caractéristiques du système 3 Structure de montage du système 4 Epaisseurs du système 5 Poids du système 6 Valeurs d

Plus en détail

Exemplar für Prüfer/innen

Exemplar für Prüfer/innen Exemplar für Prüfer/innen Kompensationsprüfung zur standardisierten kompetenzorientierten schriftlichen Reifeprüfung AHS Juni 2015 Französisch 2. Lebende Fremdsprache (4-jährig) Kompensationsprüfung Angabe

Plus en détail

Ereignis nach dem Abschluss per 30. Juni 2014 Die Kapitalanlage von CHF 1 800 000.- wurde an die Gesellschaft nach dem 30. Juni 2014 zurückbezahlt.

Ereignis nach dem Abschluss per 30. Juni 2014 Die Kapitalanlage von CHF 1 800 000.- wurde an die Gesellschaft nach dem 30. Juni 2014 zurückbezahlt. Medienmitteilung 22. Oktober 2014 DUAL REAL ESTATE INVESTMENT AG (an der BX Berne exchange kotiert), verbesserte ihr operatives Ergebnis im ersten Quartal 2014. EBITDA +32.7% von CHF 3 008 103 auf CHF

Plus en détail

On y va! A1. Hinweis für Testende. Einstufungstest. Testaufgaben 1 bis 18: 26 Punkte oder mehr u On y va! A1, Leçon 4

On y va! A1. Hinweis für Testende. Einstufungstest. Testaufgaben 1 bis 18: 26 Punkte oder mehr u On y va! A1, Leçon 4 On y va! A1 Einstufungstest Hinweis für Testende Dieser Test hilft Ihnen, neue Kursteilnehmer/innen mit Vorkenntnissen in Ihr Kurssystem einzustufen. Er besteht aus den Aufgabenblättern, einem gesonderten

Plus en détail

INFORMATIQUE ET GESTION INTEGREE

INFORMATIQUE ET GESTION INTEGREE Thèse No 4938 INFORMATIQUE ET GESTION INTEGREE DE L'EXPLOITATION AGRICOLE THESE présentée à l'ecole polytechnique fédérale, Zurich pour l'obtention du grade de Docteur es sciences techniques par Henri

Plus en détail

Abschlussprüfung 2004 LES VACANCES

Abschlussprüfung 2004 LES VACANCES Prüfungsdauer: 30 Minuten FRANZÖSISCH Abschlussprüfung 2004 an den Realschulen in Bayern (HAUPTTERMIN) HÖRVERSTEHEN Zu- und Vorname: Klasse: LES VACANCES Wichtige Hinweise: Sie hören jeden Text zweimal.

Plus en détail

SIX Pay, filiale de SIX Group, décroche une licence dans l'ue (dév.) 2. SIX-Group-Tochter SIX Pay erhält Lizenz für Dienstleistungen in der EU 3

SIX Pay, filiale de SIX Group, décroche une licence dans l'ue (dév.) 2. SIX-Group-Tochter SIX Pay erhält Lizenz für Dienstleistungen in der EU 3 SIX Pay, filiale de SIX Group, décroche une licence dans l'ue (dév.) 2 SIX-Group-Tochter SIX Pay erhält Lizenz für Dienstleistungen in der EU 3 Six Pay erhält Lizenz in Luxemburg - Expansion nach Osteuropa

Plus en détail

conseil en accessibilité

conseil en accessibilité conseil en accessibilité Quelques références de clients du secteur public Munshausen : Accessibilité du Tourist Center «A Robbesscheier» Banque européenne d investissement : Nouveau bâtiment à Luxembourg

Plus en détail

Le réseau NEBIS. Nos prestations vos avantages. NEBIS-Verbund Unsere Dienstleistungen Ihr Mehrwert

Le réseau NEBIS. Nos prestations vos avantages. NEBIS-Verbund Unsere Dienstleistungen Ihr Mehrwert Le réseau NEBIS Nos prestations vos avantages NEBIS-Verbund Unsere Dienstleistungen Ihr Mehrwert NEBIS Netzwerk von Bibliotheken und Informationsstellen in der Schweiz Inhalt NEBIS 3 Prestations 5 Le système

Plus en détail

MÉMORIAL. Verordnungs- und Verwaltungsblatt LÉGISLATIF ET ADMINISTRATIF. des Großherzogthums Luxemburg. Acte der Gesetzgebung.

MÉMORIAL. Verordnungs- und Verwaltungsblatt LÉGISLATIF ET ADMINISTRATIF. des Großherzogthums Luxemburg. Acte der Gesetzgebung. Nummer 15 97 Jahr 1853. Verordnungs- und Verwaltungsblatt des Großherzogthums Luxemburg. MÉMORIAL LÉGISLATIF ET ADMINISTRATIF DU GRAND-DUCHÉ DE LUXEMBOURG. Acte der Gesetzgebung. Actes législatifs. Generale-Administration

Plus en détail

LA CARTE DE SANTE CLE DE L'ACCES AU DOSSIER PATIENT INFORMA- TISE POINT DE VUE DES PATIENTS. Anne Eckhardt

LA CARTE DE SANTE CLE DE L'ACCES AU DOSSIER PATIENT INFORMA- TISE POINT DE VUE DES PATIENTS. Anne Eckhardt LA CARTE DE SANTE CLE DE L'ACCES AU DOSSIER PATIENT INFORMA- TISE POINT DE VUE DES PATIENTS Anne Eckhardt Zurich, 14 juillet 2001 Résumé (uniquement en allemand) Die Gesundheitskarte Aus Patientensicht

Plus en détail

Informatique pour Scientifiques I

Informatique pour Scientifiques I Informatique pour Scientifiques I Cours 6. - Introduction à la programmation - Elements de programmation dans Mathematica 28-11-06 Dr. Jean Hennebert 1 Plan Objectifs de ce cours: 1. Qu est-ce que la programmation?

Plus en détail

Parcage. Bases légales. Office des ponts et chaussées du canton de Berne. Tiefbauamt des Kantons Bern. Bau-, Verkehrsund Energiedirektion

Parcage. Bases légales. Office des ponts et chaussées du canton de Berne. Tiefbauamt des Kantons Bern. Bau-, Verkehrsund Energiedirektion Tiefbauamt des Kantons Bern Bau-, Verkehrsund Energiedirektion Office des ponts et chaussées du canton de Berne Direction des travaux publics, des transports et de l'énergie Tâches spéciales Technique

Plus en détail

Partizipation - Participation sanu - HeVs - Pfyn-Finges - FDDM 6-7 12. 2007 1

Partizipation - Participation sanu - HeVs - Pfyn-Finges - FDDM 6-7 12. 2007 1 -------------------------------------------------------------------------------------------- HERZLICH WILLKOMMEN CORDIALE BIENVENUE --------------------------------------------------------------------------------------------

Plus en détail

Control Products & Systems

Control Products & Systems Building Technologies 05/12 Control Products & Systems Guten Tag Drehen Sie die Effizienz rauf und die Kosten runter mit dem neuen Frequenzumrichter G120P. In der aktuellen Newsletter Ausgabe erfahren

Plus en détail

Zweite Kammer/ Deuxième Chambre 14.5.2014

Zweite Kammer/ Deuxième Chambre 14.5.2014 Zweite Kammer/ Deuxième Chambre 14.5.2014 1. Verfahren/Procédures a) Plainte contre un concurrent N 128/14 (Contrefaçon de réalisations publicitaires: Présentation des offres sur Internet) b) N 117/14

Plus en détail

Schriftliche Aufnahmeprüfung für das Schuljahr 2012 / 2013

Schriftliche Aufnahmeprüfung für das Schuljahr 2012 / 2013 Pädagogische Maturitätsschule Kreuzlingen Schriftliche Aufnahmeprüfung für das Schuljahr 2012 / 2013 Französisch Envol Unités 1 12 Nummer Name, Vorname: Sekundarschule: Französisch-Lehrbuch: Wir arbeiten

Plus en détail

Réponses aux questions

Réponses aux questions Concours de projets d aménagement urbain Place des Augustins à Genève Prix Evariste Mertens 2014 Réponses aux questions Les questions sont retranscrites ici telles qu elles ont été posées, c est à dire

Plus en détail

Französisch. Hörverstehen. Serie 2/3. Kandidatennummer: Name: Vorname: Datum der Prüfung: Die Experten:

Französisch. Hörverstehen. Serie 2/3. Kandidatennummer: Name: Vorname: Datum der Prüfung: Die Experten: Zentralprüfungskommission schulischer Teil Französisch Hörverstehen Lehrabschlussprüfungen 2008 für Kauffrau/Kaufmann Erweiterte Grundbildung (E-Profil) Serie 2/3 Lösungen Bewertungen Kandidatennummer:

Plus en détail