Validation NeTEx hors XSD

[thbar]

Je consigne ici des partages envoyés par @nlehuby (merci encore !).

Je ne sais pas où tout ça finira au bout du bout, sous sa forme finale ("profile as a code" dans le GT7 ? implémentation chez EnRoute ? etc) mais je veux éviter de perdre cet input utile.

J'avais noté au dernier GT7 que ton équipe était intéressée par des critères pour faire une validation NeTEx un peu plus intéressante que juste le XSD.

Voici ce qu'on utilise pour l'import NeTEx implémenté dans AccèsLibre Mobilités (concerne uniquement le sous-profil arrêts) :

Objets Quay :

• présence d'un mode de transport (Quay/TransportMode). C'est une contrainte du profil
• présence d'une position géographique (soit Quay/Polygon soit Quay/Centroid). Ce n'est pas une contrainte du profil, mais on ne peut pas utiliser l'objet pour notre cas d'usage si on ne sait pas où il est
• présence d'un nom ou d'un code (Quay/Name ou Quay/PublicCode). Idem, ce n'est pas obligatoire dans le profil, mais sans cette info, c'est peu utilisable

Objets StopPlace :

• présence d'un mode de transport (StopPlace/TransportMode). C'est une contrainte du profil
• on s'attend également à ce que le modèle de structuration des arrêts décrit dans le profil soit respecté, notamment le fait qu'un objet Quay ne peut avoir pour parent direct qu'un StopPlace monomodal.

Objets StopPlaceEntrance

• présence d'une position géographique. C'est là aussi une contrainte de notre cas d'usage

Puis:

J'en profite pour compléter la liste, avec un bug qu'on a constaté cette semaine :
Pour le mode de transport de l'arrêt (Quay/TransportMode), on s'attend à ce qu'il fasse partie de la liste énoncée dans le profil : https://normes.transport.data.gouv.fr/normes/netex/elements_communs/#les-modes
On a eu des cas d'arrêts qui avaient un autre mode de transport (valeur existante côté NeTEx mais pas reprise dans le profil)

---

Voir #4153

[ptitfred]

C'est précisément ce pour quoi les rulesets définissables par API sur Chouette seront utiles.