Protocole pour renseigner l’identifiant unique du parking

[be-mercier]

Les instructions pour renseigner l'identifiant unique sont les suivantes:
L’identifiant unique du parking, délivré par le Point d’accès national. INSEE-P-xxx où INSEE est le code INSEE de la commune et xxx est le numéro d’ordre sur 3 chiffres.

Dans le cas de la SAEMES (opérateur de parking à Paris et aux alentours), les parkings sont disponibles dans plusieurs communes, et plusieurs arrondissements, ayant chacun un code INSEE différent.

Quelle serait la meilleure pratique pour attribuer un numéro d'ordre ? Est-ce que je numérote les parkings opérateur par opérateur, indifféremment du code INSEE, ce qui donnerait des numéros de ce style :

75101-P-001, 75105-P-002, 75107-P-003, 75109-P-004, 78146-P-005 ....

Ou au contraire, le numéro d'ordre est-il spécifique au code INSEE? Dans ce cas, j'imagine attribuer les identifiants uniques pour les parkings de la SAEMES ainsi :

75101-P-001, 75105-P-001, 75107-P-001, 75109-P-001, 78146-P-001...

La deuxième option me semble plus rigoureuse, mais elle demande aux équipes chargées de consolider la base de croiser les bases de données d'un gestionnaire de parkings avec celles des autres gestionnaires opérant des parkings sur le même périmètre.

[be-mercier]

Etant donnée que le unique parking ID sera attribué par les équipes de transport.data.gouv.fr au moment de la consolidation, et que le producteur de données n'a pas à s'en soucier, je propose que ce champ ne soit plus indiqué comme "obligatoire".

[AntoineAugusti]

Salut Béatrice,

La transmission d'un identifiant unique est nécessaire pour que le PAN puisse assurer une consolidation et pour s'assurer que des changements d'attributs soient répercutés. S'il n'y a pas d'identifiant unique et que quelqu'un dépose 2 fichiers (avec une modification d'un attribut d'un parking dans le 2ème fichier), l'identifiant unique est nécessaire pour faire une liaison dans le temps. Tu ne peux donc pas t'en passer, même si le PAN veut renuméroter plus tard.

Les communes sont-elles capables de numéroter elles-mêmes des parkings de plusieurs opérateurs ? Si c'est l'opérateur qui numérote et transmet cet identifiant aux communes qui déclarent in fine, il y aura un risque collision comme tu le remarques.

[be-mercier]

Hello Antoine,

Il me semble qu'il y a deux cas d'usages : la création d'une base de données par une commune from scratch et la mise à jour de données existantes par une commune.

Dans le premier cas, il me semblerait plus simple que les communes puissent saisir les données, sans spécifier un numéro d'identifiant unique (les équipes transport.data.gouv.fr se chargeront de l'attribuer au moment de l'intégration de ces données dans la base nationale).

Dans le deuxième cas, je suis d'accord avec toi que le numéro paraît indispensable afin que l'équipe transport.data.gouv.fr puisse suivre les mises à jour de ces données.

Peut-être qu'il serait judicieux de donner des instructions claires pour le renseignement de ce champs dans la description du schéma et du readme. (En particulier, car les indications actuelles sous le champs laissent à penser que c'est à l'équipe du PAN de communiquer le numéro d’identifiant unique avant que la commune puisse commencer à renseigner ses données).

On peut imaginer quelque chose du genre:

• Est-ce la première fois que vous publiez vos données de stationnement ? si oui, vous pouvez renseigner le numéro d'identifiant unique selon cette modalité ...
  Si vous mettez à jour des données déjà publiées, vous pouvez retrouver le numéro d'identifiant unique [ ici ] (lien vers la dernière version de la base).

Dans le très court terme, je me charge de construire une première version de la base, et j'attribuerai moi-même des numéros d'identifiants uniques, donc je préfère définir une méthode qui pourra clairement être suivie par tout le monde par la suite.

[AntoineAugusti]

La création d'un identifiant unique pour une commune ne devrait pas être un problème car c'est une séquence croissante d'entiers. Dans une base de données classique ou dans un tableur, c'est simplement à maintenir : ça correspond au numéro de ligne. La présence d'un identifiant unique bénéficie au PAN et à la commune pour ses besoins.

Pour arriver à l'identifiant unique, si la commune est en charge de ça, il suffit de rajouter le préfixe INSEE-P.

[be-mercier]

J'ai l'impression d'avoir du mal à exprimer la difficulté que je rencontre.

L'identifiant unique ne correspond pas au numéro de ligne dans des cas où ce sont les opérateurs qui publient les données, car leurs parkings peuvent être présents dans plusieurs communes avec plusieurs code INSEE différents.
Si la commune se charge de créer l'identifiant unique à partir du numéro de ligne dans son tableur, on se retrouve avec une liste d'identifiants qui ressemble à la suivante : 75101-P-001, 75105-P-002, 75107-P-003, 75109-P-004, 78146-P-005
(où il existe un identifiant 75109-P-004 mais pas d'identifiant 75109-P-001).

[NicolasBerthelot]

Salut tout le monde,

Concernant l'identifiant unique, il semble pertinent que l'on puisse conserver et diffuser les identifiants utilisés par la source de données plutôt que de les écraser par l'identifiant conforme à la PAN. Cela semble une solution adaptée car les producteurs ne sont pas nécessairement disposés à remplacer l'identifiant qu'ils utilisent pour leur point de stationnement par la norme CodeInsee-P-XXX. Cela est d'autant plus intéressant que cela permettra aux réutilisateurs de faire le lien avec d'autres données diffusées dans la source qui ne sont pas incluses dans le schéma national.
Je propose donc qu'on ajoute au schéma deux champs non obligatoires :

• id_source : identifiant du parking dans la source
• uri_source : identifiant du jeu de données source utilisé (url du dataset)

Qu'en pensez-vous ?