Voir les contributions
31
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 09, 2024, 10:40:27 am »
Bonjour à tous,
J'ai avancé sur mon programme d'éditeur de JSON.
Construire un JSON "à la main" est tout à fait faisable, mais il faut bien maîtriser les subtilités de la SNCF et il faut décrire énormément de choses, ce qui est pénible et source d'erreurs.
Grâce à un programme qui automatise un peu les choses, on peut regarder les anomalies, les corriger et minimiser les saisies.
Dans mes premiers jets, les saisies étaient, à mon avis, lourdes.
Quant aux modifications, elles étaient impossibles : on efface et on réécrit les données de la zone. C'est toujours le cas en ce moment, mais j'ai des pistes prometteuses concernant les modifications. Je verrais bientôt.
La signalisation :
Je m'intéresse à la signalisation depuis des dizaines d'années.
Aussi, automatiser une signalisation pour un réseau est un vrai challenge.
Disons-le tout de suite : on ne peut pas tout automatiser. Il faut quand même donner un minimum d'informations simples qu'un programme ne peut pas deviner tout seul.
Tout le problème consiste à rentrer vraiment très peu d'informations.
A noter que très peu de réseaux ont une signalisation et encore moins une signalisation fonctionnelle. C'est malheureux.
Mais on a aussi des réseaux qui font circuler des locos électriques sans caténaire…
Quelle signalisation ?
Suivant la période et la région concernée, il y a DES signalisations.
Chaque compagnie (avant la SNCF) avait sa signalisation, au départ mécanique puis lumineuse.
En 1934, on passe progressivement au code Verlant.
La création de la SNCF en 1938 entérine cette signalisation.
Je me limiterai donc à la signalisation lumineuse, postérieure à 1936 et antérieure au TGV qui a, lui aussi une signalisation tout à fait spécifique.
En fait, je procède par étapes :
Etape 1 : Le Locoduinodrome, même dans sa version 2, est trop simple.
Je suis passé à un réseau que je connais bien et pour lequel j'ai un plan des zones, avec une signalisation complète, qui plus est, validée par Pierre il y a quelques années : le réseau de Dominique.
C'est d'ailleurs en rentrant toutes les zones dans mon programme que je me suis aperçu de la lourdeur de mon processus initial.
Par exemple, même si, à terme, on a besoin des limites de vitesse de chaque zone, ce n'est pas la peine de les rentrer dès le début. Ce sera donc dans un deuxième temps, en "complément" qu'on rentrera ces infos. Sans compter les incohérences possibles dans la saisie des vitesses.
Etape 2 : Décrire quasi automatiquement ce qu'est une gare et une zone de manœuvres.
C'est absolument nécessaire car il y a dans les gares et le zones de manœuvres une signalisation spécifique. J'en suis à cette étape
Etape 3 : En fait, on ne peut pas trouver quel signal est nécessaire si on n'a pas d'itinéraires.
Et, si on veut trouver les itinéraires dans une gare, il faut définir quels sont les zones qui la composent, avec les zones d'approche et de sortie, bien sûr. Dans un premier temps, on limitera les itinéraires aux gares.
Donc, voici ma démarche globale :
1°) Rentrer toutes les zones d'un réseau (nom des zones et des voisins)
Dans les segments, donner la position des signaux, ce qui donnera la parité des segments.
Dans les appareils de voie, pas de signaux et, je pense, pas de parité à rentrer.
-> Pour les traversées (croisements, TJS et TJD), on met la parité à "pairimpair"
-> Pour les autres aiguilles, la parité de l'appareil de voie est la parité de son unique point commun avec un segment dont on connait la parité.
Il faudra peut-être pousser un peu plus loin le raisonnement pour la parité des appareils de voie.
2°) Définir comme "gare" quelques zones pour calculer la gare entière.
3°) Définir comme "manœuvres" une zone pour calculer la zone de manœuvres entière.
4°) Trouver tous les itinéraires de chaque gare.
5°) Rentrer les infos complémentaires de vitesse des segments de la gare, ce qui donnera les vitesses des appareils de voie, branche par branche, en évitant les erreurs et les incohérences.
En déduire la signalisation correspondante.
Démarche pour définir une gare (voir le fichier gare) :
J'ouvre une ArrayList : "zones_gare" qui va collecter toutes les zones d'une seule gare, au fur et à mesure que le programme parcourt toutes les zones.
Une fois les zones rentrées, je déclare Z3 "gare", ce qui met "g0" dans le champ "gare" de la zone Z3.
Puis la recherche systématique commence. Elle est détaillée dans le fichier joint.
En ayant rentré une seule zone, on a décrit toute la gare.
Evidemment, cet exemple est très simple.
Il est basé sur le principe suivant : dans une gare, il n'y a jamais deux segments voisins.
Dans cette gare, il permet, à la fois, d'exclure Z0 et Z7 de la gare et de déclarer Z1 zone d'approche et Z6 zone de sortie.
Dans la gare de Dominique, ce seul principe ne suffit pas. Ça serait trop beau !
Il y a 2 gares : g0 au sud et g1 au nord.
On doit rentrer un segment dans g0 : j'ai choisi Z27
On doit rentrer 2 segments dans g1 (un pour le haut de la gare, un pour le bas car il n'y a pas de communication entre le haut et le bas de la gare g1) : j'ai choisi Z4 et Z22.
On n'a pas à s'occuper de la partie droite du schéma car on y trouve 2 segments consécutifs.
Z11 est une zone d'approche de g0, mais pas Z30
Z34 est une zone d'approche de g1, mais pas Z7
Pour la partie gauche, on ne peut pas utiliser le principe puisqu'il n'y a qu'une zone entre les deux gares et on aboutirait à une seule et unique gare.
Il faut donc préciser "à la main" les informations :
Z25 est la zone d'approche de g0 et Z16 est la zone d'approche de g1.
Les infos rentrées à la main sont prioritaires sur les infos crées par le programme.
Les zones de manœuvre :
Dans le réseau de Dominique, il y a aussi des zones de manœuvre. Et, si on n'y prenait pas garde, elles seraient, elles aussi, ajoutées aux gares, ce qui serait une erreur.
Il faut donc bloquer le processus en rentrant "bloque" dans les zones Z36, Z45, Z46 pour g0 et dans Z2 pour g1.
Maintenant, il faut décrire les zones de manœuvre.
A noter une chose importante : sauf cas particulier, on rentre dans la zone de manœuvre en marche arrière et on en sort en marche avant.
C'est le même principe que pour les gares, à ceci près qu'il n'y a pas besoin de bloquer, la gare s'en charge et, aux autres extrémités, tous les butoirs arrêtent le processus de recherche de zones.
On définit donc Z36 et Z37 où on rentre m0 dans le champ "manœuvres" des zones.
La dernière chose à définir, ce sont les zones d'approche des zones de manœuvres.
Là, je ne vois pas d'automatisation possible : il faut les définir à la main dans Z30 et Z16, champ "manœuvre". A noter, peut-être une piste : Z30 et Z16 sont les zones de sortie de la gare et je pense que ça n'est pas un hasard.
Résumé :
En rentrant 13 informations simples, on remplit 37 cases sans erreurs !
Fichiers joints :
https://www.locoduino.org/IMG/zip/editeur_json4.zip
Dans le .zip, on a ma dernière version du programme Processing, avec la création des gares et des zones de manœuvre. Mais je n'ai pas fait la partie "entrée des infos gare/manœuvre" : je les rentre directement dans le fichier Excel. C'est la prochaine chose que je vais faire. C'était juste pour tester le fonctionnement.
On ne pose plus de questions pour les vitesses dans la première phase, mais il faudra poser les questions dans les "compléments". A réaliser, donc
Je vais aussi ajouter la possibilité de modifier les informations dans une zone.
Les fichiers Excel décrivant les zones (avant et après) sont dans le .zip
Il y a aussi le fichier détaillé du processus de définition d'une gare.
Et, évidement, le plan du réseau de Dominique (toutes mes excuses pour cet oubli)
Denis
J'ai avancé sur mon programme d'éditeur de JSON.
Construire un JSON "à la main" est tout à fait faisable, mais il faut bien maîtriser les subtilités de la SNCF et il faut décrire énormément de choses, ce qui est pénible et source d'erreurs.
Grâce à un programme qui automatise un peu les choses, on peut regarder les anomalies, les corriger et minimiser les saisies.
Dans mes premiers jets, les saisies étaient, à mon avis, lourdes.
Quant aux modifications, elles étaient impossibles : on efface et on réécrit les données de la zone. C'est toujours le cas en ce moment, mais j'ai des pistes prometteuses concernant les modifications. Je verrais bientôt.
La signalisation :
Je m'intéresse à la signalisation depuis des dizaines d'années.
Aussi, automatiser une signalisation pour un réseau est un vrai challenge.
Disons-le tout de suite : on ne peut pas tout automatiser. Il faut quand même donner un minimum d'informations simples qu'un programme ne peut pas deviner tout seul.
Tout le problème consiste à rentrer vraiment très peu d'informations.
A noter que très peu de réseaux ont une signalisation et encore moins une signalisation fonctionnelle. C'est malheureux.
Mais on a aussi des réseaux qui font circuler des locos électriques sans caténaire…
Quelle signalisation ?
Suivant la période et la région concernée, il y a DES signalisations.
Chaque compagnie (avant la SNCF) avait sa signalisation, au départ mécanique puis lumineuse.
En 1934, on passe progressivement au code Verlant.
La création de la SNCF en 1938 entérine cette signalisation.
Je me limiterai donc à la signalisation lumineuse, postérieure à 1936 et antérieure au TGV qui a, lui aussi une signalisation tout à fait spécifique.
En fait, je procède par étapes :
Etape 1 : Le Locoduinodrome, même dans sa version 2, est trop simple.
Je suis passé à un réseau que je connais bien et pour lequel j'ai un plan des zones, avec une signalisation complète, qui plus est, validée par Pierre il y a quelques années : le réseau de Dominique.
C'est d'ailleurs en rentrant toutes les zones dans mon programme que je me suis aperçu de la lourdeur de mon processus initial.
Par exemple, même si, à terme, on a besoin des limites de vitesse de chaque zone, ce n'est pas la peine de les rentrer dès le début. Ce sera donc dans un deuxième temps, en "complément" qu'on rentrera ces infos. Sans compter les incohérences possibles dans la saisie des vitesses.
Etape 2 : Décrire quasi automatiquement ce qu'est une gare et une zone de manœuvres.
C'est absolument nécessaire car il y a dans les gares et le zones de manœuvres une signalisation spécifique. J'en suis à cette étape
Etape 3 : En fait, on ne peut pas trouver quel signal est nécessaire si on n'a pas d'itinéraires.
Et, si on veut trouver les itinéraires dans une gare, il faut définir quels sont les zones qui la composent, avec les zones d'approche et de sortie, bien sûr. Dans un premier temps, on limitera les itinéraires aux gares.
Donc, voici ma démarche globale :
1°) Rentrer toutes les zones d'un réseau (nom des zones et des voisins)
Dans les segments, donner la position des signaux, ce qui donnera la parité des segments.
Dans les appareils de voie, pas de signaux et, je pense, pas de parité à rentrer.
-> Pour les traversées (croisements, TJS et TJD), on met la parité à "pairimpair"
-> Pour les autres aiguilles, la parité de l'appareil de voie est la parité de son unique point commun avec un segment dont on connait la parité.
Il faudra peut-être pousser un peu plus loin le raisonnement pour la parité des appareils de voie.
2°) Définir comme "gare" quelques zones pour calculer la gare entière.
3°) Définir comme "manœuvres" une zone pour calculer la zone de manœuvres entière.
4°) Trouver tous les itinéraires de chaque gare.
5°) Rentrer les infos complémentaires de vitesse des segments de la gare, ce qui donnera les vitesses des appareils de voie, branche par branche, en évitant les erreurs et les incohérences.
En déduire la signalisation correspondante.
Démarche pour définir une gare (voir le fichier gare) :
J'ouvre une ArrayList : "zones_gare" qui va collecter toutes les zones d'une seule gare, au fur et à mesure que le programme parcourt toutes les zones.
Une fois les zones rentrées, je déclare Z3 "gare", ce qui met "g0" dans le champ "gare" de la zone Z3.
Puis la recherche systématique commence. Elle est détaillée dans le fichier joint.
En ayant rentré une seule zone, on a décrit toute la gare.
Evidemment, cet exemple est très simple.
Il est basé sur le principe suivant : dans une gare, il n'y a jamais deux segments voisins.
Dans cette gare, il permet, à la fois, d'exclure Z0 et Z7 de la gare et de déclarer Z1 zone d'approche et Z6 zone de sortie.
Dans la gare de Dominique, ce seul principe ne suffit pas. Ça serait trop beau !
Il y a 2 gares : g0 au sud et g1 au nord.
On doit rentrer un segment dans g0 : j'ai choisi Z27
On doit rentrer 2 segments dans g1 (un pour le haut de la gare, un pour le bas car il n'y a pas de communication entre le haut et le bas de la gare g1) : j'ai choisi Z4 et Z22.
On n'a pas à s'occuper de la partie droite du schéma car on y trouve 2 segments consécutifs.
Z11 est une zone d'approche de g0, mais pas Z30
Z34 est une zone d'approche de g1, mais pas Z7
Pour la partie gauche, on ne peut pas utiliser le principe puisqu'il n'y a qu'une zone entre les deux gares et on aboutirait à une seule et unique gare.
Il faut donc préciser "à la main" les informations :
Z25 est la zone d'approche de g0 et Z16 est la zone d'approche de g1.
Les infos rentrées à la main sont prioritaires sur les infos crées par le programme.
Les zones de manœuvre :
Dans le réseau de Dominique, il y a aussi des zones de manœuvre. Et, si on n'y prenait pas garde, elles seraient, elles aussi, ajoutées aux gares, ce qui serait une erreur.
Il faut donc bloquer le processus en rentrant "bloque" dans les zones Z36, Z45, Z46 pour g0 et dans Z2 pour g1.
Maintenant, il faut décrire les zones de manœuvre.
A noter une chose importante : sauf cas particulier, on rentre dans la zone de manœuvre en marche arrière et on en sort en marche avant.
C'est le même principe que pour les gares, à ceci près qu'il n'y a pas besoin de bloquer, la gare s'en charge et, aux autres extrémités, tous les butoirs arrêtent le processus de recherche de zones.
On définit donc Z36 et Z37 où on rentre m0 dans le champ "manœuvres" des zones.
La dernière chose à définir, ce sont les zones d'approche des zones de manœuvres.
Là, je ne vois pas d'automatisation possible : il faut les définir à la main dans Z30 et Z16, champ "manœuvre". A noter, peut-être une piste : Z30 et Z16 sont les zones de sortie de la gare et je pense que ça n'est pas un hasard.
Résumé :
En rentrant 13 informations simples, on remplit 37 cases sans erreurs !
Fichiers joints :
https://www.locoduino.org/IMG/zip/editeur_json4.zip
Dans le .zip, on a ma dernière version du programme Processing, avec la création des gares et des zones de manœuvre. Mais je n'ai pas fait la partie "entrée des infos gare/manœuvre" : je les rentre directement dans le fichier Excel. C'est la prochaine chose que je vais faire. C'était juste pour tester le fonctionnement.
On ne pose plus de questions pour les vitesses dans la première phase, mais il faudra poser les questions dans les "compléments". A réaliser, donc
Je vais aussi ajouter la possibilité de modifier les informations dans une zone.
Les fichiers Excel décrivant les zones (avant et après) sont dans le .zip
Il y a aussi le fichier détaillé du processus de définition d'une gare.
Et, évidement, le plan du réseau de Dominique (toutes mes excuses pour cet oubli)
Denis
