Revue des patterns pour les endpoints géo

[ChristopheYon]

Outre ceux des régions et des cantons-et-villes qui filtre des codes valides, on pourrait réaligner certains pattern.

• Certains pattern commencent par ^ et finissent par $ mais ce n'est pas le cas pour la plupart : ça veut dire qu'on ne filtre pas vraiment (par exemple mettre 01002ABCD pour /geo/commune/{code} ne renvoie pas d'erreur 400 parce que le pattern est respecté (avec 01002), même s'il y a des trucs après
• Il n'y a actuellement pas de commune déléguée en Corse. Mais ça pourrait venir. Et de toute façon, si un utilisateur demande un code de commune corse, on doit lui répondre qu'elle n'existe pas (404) et pas que se demande est incorrecte (400). Donc il faudrait mettre pour les communes déléguées le même pattern que pour les communes ^[0-9][0-9AB][0-9]{3}$.
• De même pour les communes associées (à la différence qu'on ne va pas en créer de nouvelle).
• Il y a un certain nombre de pattern [a-zA-Z0-9]{n}. Pourtant les lettres dans les codes sont en majuscules et on tient bien compte de la casse (/geo/bassinDeVie2022/2a247 renvoie une erreur 404 alors que /geo/bassinDeVie2022/2A247 renvoie bien le bassin de vie de Porto-Vecchio). Donc je propose pour ces cas :
  • Aire d'attraction des villes 2020 : ^[0-9A-Z]{3}$
  • Arrondissement (sur le modèle des communes) : ^[0-9][0-9AB][0-9]{1,2}$
  • Arrondissement municipal : ^(132|693|751)[0-9]{2}$
  • Bassin de vie 2022 (ce sont des codes de communes) : ^[0-9][0-9AB][0-9]{3}$
  • Circonscription territoriales (idem) : ^[0-9][0-9AB][0-9]{3}$
  • Collectivité d'outre-mer : ^9[78][0-9]$
• Certains noms de zonages comportent un millésime (unité urbaine 2020, zone d'emploi 2020, aire d'attraction des villes 2020, bassin de vie 2022, quartier prioritaire de la politique de la ville 2024 au moins). Il faudrait garder partout le millésime dans le nom (court ou long) : nos futurs collègues qui auront à créer les unités urbaines 2030 et autres nous remercieront.

[GtanSndil]

1/ OpenAPI valide la chaîne entière par défaut, même si on n'a pas mis explicitement ^ et $. En l'occurence, j'ai vérifié sur /geo/commune/01002ABCD, j'ai une erreur 400 avec "message": "Donnée invalide : getcogcom.arg0: doit correspondre à "[0-9][0-9AB][0-9]{3}"". Mais tu as raison, je vais ajouter partout ^ et $ pour plus de lisibilité

[GtanSndil]

2/bien vu, c'est corrigé
3/ et 4/ fait
5/ tu parles de champs dans le fichier openapi.yaml ? Par exemples ici ?
CodeUniteUrbaine:
description: 'Code d''une unité urbaine' => 'Code d''une unité urbaine 2020
pattern: '^([0-9][0-9A-Z][0-9]{3})$'
type: string
xml:
attribute: true
example: '01121'

ou là :
UniteUrbaine2020:
allOf:
- $ref: '#/components/schemas/TerritoireBase_ChefLieu'
- type: object
xml:
name: UniteUrbaine
properties:
code:
$ref: '#/components/schemas/CodeUniteUrbaine'

[ChristopheYon]

Oui, c'est le dans le fichier openapi.yaml. Mais en fait, partout où on fait référence à ces zonages dans le code ou dans notre doc.

[GtanSndil]

Pour ce qui est du code, je vais faire les renommages avec les millesimes dans une autre carte : #412