Powered by AppSignal & Oban Pro
Would you like to see your link here? Contact us

Les concepts de base

livebooks/2_bases/bases.livemd

Les concepts de base

1. INTRODUCTION

Avant de nous plonger dans les représentations des réseaux, de la multimodalité ou de l’accessibilité, posons les bases.

1.1. Pourquoi cette partie ?

Pour

📌 Partager le même vocabulaire et être précis dans son usage

📌 Démystifier la normalisation

1.2. Ce que vous allez apprendre

✅ Quelques définitions générales

✅ Concepts de base utilisés dans les parties suivantes


💡 Bon à savoir : Aucun prérequis technique n’est nécessaire.

2. MODÈLES DE DONNÉES, NORMES ET PROFILS

2.1. Modèle de données

Définition : un modèle abstrait définissant des concepts et leurs attributs, ainsi que les relations entre chaque concept. Le tout permet de s’accorder sur une référence commune avant d’échanger des informations (= des données).

En bref

Cela représente :

  • Des définitions de concepts
  • Des éléments de caractérisation des concepts
  • Des relations entre les concepts

C’est utile pour :

  • S’accorder sur des concepts et leur description
  • Utiliser le même vocabulaire pour des implémentations différentes

Dans notre cas : Transmodel

Exemple :

classDiagram
  direction LR
    ORGANISATION *-- ORGANISATION_SECTION : est composé de 
    ORGANISATION_SECTION <|-- EQUIPE
    ORGANISATION_SECTION <|-- DEPARTEMENT
    DEPARTEMENT  --> TYPE_D_OPERATION : caractérisé par
    DEPARTEMENT *-- EQUIPE : comprend

    ORGANISATION : +Id
    ORGANISATION : +Nom
    ORGANISATION : +NomCommercial
    ORGANISATION : +Statut

    ORGANISATION_SECTION : +Id
    ORGANISATION_SECTION : +Nom
    ORGANISATION_SECTION : +NomCourt

    DEPARTEMENT : +Id
    DEPARTEMENT : +Nom

    EQUIPE : +Id

    TYPE_D_OPERATION : +Id

🫵 Exercice pratique

Dans le modèle conceptuel de données ci-dessous,

  • Combien avons-nous de concepts ?
  • Combien d’attributs avons-nous dans le concept ‘ORGANISATION’ ?
  • Quel est le concept portant la granularité la plus fine ?

2.2. Normes

Définition : document établi par consensus et approuvé par un organisme de normalisation reconnu (ex. AFNOR, CEN, ISO), qui fournit, pour des usages communs et répétés, des règles, des lignes directrices ou des caractéristiques, pour des activités ou leurs résultats, garantissant un niveau d’ordre optimal dans un contexte donné.

En bref

Cela représente :

  • Des règles métier d’usage des concepts définis dans le modèle conceptuel de données
  • Des règles sur l’échange des données
  • Des choix prédéfinis sur la présence obligatoire ou non de certains concepts et attributs
  • Les valeurs permises pour certains attributs

C’est utile pour :

  • Favoriser la standardisation des échanges de données
  • Garantir un certain niveau de qualité des données échangées

Dans notre cas : NeTEx et SIRI

Norme vs standard : la seule différence est dans la gouvernance !


Une norme est définie par un organisme de normalisation (ex. AFNOR, ISO). Un standard est défini par un groupe d’acteurs qui n’est pas un organisme de normalisation (ex. W3C, Unicode)

Exemple :

classDiagram
  direction LR
    ORGANISATION *-- ORGANISATION_SECTION : est composé de 
    ORGANISATION_SECTION <|-- EQUIPE
    ORGANISATION_SECTION <|-- DEPARTEMENT
    DEPARTEMENT  --> TYPE_D_OPERATION : caracterisé par
    DEPARTEMENT *-- EQUIPE : comprend

    ORGANISATION : -Id
    ORGANISATION : +Nom, MultilingualString [0..1]
    ORGANISATION : +NomCommercial, MultilingualString [0..1]
    ORGANISATION : +Statut, Boolean [0..1]

    ORGANISATION_SECTION : -Id
    ORGANISATION_SECTION : +Nom, MultilingualString [0..1]
    ORGANISATION_SECTION : +NomCourt, MultilingualString [0..1]
    ORGANISATION_SECTION : #OrganisationRef

    DEPARTEMENT : -Id
    DEPARTEMENT : +Nom, MultilingualString
    DEPARTEMENT : -equipes, EQUIPE [0..*]

    EQUIPE : -Id
    EQUIPE : #DepartmentRef

    TYPE_D_OPERATION : -Id

🫵 Exercice pratique

Nommez au moins une différence avec le modèle conceptuel de données présenté plus haut.

2.3. Profils de norme

Définition : sous-ensemble défini à partir d’une norme ou d’un standard qui peut comporter des règles spécifiques.

En bref

Cela représente :

  • Une vue réduite d’une norme ou d’un standard existant
  • Des règles métier ou d’échanges de données partagées par un groupe d’acteurs

C’est utile pour :

  • Favoriser l’usage d’une norme très riche
  • Soutenir les échanges entre un certain type d’acteurs (ex. travaillant dans une même région, fournissant des données à un même commanditaire)

Dans notre cas : le profil France de NeTEx

Exemple :

classDiagram
  direction LR
    ORGANISATION *-- ORGANISATION_SECTION : est composé de 
    ORGANISATION_SECTION <|-- EQUIPE
    ORGANISATION_SECTION <|-- DEPARTEMENT
    DEPARTEMENT  --> TYPE_D_OPERATION : caractérisé par
    DEPARTEMENT *-- EQUIPE : comprend

    ORGANISATION : -Id
    ORGANISATION : +Nom, MultilingualString [1..1]
    ORGANISATION : +NomCommercial, MultilingualString [1..1]
    ORGANISATION : +Statut, Boolean [1..1]

    ORGANISATION_SECTION : -Id
    ORGANISATION_SECTION : +Nom, MultilingualString [0..1]
    ORGANISATION_SECTION : +NomCourt, MultilingualString [0..1]
    ORGANISATION_SECTION : #OrganisationRef

    DEPARTEMENT : -Id
    DEPARTEMENT : +Nom, MultilingualString
    DEPARTEMENT : -equipes, EQUIPE [0..*]

    EQUIPE : -Id
    EQUIPE : #DepartmentRef

    TYPE_D_OPERATION : -Id

🫵 Exercice pratique

Nommez au moins une différence avec l’extrait de la norme présentée plus haut.

3. LES BASES POUR COMPRENDRE TRANSMODEL ET NETEX

3.1. Le transport public

Dans Transmodel et toutes les normes qui en sont dérivées, le Transport public est tout service de transport promu et disponible à l’ensemble des usagers, quel que soit son mode d’opération. À noter, Transmodel ne réduit pas la définition du transport public à l’existence ou non de conditions d’accès aux services de transport. PT © CEN, TC278, WG3, SG4 (CC-BY-SA)

À retenir :

  • périmètre plus large que les simples ‘transports en communs’
  • richesse des concepts et des attributs pour modéliser toutes les réalités du transport public

3.2. Transmodel, NeTEx et SIRI

Rappel :

  • Transmodel est le modèle conceptuel de données
  • NeTEx et SIRI sont des formats d’échanges normalisés issus de Transmodel

Concrètement :

  • Les concepts utilisés dans NeTEx et SIRI sont définis dans Transmodel
  • Chaque concept (ou entité) a un identifiant qui permet de le référencer ailleurs (Id <> Ref)
  • NeTEx et SIRI portent une vue de Transmodel qui répond à leur périmètre fonctionnel

NeTEx = Network Timetable Exchange


Pour toutes les données théoriques (= planifiées, connues d’avance) décrivant une offre de transport public allant de la description topologique du réseau à son offre tarifaire en passant par ses éléments d’accessibilité.

SIRI = Service Interface for Real-time Information


Pour toutes les données en temps réel (= dynamiques, non connues d’avance) décrivant l’état d’une offre de transport public à un instant T allant de la position des véhicules à l’état de fonctionnement des ascenseurs en passant par les taux d’affluence.

3.3. Les profils France de NeTEx et SIRI

Rappel : un profil permet de faciliter une implémentation locale d’une norme.

En France, nous avons :

  • un profil France pour NeTEx
  • un profil France pour SIRI

Le profil France de NeTEx comporte plusieurs parties :

Ce qu’il faut retenir : c’est l’ensemble de ces parties qui forment le profil France. On ne peut pas travailler sur la partie accessibilité sans tenir compte de la partie descriptive des arrêts, par exemple.

3.4. Quelques concepts de base

Pour faciliter la prise en main des concepts de base, il a été décidé de privilégier les traductions françaises des concepts contenus dans NeTEx (Transmodel). Les noms d’origine en anglais sont notés entre parenthèses et en italique.

Pour décrire spacialement ce qui nous entoure :

  • POINT (POINT) : Un nœud de dimension 0 servant à la description spatiale du réseau.
  • TRONCON (LINK) : Un objet défini dans l’espace, orienté et de dimension 1, utilisé pour décrire la structure du réseau, définissant la connexion entre deux POINTs.

Un POINT comprend les attributs obligatoires suivants :

  • Nom (Name) : le nom du POINT
  • Localisation (Location) : localisation du point

Dans Localisation (Location), on retrouve notamment les attributs suivants :

  • Longitude
  • Latitude

Cette imbrication est permise par l’usage du XML comme langage informatique grâce à l’imbrication des balises :


   Exemple de point
  
    -0.37315428391
    49.21139117869
  

Pour décrire finement une station de métro, par exemple, on utilisera les concepts suivants :

  • LIEU D’ARRÊT (STOP PLACE) : Lieu comprenant un ou plusieurs emplacements où les véhicules peuvent s’arrêter et où les voyageurs peuvent monter à bord ou descendre des véhicules ou préparer leur déplacement.
  • ACCÈS DE LIEU D’ARRÊT (STOP PLACE ENTRANCE) : Un ACCÈS DE LIEU D’ARRÊT est un accès physique à un LIEU D’ARRÊT (entrée ou sortie). Il peut comporter une porte, une barrière, un portillon ou tout autre signe distinctif d’un accès.
  • ZONE D’EMBARQUEMENT (QUAY) : Lieu tel qu’une plateforme, zone, quai ou voie à quai où les voyageurs peuvent accéder aux véhicules de transport public, taxis, cars ou tout autre mode de transport.

De la même manière que pour les points, on pourra imbriquer plusieurs attributs descriptifs pour chaque concept.

Introduction Les basesLignes et Horaires - Rochefort