Skip to content
Pre-release

@zzzef zzzef released this Nov 2, 2018 · 13 commits to master since this release

v2.0.2-beta1

Synthèse des principales évolutions v2.0.2-beta1

  • 158 propositions d'évolutions soumises à consultation : 94 ajouts (add:) / 41 changements (chg:) / 23 corrections (fix:).
  • Correction d'anomalies dans les codes couleur FOTAG. Si vous avez des numéros de couleur de fibres entre 1.1 et 1.12, prenez contact sur Redmine.
  • Introduction des fiches de cas d'usage (travaux conjoints avec les opérateurs et InfraNum) et traduction dans le MCD (ajouts d'attributs, précision de définitions, nouvelles valeurs et surtout de nombreuses nouvelles contraintes dans la grille de contraintes) pour homogénéiser les modélisations et faciliter l'industrialisation des échanges :
    • Habitat collectif avec PBI (Homogénéisation des règles d'instanciation).
    • SRO en armoire de rue, SRO colocalisés, NRO avec fermes optiques.
    • Types d'usages des réseaux fibres : Typage et comptage plus détaillé selon les types de logements et les types de raccordements (FTTE, GFU, etc.).
  • Meilleure compatibilité avec les protocoles Interop v3.
  • A la demande générale des opérateurs et d'InfraNum, la table t_adresse est vouée à ne plus accueillir que des sites clients FTTH. Les tables t_organisme, t_sitetech, t_ptech et t_siteemission portent des attributs d'adressage postal et cadastral directement (t_organisme) ou en tables de patch (en attendant une intégration définitive en v2.1). Les attributs permettant des relations vers t_adresse autres que sf_ad_code sont toujours présents mais sont déclarés obsolètes, c'est notamment le cas de zs_ad_code. L'attribut nd_voie est également déclaré obsolète afin de ne plus disposer que d'une source possible d'adressage pour un objet.
  • Il ne devrait plus y avoir de contraintes présentes dans le géostandard ANT qui ne soient présentes dans GraceTHD-MCD.
  • Une nouvelle partie a été intégrée pour présenter les problématiques de nomenclatures internes (identifiants, étiquetage, niveaux de référenement, codes d'organismes et de références, gestion documentaire, règles de remplissage, grille de contrainte, fiches de cas d'usage) qui pouvaient être exclusivement abordées dans le Géostandard ANT ou dans des projets annexes (GraceTHD-MOD, GraceTHD-Data, etc.).
  • Nombreuses corrections et précisions de définitions.
  • Quelques attributs déclarés obsolètes.
  • Ajouts de valeurs dans certaines listes.
  • Une colonne "v2.0.2" a été ajoutée aux tableaux de GraceTHD-MCD pour simplifier l'identification des modifications directes du MCD. Attention, la consultation du changelog (.\docs\GraceTHD-MCD\gracethdmcd_changelog.txt) reste nécessaire pour identifier le détail de toutes les évolutions.
  • Les points d'évolution un moment envisagés pour la v2.0.2 non retenus ou reportés à la v2.1.0 sont consultables sur cette page :

Détail des correctifs et évolutions :

Arborescence :

  • chg: .\sources\gracethd-mcd-v2.0.2_source_r01.ods : ajout de "_source_r01".
  • add: .\docs\GraceTHD-MCD\gracethdmcd_usecase_modelisation_habitat_collectif_v0.06.pdf : fiche de cas d'usage en phase finale de validation.
  • add: .\docs\GraceTHD-MCD\gracethdmcd_usecase_modelisation_nro_ferme_v0.02.pdf : fiche de cas d'usage en phase finale de validation.
  • add: .\docs\GraceTHD-MCD\gracethdmcd_usecase_modelisation_sro_armoire_v0.05.pdf : fiche de cas d'usage en phase finale de validation.
  • add: .\docs\GraceTHD-MCD\gracethdmcd_usecase_modelisation_sro_colocalises_v0.02.pdf : fiche de cas d'usage en cours de rédaction jointe pour illustrer certaines propositions d'évolutions.
  • add: .\docs\GraceTHD-MCD\gracethdmcd_usecase_modelisation_types_usages_fibre_v0.05.pdf
    fiche de cas d'usage en cours de rédaction jointe pour illustrer certaines propositions d'évolutions.
  • add: .\sql_postgis\gracethd_00_init.sql : exemples de commandes de création de la base, du schéma et d'extension PostGIS.

Docs :

  • chg: gracethd-mcd-v2.0.2_doc* : ajout de notes pour exploiter le journal des révisions (changelog), amélioration du préambule, etc.
  • add: gracethd-mcd-v2.0.2_doc* : ajout d'une colonne v2.0.2 sur les différentes grilles pour stocker les modifs.
  • chg: gracethd-mcd-v2.0.2_doc*/Grille de remplissage : suppression des colonnes "Concerné" et "Selon grille de remplissage".
  • chg: gracethd-mcd-v2.0.2_doc* : précision si "obligatoire" ou "obligatoire (clé primaire)"
  • add: gracethd-mcd-v2.0.2_doc*/MCD_Nomenclatures : description des nomenclatures internes à GraceTHD (identifiants, étiquetage, niveaux de référencement, codes d'organismes et de références, gestion documentaire, règles de remplissage, fiches de cas d'usage). (demande #229)
  • add: gracethd-mcd-v2.0.2_doc*/MCD_Systemes_Reference : ajout d'une copie du tableau des systèmes de référence (systèmes de coordonnées cartographiques et unités) du Géostandard ANT de sortes que GraceTHD-MCD puisse être autonome.
  • add: gracethd-mcd-v2.0.2_doc*/MCD_Contraintes : ajout des parties du géostandard ANT en relation avec les contraintes.

Listes :

  • add: l_bool : ajout de cette nouvelle liste pour t_adresse_patch202.ad_sracdem
    et t_adresse_patch202.ad_dta + préparation d'une substitution future des types BOOLEAN.
  • add: l_position_usetype : ajout de cette nouvelle liste en v2.0.2 pour t_position_patch202.ps_usetype [CCO | GEFO | demande #338]
  • add: l_ltech_typephy : ajout de cette nouvelle liste en v2.0.2 pour t_ltech_patch202.lt_typephy [CCO]

Valeurs :

  • add: l_adresse_etat : ajout 'RD' - 'raccordable demande' [Interop.EtatImmeuble].
  • chg: l_adresse_etat : intégration des définitions interop pour ces codes. [Interop.EtatImmeuble]
  • add: l_avancement : ajout 'P', 'PRE-ETUDE', 'Modelisation temporaire dans l attente d'une etude detaillee.'. [CCO].
  • chg: l_bp_typelog : ajout 'BPI' [demande #406 | CCO 13/09/2018].
  • chg: l_bp_typephy : ajout 'BP864' [demande #183].
  • add: l_bool : ajout '0','FAUX' / '1','VRAI' (nouvelle liste).
  • chg: l_doc_type : ajout des définitions (parfois résumées) de MOD_DescriptionDocuments de GraceTHD-MOD.
  • fix: l_fo_color : les codes couleur FOTAG (1.1 à 1.12) étaient manquants dans la liste sur le géostandard. [demande #391]
  • chg: l_infra_nature : 'ELE' : ajout de définition. 'Infrastracture d energie electrique indiferienciee.' [demandes #140 #460 | CCO 16/10/2018]
  • add: l_infra_nature : ajouts 'EBT','ELECTRICITE BASSE TENSION' / 'HTA','ELECTRICITE HAUTE TENSION CATEGORIE A' / 'HTB','ELECTRICITE HAUTE TENSION CATEGORIE B'. [demandes #140 #460 | CCO 16/10/2018]
  • add: l_ltech_typephy : ajout 'P','PHYSIQUE','Local cloisonné dédié à un usage technique' / 'F','FONCTIONNEL','Espace défini pour un usage technique spécifique mais qui n'est pas physiquement un local cloisonné.' (nouvelle liste). [CCO]
  • chg: l_noeud_type : ajout de définition pour les valeurs SC, PC, EC (demande #453).
  • add: l_position_usetype : ajout 'R','FTTH' / 'P','FTTH PRO' / 'E','FTTE' / 'U','GFU' / 'O','FTTO' / 'N','FON' (nouvelle liste). [CCO]
  • add: l_ptech_nature : ajout poteau composite PCMP.
  • fix: l_ptech_nature : faute d'orthographe pour la définition de Y.
  • chg: l_reference_type : remplacement libellé 'BPE' par 'ELEMENT BRANCHEMENT PASSIF' [Demande #179 #249]
  • add: l_reference_type : ajout 'ST' [Demande #179 #249]
  • add: l_site_type_log : ajout 'SROS' et 'FTTH' [CCO]
  • add: l_site_typephy : ajout 'CHAMBRE VISITABLE' et 'CONSTRUCTION SOUTERRAINE'. [demande #444]
  • fix: l_statut : définition REC - caractère ; supprimé. [Demande #366]
  • add: l_suf_racco : ajout 'RD' - 'raccordable demande' [Interop.EtatImmeuble].
  • add: l_suf_type : ajout 'E' : 'Entreprise' [CCO | GEFO]
  • add: l_suf_type : ajout 'U' : 'GFU' [CCO | GEFO]
  • chg: l_suf_type : 'O' : ajout de définition [CCO]
  • chg: l_suf_type : 'T' : ajout de définition [CCO]
  • fix: l_tube : 1.12 - correction définition.
  • fix: l_tube : 1.28, 1.40, 1.52, 1.64 : correction libellé.
  • chg: l_zone_densite : 1, ZTD Haute Densité [Interop | demande #187]

Attributs t_adresse :

  • fix: ad_nbprhab : "Nombre de prises ..." remplacé par "Nombre de fibres..."
  • fix: ad_nbprpro : "Nombre de prises ..." remplacé par "Nombre de fibres..."
  • fix: ad_gest : ajouter à la définition "S’il s’agit d’une personne morale, saisir le or_code et saisir toutes les informations nécessaires pour les coordonnées dans la table t_organisme" [Interop v3]
  • fix: ad_x_ban : "lambert 93" remplacé par "système de coordonnées cartographique de référence" [demande #190]
  • fix: ad_y_ban : "lambert 93" remplacé par "système de coordonnées cartographique de référence" [demande #190]
  • fix: ad_x_parc : "lambert 93" remplacé par "système de coordonnées cartographique de référence" [demande #190]
  • fix: ad_y_parc : "lambert 93" remplacé par "système de coordonnées cartographique de référence" [demande #190]
  • chg: ad_batcode : modification de définition pour adapter aux usages constatés : Identifiant immeuble unique et pérenne propre à l'OI (Interop:IdentifiantImmeuble) [Interop | demande #279 | CCO NOK avec ajout ad_idimm | Copiltech 06/10/18 OK changement de définition ad_batcode].

Attributs t_organisme :

  • chg: or_ad_code : obsolète [CopilTech 06/10/18 | CCO 16/10/18]

Attributs t_noeud :

  • chg: nd_voie : obsolète. Utiliser les attributs d'adressage postal et cadastral ajoutés en tables de patch (t_sitetech_patch202, t_ptech_patch202, t_siteemission_patch202) [CCO | CopilTech].

Attributs - t_znro :

  • fix: zn_etatlpm : obsolète [CopilTech 06/10/18 pas de remplacement par zs_znletat].
  • fix: zn_datelpm : obsolète [CopilTech 06/10/18 pas de remplacement par zs_znldate].

Attributs - t_zsro :

  • fix: zs_accgest : obsolète. Doublon de ad_iaccgst [Interop | demande #151].
  • chg: zs_ad_code : obsolète. Utiliser les attributs d'adressage des sites techniques ajoutés via t_sitetech_patch202.
  • chg: zs_zn_code : contrainte sur l'attribut passé à obligatoire planifié pour 2.1.0.

Attributs - t_zpbo :

  • chg: zp_zs_code : contrainte sur l'attribut passé à obligatoire planifié pour 2.1.0.

Attributs - t_sitetech :

  • chg: st_ad_code : obsolète. Les attributs d'adressage postal et cadastral sont portés directement sur la table via t_sitetech_patch202 [CCO | CopilTech].
  • chg: st_nblignes : ajout à la définition. "Attribut de regroupement permettant de stocker le nombre total de lignes gérées sur ce site technique (dans le cas notamment d'un NRO, d'un SRO, …). Le réglementaire attribuant un code par PTO, il y a autant de lignes que de PTO. En cas de colocalisation de SRO au NRO utiliser le total du NRO. En cas de colocalisation de SRO, utiliser le total des SRO." [demande #268]

Attributs - t_ltech :

  • fix: lt_etat : suppression NOT NULL [demande #441]
  • fix: lt_etiquet : VARCHAR(20) au lieu de VARCHAR(254) [demande #419]

Attributs - t_baie :

  • fix: ba_prop : correction de la définition qui parlait de tiroir.

Attributs - t_tiroir :

  • chg: ti_placemt : ajout à la définition "Si le tiroir du bas mesure 2U sa position sera 1". [demande #385]

Attributs - t_ptech :

  • chg: pt_ad_code : OBSOLETE. Les attributs d'adressage postal et cadastral sont portés directement sur la table via t_ptech_patch202 [CCO | CopilTech].
  • chg: pt_a_strat : ajout dans la définition du nom de l'attribut du PIT correspondant (STRATEGIQU) [demande #73 | GE].

Attributs - t_ebp :

  • fix: bp_linecod : redimensionnement VARCHAR(30) + modification de la définition pour prise en compte de nomenclatures antérieures à celle du régulateur. [Axione | CCO 02/10/2018 | CopilTech 06/10/18].
  • chg: bp_ca_nb : précision de la définition. "Tous les plateaux physiques doivent être comptabilisée. Les plateaux de lovage doivent donc être comptabilisés." [demande #388]

Attributs - t_cassette :

  • chg: t_cassette : modification de la définition pour traiter des modules et plateaux de têtes optiques.
  • chg: cs_nb_pas : précision définition : "Taille de la cassette en nombre de pas lorsqu'elle est placée dans un BPE (épaisseur dans l'organiseur)."
  • chg: cs_num : modification de la définition pour prendre en compte les notions de module et de tête de câble.

Attributs - t_cheminement :

  • chg: cm_nd1 et cm_nd2 : précision de la définition pour spécifier de ne pas prendre en compte les noeuds de type SP (spécifique). nd_type='SP' cassent la possibilité de générer les "itinéraires", "fourreaux", etc.

Attributs - t_cable :

  • chg: cb_fo_util : précision définition : 'Fibres en continuité optique qui disposent d'une assignation spécifique (un local à desservir ou une réserve). Ex : 1fo/SUF + 20% réserve réglementaire.' [demande #242 | InfraNum | CCO]
  • chg: cb_fo_disp : précision définition : 'Fibres en continuité optique qui n'ont pas d'assignation spécifique. L'application de la règle d'épissurage au module ou demi-module génére des FO raccordées jusqu'au SRO sans assignation spécifique. Exemple : 3 Locaux résidentiels à raccorder au PB (3 FO) + 20 % de réserve au PBO (1 FO). Soudure en continuité au module jusqu'au PM : FO utiles (3 FO Locaux + 1 FO réserve) et FO disponible (6 FO du module - 4 FO assignées). Réserve de manœuvre (FO non connectorisée au PM) = cb_capafo – cb_fo_util – cb_fo_disp.' [demande #242 | InfraNum | CCO]

Attributs - t_position :

  • chg: ps_1 : ajout à la définition : "Dans le cas d’un réseau FTTH (donc non maillé) les fibres seront alignées de ps_1 vers ps_2 dans le sens NRO vers PTO." [demande #398 / CCO]
  • chg: ps_2 : ajout à la définition : "Dans le cas d’un réseau FTTH (donc non maillé) les fibres seront alignées de ps_1 vers ps_2 dans le sens NRO vers PTO." [demande #398 / CCO)]
  • chg: ps_cs_code : ajout à la définitino : "Si les fibres sont lovées en fond de boîte, saisir le code de la cassette qui sera numérotée 0 dans l’attribut cs_num." [demande #357 | GEFO | CCO 02/10/18]

Attributs - t_ropt :

  • fix: rt_fo_code : prise en compte du NOT NULL (problème de prise en compte dans le fichier de développement source) puisque attribut obligatoire. [demande #206].

Attributs - t_siteemission :

  • chg: se_etat : suppression NOT NULL [demande #441].
  • chg: se_ad_code : obsolète. Les attributs d'adressage postal et cadastral sont portés sur la table via t_siteemission_patch202 [CCO | CopilTech].

Attributs patch202 - t_cassette_patch201 :

  • fix: cs_ti_code : OBSOLETE. [demandes #37 #270 #401 | CCO].

Attributs patch202 - t_adresse patch202 :
ajout attributs pour FTTE, etc. [CCO | GEFO | demandes #250 #338 #345]

  • add: ad_nblpub : locaux exploités par des services publics.
  • add: ad_nbltec : locaux exploités exclusivement pour des usages techniques.
  • add: ad_nblope : locaux exploités exclusivement pour des usages d'opérateurs télécoms.
  • add: ad_nbprtte : nombre de fibres FTTE (Fibre activée en point-à-point sur la Boucle Locale Optique Mutualisée).
  • add: ad_nbprgfu : nombre de fibres GFU (Groupement Fermé D'Utilisateurs tel que défini par la décision ARCEP n°05 0208).
  • add: ad_nbprtto : nombre de fibres FTTO (Offre Sur Mesure sans modalités de raccordement réglementé).
  • add: ad_nbprfon : nombre de fibres noires (Location unitaire d'une ou plusieurs fibres sans offre activée).
  • add: ad_sracdem : 'SusceptibleRaccordableDemande' [Interop:SusceptibleRaccordableDemande | CCO OK]
  • add: ad_dta : ajout pour déterminer si un bâtiment a besoin d'un diagnostic technique amiante (DTA). [GEFO | CCO 16/10/18]

Attributs patch202 - t_znro_patch202 :

  • add: zn_lt_code : pour distinguer le local technique fonctionnel NRO [CCO | usecase SRO colocalisé].

Attributs patch202 - t_zsro_patch202 :

  • add: zs_lt_code : notion de local technique fonctionnel SRO. [CCO | usecase SRO colocalisé].
  • add: zs_lgmaxln : Longueur maximale des lignes situées dans la zone arrière du PM.
    Elle est exprimée en kilomètres avec avec 2 chiffres après la virgule (Interop:LongueurMaxLignes) [Interop | CCO].

Attributs patch202 - t_sitetech_patch202 :

  • add: st_rf_code : ajout. Si le site technique est un équipement télécom sur catalogue (shelter, armoire de rue), code de la référence dans la table t_reference. [demandes #179 #249]
  • add: st_ban_id, st_nomvoie, st_numero, st_rep, st_postal, st_insee, st_commune : Pour rendre st_ad_code obsolète [CCO | CopilTech].

Attributs patch202 - t_ltech_patch202 :

  • add: lt_nom : si besoin. Permet de clarifier l'usage d'un local fonctionnel notamment [CCO].
  • add: lt_typephy : type physique de local technique. REFERENCES l_ltech_typephy(code) [CCO].

Attributs patch202 - t_equipement_patch202

  • add: eq_nom VARCHAR(100) : nom de l'équipement [GEFO 19/10/2016].
  • add: eq_desc VARCHAR(254): description de l'équipement [GEFO 19/10/2016].
  • add: eq_etat : ajout [demande #241]
  • add: eq_taille : ajout [demande #241]
  • add: eq_placemt : ajout [demande #241]
  • add: eq_localis : ajout [demande #241]

Attributs patch202 - t_ptech_patch202 :

  • add: pt_codepro : Code de l’objet dans le Système d’Information du propriétaire de l’objet. A renseigner si celui-ci fournit l’information. [GE | demande #300 | CCO 16/10/18]
  • add: pt_codegst : Code de l’objet dans le Système d’Information du gestionnaire de l’objet. A renseigner si celui-ci fournit l’information. [GE | demande #300 | CCO 16/10/18]
  • add: pt_nomvoie, pt_numero, pt_rep, pt_local, pt_postal, pt_insee, pt_commune, pt_section, pt_idpar : Pour rendre pt_ad_code obsolète [CCO | CopilTech].

Attributs patch202 - t_position_patch202 :

  • add: ps_nom [CCO | GEFO | demande #260]
  • add: ps_lin [CCO | GEFO | demande #260]
  • add: ps_col [CCO | GEFO | demande #260]
  • add: ps_usetype REFERENCES l_position_usetype(code) : ajout [CCO FTTE | demande #338].

Attributs patch202 - t_siteemission_patch202 :

  • add: se_ban_id, se_nomvoie, se_numero, se_rep, se_local, se_postal, se_insee, se_commune : Pour rendre se_ad_code obsolète [CCO | CopilTech].

Contraintes générales :

  • chg: co_1_r00001 : reprise de la définition.
  • add: co_1_g00005 : obsolète.
  • add: co_1_s00011 : Tous caractères non visibles autres que espace ne doivent être saisis dans aucune valeur. C'est notamment le cas des caractères de retour à la ligne (CR ou CRLF) : les valeurs GraceTHD ne sont donc pas multilignes. [demande #236]
  • add: co_1_s00012 : Les attributs nommés sur le modèle xx_abddate indiquent la date d’abandon (fin de validité) de l’objet dans le S.I. Des objets supprimés ne doivent donc pas être supprimés, mais doivent être communiqués comme abandonnés via la date d’abandon et une cause stipulée dans les attributs nommés sur le modèle xx_abdsrc.
  • add: co_1_g00008 : Une zone arrière de PBO est intégralement contenue dans une zonde arrière de SRO et une seule.
  • add: co_1_g00009 : Les objets de la classe fibre (t_fibre) si elle est rendue géométrique partagent leur géométrie avec ceux la classe câble (t_cableline).
  • add: co_1_g00010 : Les objets de la classe ElementBranchementPassif (t_ebp) si elle est rendue géométrique partagent leur géométrie avec ceux de la classe Noeud (t_noeud) auxquels correspondent les points techniques, les sites d’émission, les sites techniques et les sites utilisateur final.
  • add: co_1_g00011 : La topologie associée aux nœuds et aux cheminements doit constituer un graphe planaire non strict (c’est à dire autorisant les intersections). Les intersections de cheminements sans interconnexion sur le terrain ne sont pas modélisées par un nœud. Des infrastructures différentes (GC/égout, GC/aérien, etc.) sont modélisées par des cheminements qui peuvent occasionnellement se superposer partiellement.
  • add: co_1_g00012 : Les divergences de cheminements sans point technique physique (c’est à dire un Y) doivent être modélisées par un nœud de type « DISJONCTION ».
  • add: co_1_g00013 : Les objets géographiques ponctuels de type Noeud et linéaires (Câbles, cheminements) doivent constituer un réseau topologique.
  • add: co_1_g00014 : En aucun cas des nœuds peuvent être superposés.
  • add: co_1_g00015 : Toute géométrie de câble (table t_cableline) doit être accompagnée de son équivalent décrivant le cheminement (t_cheminement), sauf si l’intégralité des cheminements. Une tolérance de précision spatiale pour la correspondance entre les deux classes d’objets peut être précisée mais ne doit pas . Concrètement, il est techniquement à la fois possible de stocker dans GraceTHD des câbles calés sur les géométries des cheminements avec une tolérance d'écart très faible, tout comme il est possible de tolérer des géométries de câbles avec un certain écart pour simplifier le travail d'ingénierie optique. Les extrémités des câbles et des cheminements doivent être cohérentes (même noeud). Enfin un câble n'a pas obligatoirement la même géométrie qu'un cheminement (plus morcelé, courbes différentes, imprécisions des formats, ...), donc une tolérance est une approche nécessaire.
  • add: co_1_g00016 : Les câbles sont modélisés avec les lignes simples. Un câble à tubes dérivables cartographié sera donc modélisé avec autant d’entrées dans t_cableline que de tronçons dérivés.
  • add: co_1_g00017 : Des câbles dans un même cheminement ne peuvent partager une seule et même entrée dans t_cableline. Chaque câble cartographié dispose de sa propre entrée dans t_cableline.
  • add: co_1_g00018 : Un suf est localisé par la géométrie de t_noeud qui lui correspond. Un suf doit obligatoirement avoir un noeud. Un noeud peut localiser plusieurs suf en habitat collectif. Le noeud sera généralement positionné au centroïde du bâtiment. Tout dépend de ce que les utilisateurs choisiront de définir comme adresse (ensemble immobilier, bâtiment, entrée, ...). Théoriquement la position du noeud devrait être la même que la géométrie de l'adresse qui sera considérée comme la meilleure position de l'adresse à l'instant T.

Contraintes issues travaux cas d'usage SRO en armoire de rue :

  • add: co_1_g00007 : Les géométries des zones arrières de SRO ne peuvent se superposer, sauf s’il s’agit de multiples SRO localisés dans un même habitat collectif et modélisés sur un même site technique (plusieurs PM techniques dans les étages), donc en relation avec un même noeud. t_zsro
  • add: co_1_m00020 : L’attribut zs_lt_code (t_zsro_patch202) doit obligatoirement être saisi. Ceci permet de notamment de ne pas utiliser zs_ad_code mais les attributs d’adressage de t_sitetech (t_sitetech_patch202). t_zsro
  • add: co_1_m00014 : Le positionnement des équipements et tiroirs dans une baie se faisant de bas en haut, il n’est pas possible de les positionner sur plusieurs colonnes. Une armoire de rue est donc modélisée par autant de baies qu’elle a de compartiments. Une ferme optique est donc modélisée par autant de baies qu’elle a de verticales. t_baie [demande #386]
  • add: co_1_m00015 : Les baies d’un site technique peuvent être dans un ou plusieurs locaux techniques. S’il n’y a pas d’accès différenciés (armoire multi-opérateurs) selon les compartiments, un seul local technique suffit. t_baie
  • add: co_1_m00021 : Un site technique est composé de un ou plusieurs locaux techniques. Des locaux techniques d’un site technique ne peuvent être modélisés avec plusieurs sites techniques. C’est le cas également pour une armoire de rue qui peut être constituée de plusieurs locaux, mais un seul site techniques. t_ltech
  • add: co_1_m00016 : Les tiroirs optiques (ou têtes optiques) accueillent autant de cassettes que de modules (ou plateaux de têtes optiques). Toutes les cassettes doivent être modélisées. t_cassette
  • add: co_1_m00017 : La relation entre cassettes et tiroirs (ou modules et têtes de câbles) se fait par les positions avec les attributs ps_ti_code et ps_cs_code. Donc toute création de tiroir nécessite de modéliser les cassettes et les positions. t_position
  • add: co_1_m00018 : Qu’il s’agisse d’un élément de branchement passif (table t_ebp) ou d’un tiroir optique (table t_tiroir), toutes les positions doivent être modélisées, même si elles n’ont pas d’affectation. t_position [demandes #263 #354 #416]

Contraintes issues travaux cas d'usage NRO avec ferme optique :

  • add: co_1_m00019 : Lorsque le maître d’ouvrage est propriétaire d’un site technique et que ce dernier n’est pas sur le domaine public, alors les informations cadastrales doivent être renseignées dans la table t_adresse. t_adresse

Contraintes issues travaux cas d'usage habitat collectif :

  • chg: co_1_m00006 : ajout de précision pour les PBI.
  • add: co_1_m00007 : Les éléments de branchement passif intérieurs (PBO Immeuble ou BPI) sont placés dans un local technique (attribut bp_lt_code). Pour les petits immeubles dont les éléments de branchement passifs ne sont que des PTO/DTIO, il n'est pas utile de modéliser un site technique, le ou les SUF suffisent. t_ebp
  • add: co_1_m00008 : Un PBO extrasite est modélisé par un élément de branchement passif (t_ebp) placé dans un point technique (attribut bp_pt_code). t_ebp
  • add: co_1_m00009 : Une PTO est modélisée par un élément de branchement passif (t_ebp) placé dans un SUF (attribut bp_sf_code). t_ebp
  • add: co_1_m00010 : Un élément de branchement passif (t_ebp) doit obligatoirement avoir 1 des 3 attributs suivants renseigné (bp_pt_code, bp_lt_code, bp_sf_code). t_ebp
  • add: co_1_m00022 (ancien code temporaire : co_1_s00007) : Les SUF (Sites Utilisateurs Finaux - logements) d’un habitat collectif raccordé en FTTH ayant au moins un PBI (ou un PMI) sont associés au même nœud (sf_nd_code) que le site technique (st_nd_code) qui accueille le ou les PBI (ou PMI) qui raccordent ces SUF. t_suf
  • add: co_1_m00023 (ancien code temporaire : co_1_s00008) : Les SUF d’un habitat collectif FTTH ayant au moins un PBI (ou un PMI) sont associés à la même adresse (sf_ad_code) que le site technique (st_ad_code) qui accueille le ou les PBI (ou PMI). t_suf
  • add: co_1_m00011 : Une adresse correspondant à un immeuble raccordé en FTTH ayant au moins un PBI (ou un PMI) peut être modélisé par un ou plusieurs sites techniques si les colonnes montantes n’ont aucune interconnexion présente ou potentielle. t_sitetech
  • add: co_1_s00009 : Les sites techniques de type physique ‘BATIMENT’ ont obligatoirement une adresse postale (st_ad_code IS NOT NULL). t_sitetech
  • add: co_1_s00010 : Si nd_type = ‘SH’ alors st_typelog = ‘FTTH’ (à partir de la version 2.0.2). t_sitetech
  • add: co_1_m00012 : Un local technique ayant un attribut étage (lt_etage à partir de la v2.0.1), il ne peut couvrir plusieurs étages. Dans le cas d’équipements installés dans une colonne montante, il faut autant de locaux techniques que d’étages accueillant un équipement. lt_local et lt_etiquet peuvent indiquer que c’est une seule et même colonne montante. t_ltech
  • add: co_1_g00006 : Les géométries des zones arrières de PBO ne peuvent se superposer, sauf s’il s’agit de PBO modélisés sur un même noeud (plusieurs PBI dans les étages, plusieurs PBO dans une chambre, ...). t_zpbo
  • add: co_1_m00024 : L’attribut zp_bp_code doit être renseigné. t_zpbo*
  • add: co_1_m00013 : Si une adresse de t_adresse correspond à une adresse raccordée ou potentiellement à raccorder, alors ad_ietat ne peut avoir la valeur NULL. t_adresse
  • add: co_1_m00006 : Une zone arrière de PBO est en relation avec un nœud. Dans le cas de PBO Immeuble d'une même colonne montante, ils partagent le même noeud.

Vues :

  • fix: vues existantes mais non documentées dans la version précédente : vs_elem_bp_lt_st_nd + vs_elem_cs_bp_lt_st_nd [demande #104]

Fichier de développement (Source) :

  • add: gracethd-mcd-v2.0.2_source_r01.ods : ajout d'une colonne v2.0.2 sur les différentes grilles pour stocker les modifs.
  • chg: gracethd-mcd-v2.0.2_source_r01.ods : nettoyages et restructurations multiples pour faciliter notamment la production du fichier de documentation.
  • fix: gracethd-mcd-v2.0.2_source_r01.ods : correction du calcul de code SQL pour les codes FOTAG dans l_fo_color (MCD_Valeurs - colonne L). [demande #391]

Spatialite :

  • chg: gracethd-spatialite.qgs : mis à jour.
Assets 2
You can’t perform that action at this time.