[EPIC] Correctifs court-terme à appliquer aux checks portant sur `id_pdc_itinerance`

[thbar]

cc @vdegove en particulier car ça nous concerne dès etalab/transport-site#5343, et @stephane-pignal @AurelienC également.

La spécification technique actuelle (v2.3.1) de id_pdc_itinerance est la suivante, et présente des soucis qu'il va être temps de traiter.

schema-irve/statique/schema-statique.json

Lines 259 to 268 in c547877

	{
	"name": "id_pdc_itinerance",
	"description": "L'identifiant du point de recharge délivré selon les modalités définies à l'article 10 du décret n° 2017-26 du 12 janvier 2017. Cet ID débute par FR suivi de 3 caractères délivrés par l'AFIREV, suivi de \"E\" pour l'équivalent du point de recharge en anglais EVSE - Electric Vehicule Supply Equipment (https://afirev.fr/fr/informations-generales/). Ne pas mettre de séparateur * ou -. Si le point de recharge n'est pas en itinérance, merci d'indiquer \"Non concerné\".",
	"example": "FRA68E680210015",
	"type": "string",
	"constraints": {
	"required": true,
	"pattern": "(?:(?:^|,)(^[A-Z]{2}[A-Z0-9]{4,33}$|Non concerné))+$"
	}
	},

1. Pas de contrainte d'unicité sur id_pdc_itinerance

Chaque ligne des fichiers représentant exactement 1 "pdc", id_pdc_itinerance est réputé unique (si on met de côté les Non concernés).

Or rien ne contraint cette unicité dans la spécification technique TableSchema actuellement (voir plus haut).

Je pense que l'explication est peut-être liée à ce que je perçois comme quelque chose de difficile à exprimer correctement avec TableSchema:

• il est un peu difficile en pratique de mettre en place dans TableSchema une contrainte d'unicité "sauf pour certaines lignes".
• en temps normal (= si on n'avait pas de "Non concerné"s), il suffirait d'ajouter "primaryKey": "id_pdc_itinerance" au JSON, et ça serait réglé (voir https://specs.frictionlessdata.io/table-schema/#primary-key)
• on ne peut pas directement dire "sauf si c'est égal à Non concerné
• on peut tenter de contourner en mettant required: false sur id_pdc_itinerance, mais il faut alors considérer Non concerné comme une valeur manquante, et les déclarer dans missingValues (

  schema-irve/statique/schema-statique.json

  Lines 504 to 506 in c547877

  	"missingValues": [
  	""
  	]

  )
• toutefois si on fait ça, missingValues s'applique à tous les champs... et on peut donc avoir "Non concerné" n'importe où, et on devrait le considérer comme une valeur manquante, ce qui est un peu bancal

Ce n'est pas un problème théorique: certains fichiers v2 (un nombre limité actuellement) publiés sur data.gouv contiennent plusieurs lignes pour le même id_pdc_itinerance, et sont donc considérés techniquement comme valides, alors qu'ils sont fondamentalement (pour le coup, dès la clé primaire) invalides.

Donc à voir si on arrive à exprimer ça correctement dans le schéma, ou si ça doit être un custom check en amont chez nous.

2. Reste historique dans la regexp

Si on regarde bien le pattern: (?:(?:^|,)(^[A-Z]{2}[A-Z0-9]{4,33}$|Non concerné))+$, je pense qu'il y a un reste de copié-collé dedans. Ça fait croire qu'il y aurait la possibilité de séparer plusieurs identifiants par des virgules au sein d'une seule cellule, mais ça ne l'autorise pas vraiment non plus.

On pourrait nettoyer cette regexp pour y voir plus clair, à vérifier, par exemple:

^(?:[A-Z]{2}[A-Z0-9]{4,33}|Non concerné)$

3. Durcissement de la regexp

Voir #24 et autres échanges : je ne pense pas que la regexp soit nickel par ailleurs, on ferait bien avant d'élargir ou d'être tentés de s'en inspirer ailleurs (#73) de la mettre au propre.

En vérifiant bien sûr le "taux de casse".

[vdegove]

En discutant avec un opérateur qui ne souhaite pas être intégré dans le dispositif d’itinérance (voir note plus bas), je pense qu’on doit aussi se poser la question à plus long terme de revoir à la fois le couplage existant entre cette pseudo clef primaire et le dispositif d’itinérance, et d’autre part le mécanisme d’obtention (actuellement payant) de prefixes qui garantissent la non-collision des identifiants.

En fait si on lit la documentation la clef primaire porterait à la fois sur id_pdc_itinerance et id_pdc_local : ce dernier champ id_pdc_local est à renseigner avec un identifiant unique si le premier n’est pas renseigné (et admet aussi, pour compliquer les choses, le recopiage de l’id_pdc_itinerance). On pointe même vers https://heidi.app.etalab.studio pour générer un UUID qui sera unique.

Pour moi ce qu’il y aurait à faire de mieux :

• Fusionner les deux champ id_pdc_itinerance et id_pdc_local, en les renommant id_pdc tout court
• Que ce champ id_pdc puisse être rempli même sans trigramme d’itinérance (il faut s’assurer d’un mécanisme pour la non-collision des identifiants)
• Faire les jointures des autres tables sur ce champ là
• Créer un nouveau champ booléen "in_itinerance".

Pour la non-collision des identifiants : proposer un simple générateur d’UUID est suffisant, quitte à le prefixer. On pourrait rajouter une règle (énoncée dans le schéma, et durcie dans le validateur) qui dit que si le booléen d’itinérance est à true, alors l’identifiant doit suivre une regexp.

Le type d’opérateur avec qui j’ai parlé : propose des bornes IRVE pour des gîtes, compatible OCPI, souhaite éventuellement fournir un opendata complet y compris les données dynamiques (disponibilité, pricing). Mais par contre il ne souhaite pas créer un opérateur en bonne et due forme (donc chaque gîte opère sa borne et basta) et ne pas être intégré à l’itinérance. On voit bien que si chacun des gîtes crée son propre opérateur, on va vite tomber à court de préfixes à 3 lettres.

[thbar]

@vdegove pour faire rapide mais on en reparle tout à l'heure:

• le besoin que j'ai levé en ouvrant ce ticket n'est pas de refondre le système d'identifiant mais de rendre validable techniquement l'existant ; ce que tu soulèves va beaucoup plus loin, je préfère que ça aille dans un autre ticket car c'est une grosse pelote de laine, si tu es ok, pour ne pas nous perdre
• ce que tu évoques a déjà été discuté plusieurs fois dans le passé, la conclusion n'a jamais été de faire une clé composite ; dans les faits id_pdc_itinerance est une clé primaire (hors Non Concerné), pas une pseudo clé primaire. Ça lève par ailleurs d'autres questions à rediscuter (on en reparlera)

(je ne dis pas que tes arguments ne sont pas valables pour partie, je pense que ça va beaucoup plus loin que le besoin que j'ai levé même si c'est connecté)

[vsurrel]

je confirme le besoin d'avoir une clé de jointure qui ne soit pas lié à un identifiant d'itinérance. En l'état je me suis créé mon propre trigramme 'juste' pour avoir la jointure entre mon fichier IRVE statique et IRVE dynamique. Ca fera l'affaire en attendant d'avoir une solution plus propre...

[loco-philippe]

cc @vdegove en particulier car ça nous concerne dès etalab/transport-site#5343, et @stephane-pignal @AurelienC également.

La spécification technique actuelle (v2.3.1) de id_pdc_itinerance est la suivante, et présente des soucis qu'il va être temps de traiter.

schema-irve/statique/schema-statique.json

Lines 259 to 268 in c547877

{
"name": "id_pdc_itinerance",
"description": "L'identifiant du point de recharge délivré selon les modalités définies à l'article 10 du décret n° 2017-26 du 12 janvier 2017. Cet ID débute par FR suivi de 3 caractères délivrés par l'AFIREV, suivi de "E" pour l'équivalent du point de recharge en anglais EVSE - Electric Vehicule Supply Equipment (https://afirev.fr/fr/informations-generales/). Ne pas mettre de séparateur * ou -. Si le point de recharge n'est pas en itinérance, merci d'indiquer "Non concerné".",
"example": "FRA68E680210015",
"type": "string",
"constraints": {
"required": true,
"pattern": "(?:(?:^|,)(^[A-Z]{2}[A-Z0-9]{4,33}$|Non concerné))+$"
}
},

1. Pas de contrainte d'unicité sur id_pdc_itinerance

Chaque ligne des fichiers représentant exactement 1 "pdc", id_pdc_itinerance est réputé unique (si on met de côté les Non concernés).

Or rien ne contraint cette unicité dans la spécification technique TableSchema actuellement (voir plus haut).

Je pense que l'explication est peut-être liée à ce que je perçois comme quelque chose de difficile à exprimer correctement avec TableSchema:

• il est un peu difficile en pratique de mettre en place dans TableSchema une contrainte d'unicité "sauf pour certaines lignes".

• en temps normal (= si on n'avait pas de "Non concerné"s), il suffirait d'ajouter "primaryKey": "id_pdc_itinerance" au JSON, et ça serait réglé (voir https://specs.frictionlessdata.io/table-schema/#primary-key)

• on ne peut pas directement dire "sauf si c'est égal à Non concerné

• on peut tenter de contourner en mettant required: false sur id_pdc_itinerance, mais il faut alors considérer Non concerné comme une valeur manquante, et les déclarer dans missingValues (

    [schema-irve/statique/schema-statique.json](https://github.com/etalab/schema-irve/blob/c54787771bd8786d5f997e5d088c9688ba25e744/statique/schema-statique.json#L504-L506)
  
  
      Lines 504 to 506
    in
    [c547877](/etalab/schema-irve/commit/c54787771bd8786d5f997e5d088c9688ba25e744)
  
  
  
  
  
      
        
         "missingValues": [ 
      
  
      
        
             "" 
      
  
      
        
         ] 
  

  )

• toutefois si on fait ça, missingValues s'applique à tous les champs... et on peut donc avoir "Non concerné" n'importe où, et on devrait le considérer comme une valeur manquante, ce qui est un peu bancal

Ce n'est pas un problème théorique: certains fichiers v2 (un nombre limité actuellement) publiés sur data.gouv contiennent plusieurs lignes pour le même id_pdc_itinerance, et sont donc considérés techniquement comme valides, alors qu'ils sont fondamentalement (pour le coup, dès la clé primaire) invalides.

Donc à voir si on arrive à exprimer ça correctement dans le schéma, ou si ça doit être un custom check en amont chez nous.

2. Reste historique dans la regexp

Si on regarde bien le pattern: (?:(?:^|,)(^[A-Z]{2}[A-Z0-9]{4,33}$|Non concerné))+$, je pense qu'il y a un reste de copié-collé dedans. Ça fait croire qu'il y aurait la possibilité de séparer plusieurs identifiants par des virgules au sein d'une seule cellule, mais ça ne l'autorise pas vraiment non plus.

On pourrait nettoyer cette regexp pour y voir plus clair, à vérifier, par exemple:

^(?:[A-Z]{2}[A-Z0-9]{4,33}|Non concerné)$

3. Durcissement de la regexp

Voir #24 et autres échanges : je ne pense pas que la regexp soit nickel par ailleurs, on ferait bien avant d'élargir ou d'être tentés de s'en inspirer ailleurs (#73) de la mettre au propre.

En vérifiant bien sûr le "taux de casse".

Pour info, une extension de TableSchema pour exprimer une relation 1:1 ou 1:n entre deux champs est définie (voir Pattern n°16 de TableSchema V1 et Recipes de TableSchema V2).
La règle d'unicité des id_pdc_itinerance s'exprime par une relation 1:1 entre le champ index(numéro de ligne) et le champ id_pdc_itinerance.
Une implémentation TableSchema est disponible.
Une implémentation Validata également (custom_checks + validation).

L'implémentation des dépendances des champs obligatoires liées au modèle de données est présentée ci-dessous (la première ligne exprime la règle d'unicité des id_pdc_itinerance):

# complément à inclure dans le schéma de données
schema = {
    'relationships': [
         # relation unicité des pdl
         {"fields": ["id_pdc_itinerance", "index"],                    "link" : "coupled" },   
         # relations inter entités
         {"fields": ["id_station_itinerance", "contact_operateur"],    "link" : "derived" },
         {"fields": ["id_station_itinerance", "nom_enseigne"],         "link" : "derived" },
         {"fields": ["id_station_itinerance", "coordonneesXY"],        "link" : "derived" },
         {"fields": ["id_pdc_itinerance", "id_station_itinerance"],    "link" : "derived" },
         # relations intra entité - station
         {"fields": ["id_station_itinerance", "nom_station"],          "link" : "derived" },
         {"fields": ["id_station_itinerance", "implantation_station"], "link" : "derived" },
         {"fields": ["id_station_itinerance", "date_maj"],             "link" : "derived" },
         {"fields": ["id_station_itinerance", "nbre_pdc"],             "link" : "derived" },
         {"fields": ["id_station_itinerance", "condition_acces"],      "link" : "derived" },
         {"fields": ["id_station_itinerance", "horaires"],             "link" : "derived" },
         {"fields": ["id_station_itinerance", "station_deux_roues"],   "link" : "derived" },
         # relations intra entité - localisation
         {"fields": ["coordonneesXY", "adresse_station"],              "link" : "derived" }
    ]
}

Elles découlent du modèle de données suivant :

---
title: Modele - schema statique v2.3.1
---
erDiagram
    AMENAGEUR ||..|{ STATION : amenage
    AMENAGEUR {
        string nom_amenageur
        string siren_amenageur
        string contact_amenageur
    }
    OPERATEUR ||..|{ STATION : "exploite pour le compte de l enseigne"
    OPERATEUR {
        string contact_operateur PK "M"
        string nom_operateur
        string telephone_operateur
    }
    ENSEIGNE ||..|{ STATION : "heberge"
    ENSEIGNE {
        string nom_enseigne PK "M"
    }
    STATION {
        string  id_station_itinerance PK "M"
        string  nom_station "M"
        enum    implantation_station "M"
        integer nbre_pdc "M"
        string  condition_acces "M"
        string  horaires "M"
        boolean station_deux_roues "M"
        date    date_maj "M"
        string  id_station_local
        enum    raccordement
        string  num_pdl
        date    date_mise_en_service
    }
    LOCALISATION ||--|{ STATION : "localise"
    LOCALISATION {
       array   coordonneesXY PK "M"
       string  adresse_station "M"
       string  code_insee_commune
    }
    STATION ||--|{ POINT_DE_CHARGE : regroupe
    POINT_DE_CHARGE {
        string id_pdc_itinerance PK "M Root"
        number puissance_nominale "M"
        boolean prise_type_ef "M"
        boolean prise_type_2 "M"
        boolean prise_type_combo_ccs "M"
        boolean prise_type_chademo "M"
        boolean prise_type_autre "M"
        boolean paiement_acte "M"
        boolean reservation "M"
        enum    accessibilite_pmr "M"
        string  restriction_gabarit "M"
        string  id_pdc_local
        boolean gratuit
        boolean paiement_autre
        boolean paiement_cb
        string  tarification
        string  observations
        boolean cable_t2_attache
    }

Loading