Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - DDEFF

Pages: [1] 2 3 ... 51
1
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juillet 10, 2024, 06:47:34 pm »
@ Pierre

Citer
Je préfère, et de loin, écrire et tester le gestionnaire en Processing.
Ah oui !!  ;D

2
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juillet 10, 2024, 04:40:51 pm »
Voilà la V11

@ Dominique,

J'ai tenu compte de tes remarques :

1°) Quand on modifie quelque chose, l'analyse est plus précise, propose plus de choix, eux-mêmes plus faciles.

2°) Le bouton "Annule" est maintenant efficace et on a plus de 'x' pour sortir.

3°) La recherche d'itinéraires donne les résultats dans une fenêtre (ou plusieurs, si c'est long) et on a plus les cote 0 et 1, mais A et B, comme sur les dessins des sections.
A est l'origine et B l'extrémité. C'est pareil que sur le schéma initial.

Il reste 2 choses importantes à faire :


1°) Gérer les zones multiples

2°) Ne plus sauver le fichier Zones, ce qui impose de récupérer les infos directement dans le JSON, comme Pierre le fait depuis longtemps. Et ça resservira dans le gestionnaire.

@ Pierre,

Si j'ai bien compris, tu vas mettre le gestionnaire sur un processeur en C++ et continuer à gérer le TCO en Processing.
Et échange des infos via un "tuyau" ?

A suivre
Denis  :P

3
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juillet 02, 2024, 11:08:12 am »
@ Dominique,

Je viens de sortir la V10 de mon programme qui tient compte des remarques de Pierre et les tiennes.
Il y a des points à éclaircir, visiblement.

Le but de ce programme est de créer un fichier JSON le plus petit possible tout en recueillant toutes les infos nécessaires à un gestionnaire. D'où quelques aller-retour avec Pierre sur les infos vraiment nécessaires et celle qui ne le sont pas.
Donc, le JSON qui était dans "Fichiers d'entrée Dominique" n'est pas le bon et, logiquement, je l'ai carrément supprimé.

Etape 1 : on fait un plan de réseau à la main avec des flèches pour connaitre le sens principal de circulation d'une section de voie.
Ton réseau a déjà été publié et je n'y reviens pas.
A ce moment, on n'a rien, aucun fichier, juste un dessin.

Etape 2 : on utilise mon éditeur graphique pour rentrer les infos descriptives du réseau en se conformant au dessin.
Petit à petit, un objet "Zone" se remplit avec toutes les infos qu'on a rentré.
En phase de développement, je sauve toutes les zones dans une table "Zones", mais elle disparaitra quand j'aurais terminé.
Il est quand même intéressant de comparer la table "Zones" dans les fichiers d'entrée et celle dans les fichiers de sortie.
On voit clairement que la table initiale est quasi vide car elle ne contient que les informations réellement rentrées par l'utilisateur.

Etape 3 : une fois que les infos manuelles sont rentrées, on appuie sur le bouton "Analyse" et, un peu plus d'une seconde après, toutes les cases nécessaires sont automatiquement remplies. La différence est assez impressionnante.

Etape 4 : En appuyant sur le bouton "Sauve", on sauve la table "Zones", celles des itinéraires, toutes choses nécessaires au développement, mais sans intérêt par la suite.
Et c'est aussi à cette étape qu'est généré le fichier JSON qui est, fondamentalement, un fichier texte, mais structuré.

Voyons maintenant tes questions :

J'ai fait un symbole "Butoir" à la place d'une flèche.

La Z26 n'est pas une TJD, mais est dessinée comme 2 aiguilles qui se suivent (il y a 2 moteurs). Il y a 2 versions : tripleG où la première aiguille est à gauche (Z29) et tripleD où la première aiguille est à droite (Z26)

Mais, effectivement, tu es en Fleischmann Picollo et ton aiguille triple est parfaitement symétrique, avec les 2 aiguilles l'une au dessus de l'autre.
Comme il y a 2 moteurs, on va dire que le premier moteur s'appelle a0 et il a 2 positions (gauche et droite) et le deuxième moteur s'appelle a1 et il a, lui aussi, 2 positions (gauche et droite).

Denis :P

4
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juin 26, 2024, 09:05:13 am »
@ Pierre,

Quand on cherche des itinéraires, on parcourt un graphe et on va d'un nœud à un autre. Qu'on appelle les nœuds "connecteurs" ou autrement, cela ne change rien.
Après, que tu me dises que ça n'a rien à faire dans le JSON parce qu'on peut les calculer dans le gestionnaire, je l'entend parfaitement.
C'est d'ailleurs aussi le cas des bretelles, facilement calculables à partir des voisins dans le gestionnaire.

Il y a un problème de vases communicants : plus le JSON est petit, plus le setup grossit pour calculer les infos nécessaires au gestionnaire. Et, globalement, la place nécessaire à la description du réseau dans le gestionnaire est la même.

@ Marc,

A la SNCF, il y a une analyse des possibilités d'un grill de voie d'une gare bien en amont et certains sont choisis et pas d'autres.
En plus, il y a une priorisation dans le cas où plusieurs itinéraires sont possibles d'un point à un autre.

Je distinguerai 2 types de gares :

1°) Les gares "biceps", c'est à dire les gares qui ressemblent à un biceps (par exemple celle de Dominique, voir schéma dans les posts précédents) où les itinéraires sont TOUS INCOMPATIBLES 2 à 2. C'est le cas le plus fréquent sur nos réseaux. C'est très simple à gérer puisqu'il n'y a pas de choix.
Il n'y a qu'une seule façon d'aller de Z25 à Z28. Et c'est pareil pour chaque grill d'entrée.
Ta gare est aussi dans ce cas (c'est un 1/2 biceps).

2°) Les gares qui possèdent plusieurs diagonales et, là, la question se pose de choisir tel itinéraire ou tel autre en priorité. Ma gare est dans ce cas. J'ai une vision particulière de ce cas en mettant des "poids" aux appareils de voie. Je ne souhaite pas développer ici. Je l'ai déjà fait il y a quelques années. J'y reviendrai le moment venu.

Après, on peut parler "d'itinéraires" qui vont d'un point A à un point B quelconques et, en particulier ceux qui traversent des gares.
Mon gestionnaire sera dans ce cas. Mais j'ai bien conscience que ça ne correspond à rien dans la réalité. C'est une extension de la notion d'itinéraire.
Et, là, évidement, il y a plein de priorisations à faire.

@ tous,

Je me pose des questions sur la numérotation des signaux.

Suivant l'auteur, j'ai 2 versions :
1°) les signaux pairs ont un numéro pair et les signaux impairs des numéros impairs.
2°) Les signaux de voies paires ont des numéros pairs et les signaux de voies impaires on des numéros impairs.
La notion de "voie" n'est, pour l'instant, pas dans le JSON.

Le 1°) est très facile à programmer.
La notion de "voie" ne sert pas dans le gestionnaire (à mon avis). Mais chaque signal a un nom (et donc un numéro) et s'il faut connaitre le nom de la voie pour attribuer un nom au signal, ça se complique... :o

Denis :P

5
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juin 25, 2024, 10:55:14 am »
@ Pierre,

Pour pouvoir faire tourner une recherche d'itinéraires, il faut des connecteurs.
Dans mon éditeur graphique de TCO, je les repère par leur coordonnées X, Y.
Là, n'ayant pas de X, Y, je me suis rendu compte qu'il suffit que chaque connecteur ait un ID.
Le connecteur étant le point unique entre 2 zones mitoyennes, je mets cet ID dans les voisins, par un "int" en premier.

Exemple des zones Z22, Z23, Z24 et Z25 dans le réseau de Dominique :

            "Z22" : {
                    "nom" : "Z22",
                    "sens" : "impair",
                    "signI" : "C1",
                    "balI" : "B17",
                    "voisP" : [36,"Z35"],
                    "voisI" : [37,"Z24"],
                    "no" : 15
            },
            "Z23" : {
                    "nom" : "Z23",
                    "sens" : "impair",
                    "signI" : "C3",
                    "balI" : "B19",
                    "voisP" : [38,"Z35"],
                    "voisI" : [39,"Z24"],
                    "no" : 16
            },
            "Z24" : {
                    "nom" : "Z24",
                    "voisP" : [40,"Z25"],
                    "voisI" : [[37,"Z22","a18","gauche"],[39,"Z23","a18","droite"]],
                    "no" : 17
            },
            "Z25" : {
                    "nom" : "Z25",
                    "sens" : "impair",
                    "signI" : "C5",
                    "balI" : "B21",
                    "voisP" : [40,"Z24"],
                    "voisI" : [44,"Z26"],
                    "no" : 18
            },

Le voisI de Z22 a le connecteur 37 et on retrouve le connecteur 37 dans Z24 quand l'aiguille est à gauche.
Le voisP de Z25 a le connecteur 40 et on retrouve le connecteur 40 dans Z24 à la pointe de l'aiguille

Voilà
Denis :P

6
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juin 24, 2024, 10:58:06 am »
@ Pierre,

Sur le réseau de Dominique, j'ai bien respecté le fait que les zones impaires se suivent et les zones paires se suivent.
Donc, quand on suit un circuit, on change bien de parité du cote à chaque changement de zone, ce qui est ta condition à laquelle je souscrit parfaitement.
Il ne faut pas dessiner n'importe quoi et, là aussi, je suis bien d'accord.
En fait, nos points de vue sont parfaitement compatibles.

Bretelles : c'est dans le JSON que sont calculées les positions où elles sont en continuité. On n'a donc plus à le faire dans le gestionnaire.
Exemple :

    "a13" : {
        "type" : "aiguilleD",
        "bretelle" : ["droite", "a16"],
        "no" : 13
    }

A vérifier sur le réseau de Dominique : L'aiguille a13 à droite fait face à l'aiguille a16 à droite.

Il est certain que faire marcher un gestionnaire sur un microcontrôleur est extrêmement complexe car ça ajoute de contraintes de place et de temps de calcul. A ma connaissance, ce serait une première.

Choix des itinéraires :

Evidemment, à chaque fois qu'on va choisir deux points, le programme va nous sortir plusieurs itinéraires possibles techniquement.
1°) Il faut d'abord éliminer ceux qui font parcourir une zone paire dans le sens impair (et réciproquement), sauf si c'est une zone à 2 sens.
2°) Il faut éliminer les itinéraires qui font tout le tour du réseau
3°) Il est tentant de calculer le nombre de zones parcourues par chaque itinéraire et de prendre l'itinéraire qui a le plus petit nombre de zones. Mais je crains que cela nuise à la fluidité.
4°) Quand on demande à un programme deux fois le même calcul, il va fournir à chaque fois les même solutions dans le même ordre.
On peut alors numéroter les itinéraires, ce qui évite d'avoir à les décrire et remplacer une liste de zones par un "int".
Et regarder, "à la main" quel itinéraire on veut garder en fonction de l'origine et l'extrémité sélectionnés.

Exemple sur le réseau de Dominique :
Je veux aller de Z25 à Z30 :

Z25 (section) signal1 signal1
Z26 (triple droit) L0 a0 a gauche + a1 a droite TIV
Z27 (section) signal1 signal1 vitesse maxi 60 km/h TIV
Z29 (triple gauche) L0 a11 a droite + a9 a gauche TIV
Z30 (section) signal1 signal1
------------------------------------- FIN DE L'ITINERAIRE ---------------------------------------------------------- 3720 292
Z25 (section) signal1 signal1
Z26 (triple droit) L1 a0 a droite vitesse maxi 60 km/h RR
Z15 (TJD) L0 a2 a droite + a4 a droite vitesse maxi 30 km/h TIV
Z42 (aiguille droite) L1 a5 a droite vitesse maxi 30 km/h RR
Z14 (section) signal0 signal0 vitesse maxi 30 km/h TIV
Z43 (aiguille gauche) L1 a6 a gauche vitesse maxi 30 km/h RR
Z12 (TJD) L1 a7 a gauche + a8 a gauche vitesse maxi 30 km/h TIV
Z29 (triple gauche) L1 a11 a gauche vitesse maxi 60 km/h RR
Z30 (section) signal1 signal1
------------------------------------- FIN DE L'ITINERAIRE ---------------------------------------------------------- 3720 293
Z25 (section) signal1 signal1
Z26 (triple droit) L2 a0 a gauche + a1 a gauche vitesse maxi 60 km/h RR
Z44 (aiguille gauche) L1 a3 a gauche RR
Z28 (section) signal1 signal1 vitesse maxi 30 km/h TIV
Z29 (triple gauche) L2 a11 a droite + a9 a droite vitesse maxi 60 km/h RR
Z30 (section) signal1 signal1
------------------------------------- FIN DE L'ITINERAIRE ---------------------------------------------------------- 3720 294

Il trouve 3 itinéraires qui se trouvent avoir les numéros 292, 293 et 294 dans "_TOUS_ITI____.tsv"
Je décide (au pif, ici) de retenir l'ordre suivant, dans le JSON :
"itinéraires" : ["Z25", "Z30", 2, 1, 3]
Ce qui, dans mon esprit, veut dire :
Quand on demande Z25-Z30, on choisit l'itinéraire n°2. Si c'est incompatible avec un autre itinéraire existant à cet instant ou si une zone de cet itinéraire est occupée, on choisit ensuite le n°1. Et si c'est encore impossible on choisit n°3.

Cette notation est compacte, peut être taillée sur mesure. Si le programme sort 10 itinéraires, on peut n'en garder que 3, ...
A ce moment, on utilise dans mon éditeur JSON le bouton itinéraire qui ne donne que les itinéraires d'un point choisi et un autre point choisi.

La seule contrainte est qu'il faut le même programme de recherche d'itinéraires dans l'éditeur JSON et le gestionnaire.

Denis :P

7
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juin 23, 2024, 11:44:50 am »
@Pierre,

Bravo pour tes efforts pour faire entrer un gestionnaire dans un microcontrôleur. 8)

@ tous,

J'ai bien avancé sur mon éditeur, bien clarifié certains points et corrigé quelques bugs. :P

Voyons dans le détail :

1°) La parité :

Quand on trace un trait sur une feuille, on a une origine et une extrémité.
Cette information ne doit jamais être perdue.

Quand un train va de l'origine vers l'extrémité, je décrète arbitrairement qu'il va dans le sens pair.
Comme, par ailleurs, on circule à gauche à la SNCF (hors AL pour des raisons historiques), il s'ensuit que les trains pairs vont dans le sens des aiguilles d'une montre. C'est une conséquence du choix précédent.

Un train pair voit des signaux pairs à l'extrémité d'une zone paire.
Un train impair voit des signaux impairs à l'extrémité d'une zone impaire.

Si une zone paire peut être parcourue dans les 2 sens, les trains pairs voient les signaux pairs à l'extrémité et les trains impairs des signaux impairs à l'origine de la zone.
Si une zone impaire peut être parcourue dans les 2 sens, les trains impairs voient les signaux impairs à l'extrémité et les trains pairs des signaux pairs à l'origine de la zone.

Donc, dans la ligne "sens" de la zone, je ne peux avoir que "pair" ou "impair".

Le voisin pair d'une zone paire est à l'extrémité et le voisin impair d'une zone paire est à l'origine.
Le voisin impair d'une zone impaire est à l'extrémité et le voisin pair d'une zone impaire est à l'origine.

Par ailleurs, il peut y avoir 0, 1 ou 2 signaux pour une zone.
On traitera plus tard le cas de 0 signaux, en particulier dans les zones multiples.
Pour 1 signal, si la zone est paire, il y aura un seul signal pair et un seul signal impair si la zone est impaire.
Pour 2 signaux, il y aura un signal pair et un signal impair. Et la parité nous dira à quel bout il est.
Si on veut garder à la fois l'information de parité et l'information du nombre de signaux dans la ligne "sens", je propose de mettre "pair0"/"impair0", "pair1"/"impair1" ou "pair2"/"impair2"

Pour les appareils de voie, je ne m'occupe pas de la parité. L'origine est toujours du côté de la pointe et l'extrémité côté talon.

Pour les traversées (croisement, TJS, TJD), je définis arbitrairement un sens puisque tout est symétrique.

Enfin, pour les zones qui ont un butoir, celui-ci est toujours à l'extrémité. La parité de la zone désignant cette extrémité.

J'ai abandonné la notion de "pairimpair" car elle fait perdre la notion d'origine/extrémité.

2°) Pierre a eu l'excellente idée d'ajouter des balises dans les zones, paires ou impaires évidemment, ce qui permet de récupérer plus souvent une information de position du train réel (odométrie) et de s'assurer d'un arrêt au pied du signal.
On évite ainsi de découper les rails pour des "zones d'arrêt" dans les zones et un seul capteur à effet hall suffit pour détecter le train à l'endroit d'une balise.

Pour l'instant j'ai défini 2 types de balises :
- avant un signal
- avant un butoir
Mais on pourrait définir d'autres types. Par exemple une balise quand un train doit siffler (entrée de tunnel, passage à niveau, …).

3°) Autre excellente idée de Pierre : les bretelles.

Effectivement, la position de certains appareils de voie implique la position d'un autre appareil sous peine de déraillement.
Dans une bretelle, il y a deux positions :

L'une ou les tracés sont parallèles où il ne peut rien se passer du point de vue du gestionnaire (pas de rattrapage, de face à face, …) et l'autre position où des zones sont dans la continuité l'une de l'autre. C'est pour ça que j'ai ajouté à la ligne "bretelles" du JSON la position des 2 appareils de voie qui amène un problème à gérer au gestionnaire.

On remarque, au passage, que les 2 appareils de voie sont soit tous les 2 à droite ou tous les 2 à gauche dans une bretelle.
Il ne peut y avoir de bretelles qu'entre 2 appareils de voie ayant des lames mobiles. Donc, on serait tenté d'exclure, à priori, les sections et les croisements.
En fait c'est plus compliqué :

Cas de la section :

Il peut très bien y avoir une section entre les 2 appareils de voie et cela constituera quand même une bretelle si cette section est "courte".
Si une section est suffisamment courte pour qu'on ne puisse pas y mettre un wagon, cela ne pose pas de problème.
Si la section est plus longue, il faut pouvoir détecter un wagon sur cette section.
Si la section est suffisamment longue pour contenir un train complet, est-ce encore une bretelle ?

Cas du croisement :

Il est très fréquent qu'un petit croisement soit associé à 2 bretelles successives, permettant ainsi de passer d'une voie à l'autre dans les 2 sens.
La difficulté, en recherche automatique, c'est que, là, il faut chercher le voisin du voisin.
C'est une récursivité à un seul étage.
4°) Pour la partie aiguilles, j'ai précisé quelle était l'aiguille concernée dans les appareils ayant 2 aiguilles (TJS, TJD, triples).
"TJDa" et "TJDb" pour une TJD. "TJSa" et "TJSb" pour une TJS
"TripleGa" et "TripleGb" et "TripleDa" et "Tripleb" pour les triples.

5°) Pour la partie signaux, j'ai ajouté la liste des signaux affichables par un signal donné.
J'ai ajouté, pour ceux susceptibles d'afficher "RR", la liste et la position des aiguilles concernées dans ce cas.

Quant à la numérotation des signaux, il y a une lettre et un nombre.
- La lettre correspond au nom du signal hiérarchiquement le plus élevé (C, Cv, S)
- Le nombre est un incrément. Il y a 2 incréments : un pair et un impair.
Suivant la parité de la zone, on incrémente de 2 le bon incrément.

Au passage, comme un signal ne peut afficher C et Cv en même temps du fait que la deuxième ampoule du carré est l'ampoule du Cv (voir ci-dessous), j'ai tenu compte de cette particularité.



Dans le gestionnaire, il faudra également gérer le feu blanc (M) qui peut être clignotant.
Le feu M à l'origine de Z28 ne peut être que clignotant, de même que les deux feux de Z37.



Je terminerai sur les signaux en disant qu'ils peuvent être visibles ou invisibles.
Un signal invisible est un signal qui est nécessaire au fonctionnement du gestionnaire, mais qui n'est pas forcément implanté sur le terrain, en particulier en zone de manœuvre où ce sont souvent des hommes qui, sur place, manipulent des drapeaux ou des lanternes.

J'ai mis un cercle vide pour les signaux qui, à mon avis, sont invisibles.
Le feu visible en Z46 sera traité avec les zones multiples, encore à faire.

6°) Je n'ai pas mis les trains dans le JSON. Pour l'instant, je ne sais pas quoi mettre.

7°) Concernant les itinéraires, c'est tellement rapide à calculer que je ne suis pas absolument convaincu que ce soit nécessaire de les calculer d'avance.
Il faut trouver une méthode qui permette de choisir un seul itinéraire quand il y en a plusieurs d'un point A à un point B.

8
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juin 10, 2024, 04:08:29 pm »
@Pierre,

Pour répondre à ta dernière remarque sur les butoirs.
C'est une chose de ne rien mettre dans le JSON. Ça gagne de la place et c'est logique. OK.
Mais pour gérer les itinéraires, il faut que toutes les zones aient un voisin et le plus facile, comme il faut bien mettre quelque chose, j'ai pris le parti de mettre le nom de la zone.
En plus, quand on recherche des itinéraires, on change de sens de parcours aux butoirs. Il n'y a même pas besoin d'avoir un cas particulier, l'inversion se fait d'elle même.

Par ailleurs, j'ai beaucoup de mal à dire qu'une zone est paire ou impaire. Je conçois, par contre, très bien qu'une zone ait un côté pair et un côté impair. Ça me va parfaitement.

Je supprimerai bien l'info "sens" dans le JSON :

Une zone a un feu (coté pair ou impair), deux feux ou pas de feux.
Si une zone a un feu "signP", elle est "paire" et l'info "sens" est redondante. Si une zone a un feu signI, elle est "impaire" et l'info "sens" est redondante.
Si une zone a deux feux, elle est banalisée et n'a donc pas vraiment de sens.
Si elle n'a pas de feu, elle est aussi banalisée et n'a donc pas vraiment de sens.

Dans les itinéraires, on a une liste de zones. L'ordre de cette liste donne le sens de parcours. Là encore, l'info "sens" est redondante.

Concernant les ralentissements, je propose que cette info soit au niveau des feux R et pas de feux RR, comme ça le train a directement l'info quand il en a besoin.

Denis :P

9
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juin 08, 2024, 07:12:48 pm »
@ Dominique,

Le fichier JSON va évoluer, suite au dernier post de Pierre.
 
En effet, comme son gestionnaire évolue, il a besoin d'informations supplémentaires et de simplifications.
En particulier, il doit être aussi petit que possible, si on veut le charger dans un processeur avant de lancer le gestionnaire.
Je suis en train de l'adapter pour qu'il réponde aux nouveaux enjeux.

Pour répondre à tes questions :

1°) Oui, le voisin d'une zone avec butoir, c'est elle-même. Et ça fonctionne très bien dans la recherche d'itinéraires.

2°) Pair/impair, c'est le sens de circulation principal d'une zone. C'est une donnée du réseau. Et ça suppose que le train roule à sens unique.
Sauf accident ou problème technique, un train pair roule dans le sens pair et voit les signaux de sens pair.

3°) Concernant les voisins, justement ça va changer : voisP pour voisin pair, voisI pour voisin Impair, pareil pour les signaux. Il va falloir que je change.

4°) Pour moi, il faut que le type des appareils de voie soit clair : une aiguille droite a la voie déviée à droite et une aiguille gauche la voie déviée à gauche.

5°) Je construit le fichier JSON à partir du fichier Zones. Pour l'instant, je sauve le fichier Zones, mais quand on sera d'accords sur le JSON, je ne le sauverai plus.
De la même façon, je sauve les fichiers d'itinéraires, très complets, mais, comme ça finira aussi dans le JSON (en résumé), ils disparaîtrons aussi.
Il y a dans le fichier Zones toutes les infos nécessaires pour construire le JSON.

Le fait de raisonner exclusivement en pair/impair va me poser quelques soucis, car c'est très différent de mon raisonnement, mais j'ai bon espoir  ;)

Denis  :P

10
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juin 06, 2024, 06:03:52 pm »
Bonjour Pierre,

Je décortique ton fichier JSON et je me pose des questions :

1°) Il y a un fichier JSON indépendant qui ne sert pas ?
2°) Tu as 2 onglets Z1 et Z2 j'imagine que Z1 est une ancienne version et que tu utilises Z2 ?
3°) Tu utilises maintenant pairETImpair, pairOUImpair. C'est quoi la nuance ?
4°) Comment tu coderais une zone sans feux (dans une zone de manœuvres, par exemple) ?
5°) Plutôt que des 0/1, tu utilises exclusivement les notions de pair/impair, partout ?
6°) C'est quoi, les balises ?
7°) J'ai un peu de mal avec tes aiguilles : tu as 2 aiguilles dans une bretelle, ce qui est logique, mais je ne vois pas de bretelle, vu que ce sont des TJS.
Et je ne vois qu'une aiguille dans les TJS ?
8°) Je vois la valeur des ralentissements dans les signaux (en donnant la position de l'aiguille qui nécessite ce ralentissement). Je trouve ça bizarre. Je pense que ce serait plus logique dans l'aiguille
9°) Dans les itinéraires, il n'y a qu'une liste de zones. Mais j'aurais tendance à y mettre aussi la position des aiguilles, de façon à ne pas avoir à la recalculer quand on appuie sur un bouton.
10°) C'est quoi "auts" ?

Je devrai être capable de traduire mon fichier Zones en un JSON de ton type, mais il faut que je comprenne tout.
Je joins ma version 8 où on trouve un fichier JSON du réseau de Dominique, pas complètement en phase avec le tien...

Par ailleurs, ça n'a rien à voir avec ce post : un PRS expliqué :
https://roverch.net/modelisme/PostePRS.htm

Denis :P
 

11
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: juin 05, 2024, 09:44:17 am »
Bonjour,

Voici la version 7 de mon éditeur JSON.
 
J'ai beaucoup d'occupations par ailleurs et peu de temps pour développer. Mais je suis impatient de vous présenter ces améliorations.
C'est sur le fichier "zones" que se voient les changements, mais je vais les traduire en modifications du fichier JSON.

Deux pistes :

1°) Suppression des feux VL sur les cibles qui ne peuvent pas l'afficher. Merci à Pierre d'avoir mis le doigt sur ce problème.

2°) Amélioration de l'ergonomie d'affichage des zones :
- On a le menu "afficher" directement dans le menu général (c'était facile)
- On a maintenant des flèches sur l'affichage d'une zone permettant de se promener de voisin en voisin sur tout le réseau. Merci à Dominique pour avoir proposé cette idée.

Point 1 :

Il est évident que le feu "cote0" de Z0 ne peut pas afficher VL puisque Z40 est une zone avec butoir.
Donc, lorsque je fais le tour des zones pour détecter les sones avec butoir, j'en profite pour enregistrer la liste de ces zones dans une ArrayList. On trouve : Z40, Z41, Z36, Z18, Z19, Z20, Z21. On trouverait aussi toutes les voies d'une gare terminus.
Puis je fais le tour des itinéraires pour détecter les zones "précédant un butoir", ce qui donne Z0, Z3, Z28, Z14 et Z37 et on les enregistre dans une ArrayList.
Puis je teste s'il existerait une autre possibilité que d'aller vers un butoir depuis ces zones. C'est faux pour toutes les zones, sauf Z14 qui permet, des deux côtés, d'aller voir ailleurs.
Donc Z14 aura la possibilité d'afficher VL et pas les autres qui auront un côté "sans VL".
Finalement, c'est assez simple.

Point 2 :

L'utilisation des flèches est effectivement une grosse amélioration de l'ergonomie.
Je réfléchirai plus tard à la possibilité d'afficher ce qui "ressemblerait à un TCO" en mettant chaque carré (zone) dans une grille.

Je vais maintenant m'attaquer aux zones multiples.

A suivre
Denis :P

12
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mai 24, 2024, 04:21:37 pm »
@Pierre,

Merci pour toutes ces remarques, fort intéressantes.

Tout d'abord, je voudrais préciser ce que j'entends par "zone multiple" (que je préfère à "zones complexes").

C'est par exemple une section + une aiguille que nous appellerons Z38.
Dans ce cas, je propose de créer dans mon programme une zone qui est une section Z38/0 et une zone qui est une aiguille Z38/1.
Dans mon programme, ce seront 2 zones, mais avec des noms particuliers avec un caractère réservé : "/", plus un numéro d'ordre.
Mais comme ce n'est, sur le réseau, qu'une seule zone (une seule détection de présence), dans le JSON, on ne fera écho que d'une seule zone : Z38.

L'intérêt, pour moi, est de garder une cohérence complète et de ne gérer des signaux que sur des sections. Je ne change rien au programme, les affichages sont identiques, sauf que la section Z38/0 est de longueur nulle.
Pour le JSON, ça ne change rien, on n'a bien qu'une seule Z38.

Pour ta zone multiple :


 
On a 5 parties dans la zone Z1.
Cela répond à ta première remarque.

Citer
Sur le dessin, la zone de manœuvres est identifiée en étant en blanc. Elle a un traitement particulier.
Les zones Z16 et Z30 sont aussi des zones de manœuvres, mais ne sont pas en blanc ! en fait ce sont des zones hybrides ligne/manœuvre.

Je suis entièrement d'accord.

Citer
Concernant les parités, j'ai abandonné, dans le gestionnaire, les cotés 0/1 ou 1/2 pour des cotés pair/impair, c'est beaucoup plus simple. Et ceci pour toutes les zones. Cela implique aux changements de zone des transitions pair vers impair ou impair vers pair.

La raison pour laquelle j'utilise des numéros, c'est que je m'en sers dans des Arrays (par exemple pour les connecteurs[coté][lames]). Il me faut des "int".

Citer
Il y a deux types de limitation de vitesse.
- Les limites pour les sections, par TIV (Tableau Indicateur de Vitesse).
- Les limites liées à une position déviée d'aiguille.
Les TIV sont surtout utilisés en ligne, même en présence d'aiguilles  (en talon). En présence d'aiguilles en pointe, si la vitesse est limitée à 30 ou 60 on utilise de RR30 ou RR60, sinon un TIV est utilisé. Il y a même des cas ou un RRxx et un TIV sont utilisés pour deux vitesses différentes suivant la position d'aiguilles.

Tout à fait d'accord.
Dans mon programme, s'il y a une limitation de vitesse en position "tout droit", je la tague "TIV".

Citer
A noter une chose importante : on entre dans une zone de manœuvres en marche arrière pour pouvoir en ressortir en marche avant.
C'est quoi une marche avant ou une marche arrière (par rapport à quoi).

Les zones Z16 et Z30 sont, normalement des zones unidirectionnelles. Elles deviennent banalisées uniquement pour aller dans la zone de manœuvres en reculant.

Citer
- à propos de VL, les carrés d'entrée des gares terminus n'affichent jamais VL

C'est vrai, j'avais oublié ce cas, pourtant très logique...
Mais c'est aussi vrai hors des gares terminus.
Je vais lire tous les itinéraires et trouver ceux qui se terminent par une voie de garage. Comme un butoir est un C, le signal précédent est, au mieux, un A. Donc, lors de cette recherche, je vais pouvoir faire une liste des sections précédant un butoir et, donc, susceptibles de ne pas afficher VL.
Dans une deuxième phase, je testerai si les sections de cette liste peuvent avoir autre chose qu'un butoir comme zone suivante. Si une zone ne peut avoir qu'un butoir comme suivant, je supprime VL.

Sur le réseau de Dominique, Z28 sera dans la liste puisqu'elle peut déboucher sur Z36.
L'autre issue possible pour Z28 cote0 serait Z25, mais Z25 n'est pas banalisée et uniquement en sens contraire de Z28. Donc, le signal coté0 de Z28 ne pourra jamais être VL.

Citer
- a propos de S, ce feu n'est utilisé que pour le cantonnement (BMU,BAL,BAPR, ...), sur un réseau il peut avoir de parties sans cantonnement (donc avec des signaux sans S)

Là aussi, je suis d'accord. Pour l'instant, je me limite au BAL et je n'ai jamais vu ce cas sur un réseau miniature, alors que ce serait possible.

Citer
- dans les postes avec des itinéraires permanent, s'il y a du cantonnement, certains carrés peuvent présenter le S, pour assurer la continuité du cantonnement à la traversée d'une gare, d'une bifurcation , ...
- dans les postes avec du transit souple, s'il y a du cantonnement, les carrés peuvent s'ouvrir au sémaphore (S)

Je suis d'accord avec toi, c'est possible, mais pour qu'il y ait du cantonnement DANS la gare, il fait qu'elle soit vraiment grande. Je n'ai pas d'exemple de réseau miniature qui ait eu besoin de ça. Ceci dit, c'est simple à faire : je vais garder le S pour les cas où, DANS une gare, il y a 2 sections qui se suivent.

Mais à partir du moment où il y a des itinéraires, je vois mal l'aiguilleur donner le S. Ou il donne le C, ou il donne au train la possibilité de partir.

Citer
- il peut avoir d'autres signaux qui ne soient pas des signaux de cantonnement (avertissement, carré, ...)

OK, c'est vrai.

Citer
- il y a un autre signal de manœuvre, dans les grandes gares un feu de manœuvre (M : blanc) peut être utilisé pour les départs en manœuvre sur les carrés (compter les feux des signaux de grande gares : 5 feux (A, S, Vl, M, C)

Effectivement, il faut penser à cette possibilité. A développer.
Dans la pratique du réseau miniature, je préfèrerai utiliser des signaux au ras du sol pour aller vers les zones de manœuvre depuis les voies principales et ne pas avoir de signal combinant les signaux de voie principale et des signaux de manœuvre. Mais je suis d'accord que ça existe.

Enfin, il existe affectivement des BMU, des BAPR, … et, effectivement, certains réseaux simples auraient besoin de ce type de signalisation allégée, justement parce qu'ils sont simples. Pour l'instant, je n'ai pas d'idée pour intégrer ça et je me cantonne (ah ah) au BAL.
L'autre problème, dans les cas simples, justement, c'est le signal qui sert à 2 voies en sortie de gare. Je cherche une idée.

Denis :P

13
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mai 23, 2024, 10:25:33 am »
Bonjour,

Aujourd'hui : les itinéraires.

Il existe dans le programme un bouton "Itinéraires" qui donne tous les itinéraires entre un point A et un point B quelconque sur le réseau. C'est anecdotique.
C'est juste pour voir ce que ça donne. Je supprimerai certainement ce bouton par la suite.

En revanche, il y a un autre bouton, le bouton "Analyse", qui, lui, donne 3 tables qu'on peut lire par la suite dans Excel :
_TOUS_ITI____.tsv qui liste tous les itinéraires possibles du réseau
_TOUS_ITI_G__.tsv qui ne liste que ceux des gares
_TOUS_ITI_M__.tsv qui ne liste que ceux concernés par les zones de manœuvres.

Le fait que ce soit sous forme de tables est, là aussi, anecdotique.
Mais c'est utile en phase de développement.
C'est, comme le nom de la variable le dit bien : "littéral", c’est-à-dire lisible par un humain et il faudra qu'on décide ce qu'on garde pour le fichier JSON et sous quelle forme plus compacte.

Comment se calcule un itinéraire ?

Voici un exemple très simple :


 
En bleu, comme précédemment, les signaux, en rouge le "cote0" et, en "non rouge", le "cote1".

Je ne raisonne pas en aiguille à gauche/à droite, mais je considère les "lames" d'un appareil de voie.
Pour l'aiguille en Z5, quand les lames sont à 0 (= "L0"), on est "tout droit", de A à B.
Pour l'aiguille en Z5, quand les lames sont à 1 (= "L1"), on est "dévié", de A à C.
Pour la TJD Z2, quand les lames sont à 0, on va de A à B, en 1, on va de C à D, en 2, on va de A à D et en 3, on va de C à B.
Je n'ai ainsi qu'une seule variable à suivre pour connaitre la position des lames dans n'importe quel appareil de voie.

Evidemment, une section a les "lames" à 0…

Je veux aller de Z1, cote1 vers Z6, cote0.

J'ai 2 procédures dont le nom dit bien ce qu'elles font :
- connecteur_mitoyen(zone, connecteur)
- connecteur_suivant(zone, connecteur)

On démarre par connecteur_mitoyen(Z1, 1).

Les connecteurs d'une zone sont repérés par 2 variables : zone.connecteur[cote][lames]

Donc, on part de Z1.connecteur[1][0] et, en raisonnant sur les voisins, on trouve que le connecteur mitoyen est Z2.connecteur[0][0] (on démarre par lames à 0), c’est-à-dire A.
Puis on passe au connecteur suivant qui est le Z2.connecteur[1][0], c’est-à-dire B.
Connecteur mitoyen = Z3.connecteur[0][0]
Connecteur suivant = Z3.connecteur[1][0] qui est un butoir. Le mitoyen d'un butoir, c'est lui-même et on est dans le sens retour.
Connecteur suivant = Z3.connecteur[0][0] sens retour
Connecteur mitoyen = Z2.connecteur[1][0] sens retour, c’est-à-dire B
Connecteur suivant = Z2.connecteur[0][0] sens retour et comme on a mémorisé la première entrée dans Z2 dans une variable indépendante, on repart dans le sens aller, mais on avance les lames, ce qui fait qu'on repart de Z2.connecteur[0][2], c’est-à-dire A
Connecteur suivant = Z2.connecteur[1][2], c’est-à-dire D
Connecteur mitoyen = Z5.connecteur[2][1], c’est-à-dire C
Connecteur suivant = Z5.connecteur[0][1], c’est-à-dire A
Connecteur mitoyen = Z6.connecteur[1][0]
Connecteur suivant = Z6.connecteur[0][0] qui est le connecteur final.

Le Diable se cachant dans les détails, c'est, évidemment, plus compliqué que ça, mais on a là une bonne idée de ce qui se passe.

Calculer tous les itinéraires d'un réseau :

Avant de se lancer dans des boucles imbriquées, on va calculer combien de recherches d'itinéraires on va avoir.
Le réseau de Dominique comporte 47 zones.
A priori, on a 47 zones x 2 cotes x 47 zones x 2 cotes = 8 836 itinéraires.
C'est beaucoup, mais c'est gérable.
Première simplification : on part et on arrive sur une section. Il y en a 31.
Deuxième simplification : on n'arrive pas sur la même zone que celle du départ.
Donc 31 x 2 x 30 x 2 = 3 720 itinéraires.
On a gagné 60% des tests !
for (Zone zone0 : toutes_zones) {
    //-------------------------------- on balaie toutes les zone0----------------------------------------
    if (zone0.type == 99) {
        //---------------------------- on part obligatoirement d'une section ----------------------------
        for (int cote0 = 0; cote0 < 2; cote0++) {
            //------------------------ on teste les 2 cotés de la zone0 ---------------------------------
            for (Zone zone1 : toutes_zones) {
                //-------------------- on balaie toutes les zone1 ---------------------------------------
                if ( zone1.type == 99) {
                    //---------------- on part obligatoirement d'une section ----------------------------
                    if (zone1 != zone0) {
                        //------------ on ne peut pas avoir zone0 = zone1 -------------------------------
                        for (int cote1 = 0; cote1 < 2; cote1++) {
                           compte_ori_ext++;
                           zone_depart  = zone0;
                           cote_depart  = cote0;
                           zone_arrivee = zone1;
                           recherche_itineraires(zone0.connecteur[cote0][0], zone1.connecteur[cote1][0]);
                        }
                    }
                }
            }
        }
    }
}

Dans la pratique, on n'a que 579 itinéraires possibles et le calcul ne prend qu'une seule seconde. Et on ne fait pas que ça.

Je calcule également les itinéraires des gares, c’est-à-dire que je limite les sections de départ et d'arrivée : on part d'une zone en ap_g0 vers une zone en g0 (champ gare) ou on part de g0 vers so_g0. Et pareil pour g1.
On trouve 18 itinéraires sur 128 testés.

Enfin, on calcule aussi les itinéraires de la zone de manœuvres.
On trouve 30 itinéraires sur 288 testés.

A chaque fois, on obtient une table qui donne, en littéral, les itinéraires trouvés.

Maintenant, je pose deux questions :
- Ai-je bien trouvé tous les itinéraires possibles (surtout en gare et en manœuvres) ?
- Sous quelle forme doit-on les rentrer dans le JSON ?

Une autre question se pose :
A quoi cela peut-il servir de calculer TOUS les itinéraires d'un réseau ?

Cela sert à calculer où on doit implanter des RR (Rappel de Ralentissement) et, par la suite les R (Ralentissement).
On a vu dans mon précédent post que les limites de vitesse sont distinguées en "RR" et "TIV".
Donc, si, dans la liste de l'itinéraire, on a une vitesse "en RR", on remonte dans l'itinéraire jusqu'à arriver sur une section qui aura donc un signal RR.

Remarque :
Cela ne veut pas dire que, dans le même itinéraire, on pourra remonter jusqu'à trouver la section précédente.

Exemple : on est dans l'itinéraire Z25 -> Z28.
Aussi bien dans Z44 que dans Z26 en position déviées, on a une limite à 30 km/h.
Donc, il y a bien un RR affiché dans le signal de Z25.
Mais l'itinéraire n'est pas assez long pour qu'on puisse aller jusqu'à Z22 ou Z23 qui, eux, auront un R qui justifiera du RR en Z25.
Donc, dès qu'on sait que le signal de Z25 peut afficher RR, on sort de la boucle.
Et, à la fin de ces boucles, on a tous les signaux susceptibles d'afficher RR.
Et il faut repartir dans les d'autres boucles pour déterminer les R dans la section précédant la section ayant un RR.
Et c'est là que Z22 et Z23 auront un signal susceptible d'afficher R.

Remarque :
Il existe 2 types de R/RR : le R/RR30 et le R/RR60. Ils se gèrent de la même façon.

Auparavant, on a permis l'affichage de S, A, VL (Sémaphore, Avertissement, Voie Libre) sur tous les signaux. Puis on s'attaque aux C (Carrés).

On a deux types de C :

1°) Le C "d'impossibilité de continuer", lié au fait que les lames des appareils de voie sont dans une position qui ne vous permet pas d'avancer. Exemple : vous arrivez par la voie déviée d'une aiguille et les lames sont en position "tout droit".
Remarque : il existe à la SNCF une possibilité technique de continuer quand même si c'est prévu et que cette aiguille est "talonnable".
Je pense que ce n'est pas une bonne idée en miniature. Il y a déjà tellement de possibilités de dérailler que ce n'est pas la peine d'en rajouter…

2°) Le deuxième type de C est complètement différent : c'est l'aiguilleur qui gère la gare qui l'affiche ou le retire quand toutes les conditions (sécurité, horaires, …) sont remplies.
Exemple : Le train que vous prenez est déjà là, 20 minutes avant le départ. Il y a peu de trafic et e l'itinéraire est déjà "formé". Si le train avançait, il n'y aurait aucune impossibilité technique, toutes les aiguilles étant déjà "en position". Mais il n'est pas l'heure, ou d'autres raison peuvent être évoquées, et l'aiguilleur fait afficher le C au signal devant le train.
Quand il le décidera, il éteindra le C et le train pourra partir.

Remarque : (on l'a déjà dit dans un précédent post) un signal de gare gérée par itinéraires n'affiche pas le S. Donc, quand je donnerai à toutes les voies de gare la possibilité d'afficher le C, il faudra effacer le S. Cela vaut aussi pour les zones d'approche.

Signaux de manœuvres :

Il n'y a qu'un signal de manœuvre : le Cv (Carré Violet). C'est le seul qui ne soit pas un signal de cantonnement.

Dans la pratique, il y a moins de signaux que sur les voies principales car les trais roulent "à vue", à 15 km/h maxi.
Ils sont indispensables aux frontières zone de manœuvre/voies principales et pour les zones d'approche de la zone de manœuvre. Après, les règles sont floues…

Signaux au-dessus des butoirs :

Il s'agit obligatoirement de carrés ayant la particularité de n'avoir qu'un feu, au milieu du butoir.
En zone de manœuvre, ce sont des Cv (et donc violets) (Z18, Z19, Z20 et Z21) et des C (et donc rouges) sur voies principales (Z40 et Z41)


Voilà donc comment, en appuyant simplement sur le bouton "Analyse", on calcule tous les itinéraires et les signaux d'un réseau. Le tout en une seconde chrono !

Denis  :P

14
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mai 21, 2024, 05:07:32 pm »
Bonjour,

Depuis des années, je suis persuadé qu'on peut calculer les signaux à partir du dessin du réseau et quelques infos simples.

La vraie question qui se posait, c'était de savoir quelles infos étaient absolument indispensables.
Je viens de franchir une étape que je vais vous détailler.

Je vais le faire sous forme d'une série de posts. Le programme sera proposé dans le dernier post.

Pour l'instant, il sort plusieurs fichiers complets, faciles à lire (et à comprendre, j'espère), mais il faudra en extraire les infos utiles au fichier JSON en ce qui concerne les signaux et les itinéraires.
En gros, il y a "trop" d'informations et il ne faudra garder que celles absolument nécessaires au gestionnaire. Par exemple, quand il y a plusieurs itinéraires entre un point A et un point B, lequel choisir ?

Infos minimales :

Je prends comme exemple le réseau de Dominique qui est assez représentatif des difficultés rencontrées par de nombreux modélistes.


 
Sur ce dessin, sont représentés les infos qui doivent être rentrées dans mon programme pour que tous les calculs soient faits.
Il faut faire ce dessin, avant de rentrer les infos.
 
Dès le dessin, il faut prendre des décisions : sens de circulation des zones, leur nom, la position des signaux.
 
A noter que j'ai retiré les numéros de voie et je n'ai gardé que les noms de zone.
On pourra, par la suite, donner des numéros de voie, mais ils ne serviront pas dans un gestionnaire.

Sont représentés :

1°) Le dessin du réseau :

En rose, les "appareils de voie" (aiguilles, TJD, croisements, …).
En bleu, les "sections", c’est-à-dire tout ce qui n'est pas un appareil de voie (rails droits, courbes, flexibles)

Exemple : Z17 est un appareil de voie (une aiguille) et Z16 est une section.

Je fais la distinction car j'impose aux signaux de n'être que sur des sections.

Une première difficulté apparait sur la Z46 qui est, pour moi, une "zone complexe". Elle est composée de l'aiguille a20, d'une section de longueur nulle qui supportera le signal et de l'aiguille a10.
Dans le programme actuel, la Z46 est une TJD sans signal.
C'est une erreur, mais je réserve pour la suite le traitement des zones complexes. J'ai une idée assez précise de ce que je vais faire, mais on en parlera plus tard. Il y a déjà assez de questions à se poser avant.

Sur le dessin, la zone de manœuvres est identifiée en étant en blanc. Elle a un traitement particulier.

Je considère qu'il y a 2 gares : la gare g0 en bas (hors zone de manœuvres) et la gare g1 en haut.

Par ailleurs, une navette se promène sur les zones vertes (de Z40 à Z41).
 
Je n'ai pas considéré que Z40+Z0 et Z41+Z3 soient des gares, mais on aurait pu le faire car, dans la réalité, ce serait le cas.
Mais l'intérêt de déclarer un ensemble de zones comme étant une gare, c'est qu'on peut attribuer des itinéraires à cette gare. Et là, … les itinéraires…

2°) L'orientation des zones (les flèches rouges) :

Toute zone a un sens privilégié, ne serait-ce que pour la dessiner.
Je préfère raisonner par "côtés" (voir un précédent post à ce sujet).
Le sens privilégié (la grosse flèche) va du "cote0" au "cote1" (de A à B). Donc, quand vous sélectionnerez une section, vérifiez bien que le sens que vous avez choisi correspond bien à celui du dessin du réseau.
Pour les appareils de voie, j'ai fait un récapitulatif des différents cas :


 
Le point rouge correspond au cote0, les autres extrémités étant cote1. Je reviendrais sur ce schéma dans les itinéraires.

Le point bleu sur le dessin du réseau correspond à la présence d'un signal.
Pour les zones n'ayant qu'un seul sens de circulation, le signal est toujours "cote1".
Pour les zones ayant les deux sens de circulation (les zones "banalisées"), on a une deuxième flèche, plus petite.
Pour moi, les zones banalisées "ont un sens". Pensez-y en choisissant où vous mettez les feux (côté A ou côté B dans le programme) : il y a un signal "cote0" (= A) et un signal"cote1" (=B).

3°) La parité :

On n'a pas à rentrer spécifiquement la parité d'une zone.
Rien qu'en choisissant une section sur l'octogone de départ, vous définissez la parité de la zone. Puis, par itération successives, le programme calcule la parité des appareils de voie.
Par exemple, la zone 24 est déclarée "sens impair" par le fait que les zones Z22, Z23 et Z25 sont impaires.
La parité d'une zone est donc calculée et entrée directement dans le fichier JSON pour usage ultérieur dans un gestionnaire. Les zones banalisées sont dites "pairimpair".

4°) Zones complexes :

Pour l'instant, chaque appareil de voie est une zone à lui tout seul. Ce n'est pas toujours le cas dans la réalité.
On regroupe souvent des appareils en une seule zone ou une zone peut être constituée d'une section et d'un appareil de voie. C'est ce que j'appellerai une "zone complexe", pour l'instant non gérée par le programme actuel. A suivre, donc.

5°) Les vitesses limites :

J'ai défini (arbitrairement) la vitesse maxi à 160 km/h.
Il y a deux types de limitation de vitesse.
 
- Les limites pour les sections, par TIV (Tableau Indicateur de Vitesse).
On la rentre simplement dans la section en cliquant sur le point blanc sur le tracé de la zone. On affiche alors la vitesse qui apparait dans un losange sur le dessin de la zone.
Dans les fichiers d'itinéraires, la vitesse limite sera alors suivie de "TIV".

- Les limites liées à une position déviée d'aiguille.
On la rentre de la même façon sur la branche concernée du dessin de l'appareil de voie.
Elle est également affichée dans un losange sur la branche concernée.
Dans les fichiers d'itinéraires, la vitesse limite sera alors suivie de "RR".
On verra dans le calcul des signaux que cette info est cruciale.

A noter que la vitesse limite dans la position "tout droit" est une limite de type TIV.

6°) Le calcul des zones de gare :

Les gares sont parfois importantes et, même si on peut rentrer ces infos à la main, zone par zone, cela peut être très fastidieux. J'ai donc développé un programme qui complète automatiquement les infos rentrées.
Dans une première version, j'arrivais à définir les gares en ne définissant qu'une seule zone. Mais il fallait des gares vraiment particulières.
Dans cette version, il faut rentrer les infos de zone d'approche et de zone de sortie, le programme ne pouvant pas toujours les définir automatiquement.

Dans le cas de la gare0 du réseau de Dominique, on rentre :
En zone 11 : "ap_g0" dans le champ "gare". C'est la zone d'approche de la gare0.
En zone 16 : "so_g0" dans le champ "gare". C'est la zone de sortie de la gare0.
En zone 25 : "ap_g0" dans le champ "gare". C'est la zone d'approche de la gare0.
En zone 30 : "so_g0" dans le champ "gare". C'est la zone de sortie de la gare0.
Et on rentre "g0" dans la zone 27, ce qui devrait permettre de calculer la gare.
Malheureusement, ça "bave" sur la zone de manœuvres qui se trouve ainsi déclarée "gare", ce que je ne veux pas.
Il faut donc, en plus rentrer "bloque" en zones Z36, Z45 et Z46. Et là, tout est OK.

7°) Le calcul des zones de manœuvres :

C'est un calcul similaire au calcul d'une gare, mais il n'y a pas besoin de bloquer puisque la gare est déjà définie et elle va bloquer l'expansion de la zone de manœuvres.
Il faut juste entrer :
En zone 16 : "ap_m0" dans le champ "manœuvres". C'est la zone d'approche de la zone de manœuvres 0.
En zone 30 : "ap_m0" dans le champ "manœuvres". C'est la zone d'approche de la zone de manœuvres 0.
Puis Z36 et Z37 définies comme "m0".

A noter une chose importante : on entre dans une zone de manœuvres en marche arrière pour pouvoir en ressortir en marche avant. Les zone Z16 et Z30 sont donc banalisées.

Une zone de manœuvres est toujours banalisée.
 
Il s'ensuit que la zone de gare Z14 est forcément banalisée à cause de Z45 et Z46 banalisées, ainsi que la zone de gare Z28 à cause de Z36.

Voilà, on a fait le tour de toutes les infos nécessaires au fonctionnement du programme.

On voit qu'elles sont chacune assez simple à déterminer et que les connaissances de la SNCF sont très minces pour mener à bien cette mission.
Tout le reste est automatique.

En PJ, le réseau en plus grand, plus lisible, les appareils de voie, imprimables et le fichier "Zones" initial en .tsv (à ouvrir dans Excel) dans lequel on voit qu'il y a plein de cases vides...
On y voit aussi les cases remplies via les dessins de zones. On ne rentre rien directement dans le fichier sous peine d'erreurs et d'incohérences.

A suivre : les itinéraires

Denis :P

15
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mai 09, 2024, 02:48:12 pm »
Bonjour Pierre,

Le problème que tu poses n'est pas lié au PRS, il est, en effet beaucoup plus général.

Comme tu le sais déjà, il s'appelle à la SNCF la "limite de zone de garage franc", symbolisée, à la SNCF, par une marque blanche qui indique l'endroit à partir duquel un véhicule (loco ou wagon, voiture, ...) engage le gabarit d'une voie voisine.
C'est même en vente chez Décapod, pour info (voir fichier joint).

Concernant le matériel en miniature, comme la détection se fait par détection de courant, c'est donc au niveau des roues que l'on détecte une présence.
Et, particulièrement pour les voitures (ou tout matériel à bogies), il y a un bon écart entre le tampon et la roue... ce qui n'arrange rien.

Ce qui m'embête aussi, c'est que je n'ai aucune idée de la façon dont la SNCF gère le problème que tu soulèves.
Parce que mettre un repère blanc, c'est bien, mais ça ne résout pas le problème.

A mon avis, en gérant les longueurs de train (en comptant les "points" dans l'image à l'écran, par exemple), on devrait pouvoir s'en sortir.
Mais un train virtuel ne perd jamais ses wagons...
Je pense que le vrai problème se pose quand les wagons se décrochent.

Denis

Pages: [1] 2 3 ... 51