Le portail francophone de la géomatique

Bonjour,

sur le principe, en cas de besoins à enrichir le standard voila la philosophie adoptée :
- Pour les domaines de valeurs (ex : matériau), création d'un domaine maison avec table de correspondance vers les types énumérés du standard.
De notre côté, les tests de migration des données des concessionnaires au strict standard provoquaient un volume inconsidéré d’attributs avec une valeur reclassée à "autre".

- Pour les attributs, 2 options :
* soient les attributs nécessaires à créer ont un sens commun à tous les objets de la classe métier, dans ce cas, on ajoute un attribut à la classe du modèle du standard
* soient les attributs nécessaires à créer ont un sens spécifique à certains objets de la classe métier du standard, et dans ce cas, on créé une sous-classe spécialisée

Pour les échanges, sur le principe on demande les fichiers au standard RAEPA tels que et bruts  (+ des ajouts locaux pour éviter une perte sèche d'info à la collectivité et surlesquels on va travailler prochainement).
Pour les usages internes des services, on travaille en revanche à rendre la donnée compréhensible en substituant (présentation) les codes des types énumérés par les libellés explicites.

Cordialement

Dernière modification par florent vanhoutte (Thu 23 January 2020 13:51)

Dans l'exemple cité, on appliquerait la méthode évoquée comme suit :
* ajout d'un attribut code local dans le domaine de valeur de type d'appareillage
* ajout dans ce code local d'une valeur appropriée pour désigné un coude
* création d'une sous classe "coude" comme une spécialisation de l'appareillage avec un attribut dédié permettant d'identifier le type de coude

en PJ un schéma de principe de notre approche.

Cordialement