| ArcMap<\/TD><\/TR><\/TBODY><\/TABLE><\/TD> | 26\/10\/16 Will : Un itinéraire unique avec un écart est une autre solution viable (en plus de la division en deux itinéraires) pour les itinéraires fish. R&H supporte actuellement les itinéraires Lollipop. Les itinéraires fish nécessitent un effort de développement important pour accommoder les différentes logiques et processus R&H. La FHWA a indiqué que les écarts le long des itinéraires ne sont pas acceptables pour HPMS.<\/P> Certaines DOT signalent des problèmes de mesure d'événements en utilisant la solution de l'itinéraire unique. Will est prêt à faire un suivi sur ces problèmes et pense que R&H devrait supporter.<\/P> Il existe actuellement un problème global incluant divers types d'itinéraires : Alpha, Loop, Branch, Fish, Lollipop, etc. \/ NC - R&H ne supporte pas les itinéraires fish. ADOT limite actuellement les bifurcations dans son système d'itinéraires. Il serait intéressé par un support natif de Roads and Highways car cela permettrait de modéliser certaines géométries d'itinéraires "réelles". D'après la documentation Agile : "La définition d'une bonne qualité inclut qu'il y aura un et un seul enregistrement par itinéraire, que les mesures des sommets augmenteront strictement avec la direction de numérisation (pour tous les LRM), qu'aucune mesure pour un itinéraire donné n'est ambiguë (pour tous les LRM), et que les règles de dominance des itinéraires sont en place et fonctionnent"<\/P><\/TD> | 16<\/TD> | Très élevé<\/TD> | Nécessite un support au niveau du code dans tous les niveaux du logiciel : édition d'itinéraire, calibration, édition d'événement,
RHUG : Priorité maximale parmi les LoE élevés pour la prochaine version. Devrait aussi être supporté au moins à la version 10.5 via un patch. Nécessaire pour répondre aux exigences FHWA HPMS et supporter l'intégration Agile.<\/P><\/TD><\/TR> |
| Comportement d'événement "Cover"<\/TD> | ArcMap<\/TD> | 26\/10\/16 - Le DOT de l'Idaho a souligné ce problème comme ayant un grand impact sur les processus QA/QC des événements. Les solutions existantes ne fonctionnent pas pour les événements externes et il y avait un consensus général que l'ajout du comportement "cover" serait un gain de temps pour gérer les événements continus.<\/P> Plusieurs DOTADOT - ce comportement "cover" devrait imiter étroitement le comportement déjà en place pour les réalignements cartographiques. MN : Quelle est votre définition de "cover" ? NC : Le comportement Move peut laisser de petits écarts alors qu'il devrait y avoir une couverture complète - Cover assurerait une couverture complète de l'événement après l'édition.<\/P><\/TD> | 11<\/TD> | Élevé<\/TD> | RHUG : Reste une priorité élevée pour les états qui implémentent. Souhaiterait inclure dans la prochaine version mais ne peut pas différer la correction des itinéraires alpha<\/TD><\/TR> ... (le reste du contenu vide ou non fourni reste inchangé) style="width: 11%;"><\/TD> | <\/TD> | <\/TD> | <\/TD> | <\/TD> | <\/TD><\/TR> |
