Auteur Sujet: Projet partagé d'un gestionnaire de réseau  (Lu 320203 fois)

DDEFF

  • Hero Member
  • *****
  • Messages: 822
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #570 le: avril 22, 2025, 09:16:03 am »
Bonjour Pierre,

Finalement, je propose de renommer les "super-appareils" en "claviers", avec des boutons, car c'est vraiment à ça que ça correspond.

Pour un aiguillage simple, un clavier à 2 boutons (on ne gagne rien)

Pour une TJD, un clavier à 4 boutons (on ne gagne rien)

Pour une TJS, un clavier à 3 boutons (on gagne déjà un bouton)

Pour une bretelle double, on a un clavier à 3 boutons (on gagne 7 boutons).
Il y a, en effet, 5 appareils (4 aiguillages et une traversée) qui sont, chacun, à 2 boutons, soit 10 boutons.
Et, en combinaison de boutons, on a 2^5 = 32 combinaisons dont seulement 3 sont utiles !
Et j'insiste bien : dans la bretelle double, il y a bien les 7 zones (une par appareil + une section en haut et une section en bas).

Pour l'ancien "SU19", appelé maintenant "CLV19", pour "Clavier 19", on a 4 boutons.
Comme il y a 3 appareils à 2 boutons, on gagne 2 boutons, mais on passe de 2^3 = 8 possibilités à 4 seulement.

-----------------------------------------------------------------------------------------------------------------------------------------
Je vais maintenant expliquer, dans le détail, ce que j'ai compris de ton programme.

Tu utilises HashMap, ce qui permet de gérer des valeurs nulles.

On démarre dans le simple avec des zones qui ne gèrent que des signaux, pairs et impairs.

On lit l'objet "json", globalement.

On définit l'objet "zones", l'une des clés. Puis les autres objets (signaux, …).
Si j'ai bien compris, on devra citer tous les objets dans le JSON car HashMap n'accepte qu'une clé nulle. Mais leur valeur pourra être nulle.
Dit autrement, je devrai avoir une clé "itinéraire", même si je ne les définis pas. Cela explique peut-être pourquoi ça plantait.

Puis tu définis la HashMap "tableZones".

Si j'ai bien compris, la clé est une variable de type String, et la valeur est un objet "zone".

Puis tu fais une boucle forall. Après, la syntaxe est plus floue…
Tu balaie toutes les clés des zones en mettant en String le nom des zones ?

Le reste de la boucle est clair :
On crée une nouvelle zone.
On ajoute à TableZones un couple (z, zone), z étant une String, celle du balayage, et une zone vide en valeur.
Pareil pour TableSignaux avec un couple (z, signal).

Démarre la phase 2.

On rebalaie toutes les zones.
Là, j'ai encore un problème de syntaxe avec getString("signI", null). Je ne vois pas d'où sort le null.

Après, c'est clair : tu définis la zone, fonction de z, et tu remplis signalI et signalP

C'est une bonne idée d'avoir démarré par une zone et les signaux, car il n'y a que des objets. Quand on arrivera aux ArrayList, ça va être plus coton.

Merci Pierre

Denis :P
« Modifié: avril 22, 2025, 09:34:41 am par DDEFF »
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 385
    • Voir le profil
Re : Re : Projet partagé d'un gestionnaire de réseau
« Réponse #571 le: avril 22, 2025, 10:23:37 am »
Je vais maintenant expliquer, dans le détail, ce que j'ai compris de ton programme.

Tu utilises HashMap, ce qui permet de gérer des valeurs nulles.
==> une hashtable c'est un ensemble de clé/valeur, les clés ne peuvent pas êtres nulle, les valeurs oui mais cela n'a pas grand intérêt. Ici on s'en sert pour associer un nom (string) a une instance, par exemple associer au nom d'une zone à son instance.
Citer
On démarre dans le simple avec des zones qui ne gèrent que des signaux, pairs et impairs.

On lit l'objet "json", globalement.

On définit l'objet "zones", l'une des clés. Puis les autres objets (signaux, …).
Si j'ai bien compris, on devra citer tous les objets dans le JSON car HashMap n'accepte qu'une clé nulle. Mais leur valeur pourra être nulle.
Dit autrement, je devrai avoir une clé "itinéraire", même si je ne les définis pas. Cela explique peut-être pourquoi ça plantait.
==> je ne comprends pas bien ce que tu veux dire, les hashmap utilisent des clés et des valeurs non nulles.
Citer
Puis tu définis la HashMap "tableZones".

Si j'ai bien compris, la clé est une variable de type String, et la valeur est un objet "zone".
==> tout à fait
Citer
Puis tu fais une boucle forall. Après, la syntaxe est plus floue…
Tu balaie toutes les clés des zones en mettant en String le nom des zones ?
==> on balaye le Json pour obtenir tous les noms des zones (string).
Citer
Le reste de la boucle est clair :
On crée une nouvelle zone.
On ajoute à TableZones un couple (z, zone), z étant une String, celle du balayage, et une zone vide en valeur.
Pareil pour TableSignaux avec un couple (z, signal).

Démarre la phase 2.

On rebalaie toutes les zones.
Là, j'ai encore un problème de syntaxe avec getString("signI", null). Je ne vois pas d'où sort le null.
==> null c'est la valeur par défaut si on ne trouve pas la clé "signI" dans le Json de la zone concernée.
Citer
Après, c'est clair : tu définis la zone, fonction de z, et tu remplis signalI et signalP

C'est une bonne idée d'avoir démarré par une zone et les signaux, car il n'y a que des objets. Quand on arrivera aux ArrayList, ça va être plus coton.
==> c'est vrai que ce sera plus difficile, mais le choix était volontaire.

Pierre

PS de Dominique : pour une meilleure lisibilité j'ai juste inséré "[/quote]" devant les "==>" et le même sans "/"  après  :D
« Modifié: avril 22, 2025, 10:46:18 am par Dominique »

DDEFF

  • Hero Member
  • *****
  • Messages: 822
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #572 le: avril 22, 2025, 10:48:43 am »
Citer
Si j'ai bien compris, on devra citer tous les objets dans le JSON car HashMap n'accepte qu'une clé nulle. Mais leur valeur pourra être nulle.
Dit autrement, je devrai avoir une clé "itinéraire", même si je ne les définis pas. Cela explique peut-être pourquoi ça plantait.

==> je ne comprends pas bien ce que tu veux dire, les hashmap utilisent des clés et des valeurs non nulles.

Dans ton "lecture_json()" du précédent programme, tu attendais des clés "itineraires", "auts", "trains" qui ne figurent pas dons mon JSON.
Donc, ce sont des clés de valeur nulle et il n'a pas aimé...
Dit autrement, il faut que dans mon JSON, je mette aussi ces clés, quitte à ce qu'elles soient vides.

Denis :P
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 385
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #573 le: avril 22, 2025, 10:56:54 am »

Faut laisser tomber, pour l'instant, les clés "itineraires", "auts", "trains", ...

Pierre

Pierre59

  • Sr. Member
  • ****
  • Messages: 385
    • Voir le profil
Re : Re : Projet partagé d'un gestionnaire de réseau
« Réponse #574 le: avril 22, 2025, 11:19:30 am »
Bonjour Pierre,

Finalement, je propose de renommer les "super-appareils" en "claviers", avec des boutons, car c'est vraiment à ça que ça correspond.

Pour un aiguillage simple, un clavier à 2 boutons (on ne gagne rien)

Pour une TJD, un clavier à 4 boutons (on ne gagne rien)

Pour une TJS, un clavier à 3 boutons (on gagne déjà un bouton)

Pour une bretelle double, on a un clavier à 3 boutons (on gagne 7 boutons).
Il y a, en effet, 5 appareils (4 aiguillages et une traversée) qui sont, chacun, à 2 boutons, soit 10 boutons.
Et, en combinaison de boutons, on a 2^5 = 32 combinaisons dont seulement 3 sont utiles !
Et j'insiste bien : dans la bretelle double, il y a bien les 7 zones (une par appareil + une section en haut et une section en bas).

Pour l'ancien "SU19", appelé maintenant "CLV19", pour "Clavier 19", on a 4 boutons.
Comme il y a 3 appareils à 2 boutons, on gagne 2 boutons, mais on passe de 2^3 = 8 possibilités à 4 seulement.

Je ne vois pas bien ce que vient faire ici ce mégotage de boutons, de toute façon on va par la suite commander les aiguilles par les itinéraires.

On est dans un gestionnaire, et on va avoir besoin des voisins des zones, c'est de cela dont il faut s'occuper maintenant.

Ton idée d' "appareil" de voie était séduisante. Je vois plusieurs "appareils" possibles : l'aiguille simple, deux aiguilles en bretelle, le croisement, la TJD, la TJS, l'aiguille triple, la bretelle double. Comment pourrait on coder tout cela.

Je ne vois pas du tout l'utilité du SU19 (quelque soit son nom), on a une bretelle (a15 et a16) et une aiguille (a13).

Pierre
« Modifié: avril 22, 2025, 06:02:38 pm par Pierre59 »

DDEFF

  • Hero Member
  • *****
  • Messages: 822
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #575 le: avril 22, 2025, 01:54:16 pm »
Le fait qu'on travaille avec des itinéraires ne change pas le fait que si on a plus d'appareils, ayant chacun plus de positions, on allonge le temps de traitement.

Dans la liste des appareils, il faut ajouter la bretelle double.

En PJ, le plan d'une bretelle double.

Voici ma façon de décrire ça :
(j'ai viré les balises et la parité, pour l'instant, et chaque moteur d'aiguille a, comme numéro, son numéro de zone)

"appareils" : {
            "a600" : {
                     "nom" : "a600",
                     "type" : "bretelle double",
                     "liste" : [["a60", "droite", "a63", "droite", "a66", "droite"],
                               ["a64", "gauche", "a63", "gauche", "a62", "gauche"],
                               ["a60", "gauche", "a62", "droite", "a64", "droite", "a66", "gauche"]],
                      "no" : 8
            }
},
"zones" : {
            "Z60" : {
                    "nom" : "Z60",
                    "voisP" : "Z220",
                    "voisI" : [["Z221","a600","2"],["Z231","a600","0"]],
                    "no" : 48
            },
            "Z61" : {
                    "nom" : "Z61",
                    "signI" : "C11",
                    "voisP" : "Z62",
                    "voisI" : "Z60",
                    "no" : 49
            },
            "Z62" : {
                    "nom" : "Z62",
                    "voisP" : "Z221",
                    "voisI" : [["Z220","a600","2"],["Z230","a600","1"]],
                    "no" : 50
            },
            "Z63" : {
                    "nom" : "Z63",
                    "voisP" : [["Z60","a600","0"],["Z64","a600","1"]],
                    "voisI" : [["Z66","a600","0"],["Z62","a600","1"]],
                    "no" : 51
            },
            "Z64" : {
                    "nom" : "Z64",
                    "voisP" : "Z230",
                    "voisI" : [["Z65","a600","2"],["Z63","a600","1"]],
                    "no" : 52
            },
            "Z65" : {
                    "nom" : "Z65",
                    "signI" : "C13",
                    "voisP" : "Z66",
                    "voisI" : "Z64",
                    "no" : 53
            },
            "Z66" : {
                    "nom" : "Z66",
                    "voisP" : "Z231",
                    "voisI" : [["Z230","a600","2"],["Z220","a600","0"]],
                    "no" : 54
            },
            "Z220" : {
                    "nom" : "Z220",
                    "signI" : "C15",
                    "voisP" : "Z60",
                    "voisI" : ["Z24"],
                    "no" : 57
            },
            "Z221" : {
                    "nom" : "Z221",
                    "signI" : "C17",
                    "voisP" : "Z35",
                    "voisI" : "Z62",
                    "no" : 58
            },
            "Z230" : {
                    "nom" : "Z230",
                    "signI" : "C19",
                    "voisP" : "Z64",
                    "voisI" : "Z24",
                    "no" : 59
            },
            "Z231" : {
                    "nom" : "Z231",
                    "signI" : "C21",
                    "voisP" : "Z35",
                    "voisI" : "Z66",
                    "no" : 60
            },
    },


Denis :P
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 385
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #576 le: avril 22, 2025, 03:13:45 pm »

Dans ta bretelle double il y a trop de zones et de signaux.

C11 et C13 ne servent pas à grand chose.

Deux zones suffisent pour toute la bretelle (Z61 et Z65), la coupure des zones se fait au milieu du croisement.


Par ailleurs si tu veux réaliser ta gare, ce genre de bretelle est insuffisant, il faut pouvoir remplacer chaque aiguille par une TJD,TJS,Croisement, …

Pierre

DDEFF

  • Hero Member
  • *****
  • Messages: 822
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #577 le: avril 22, 2025, 03:41:15 pm »
En PRS, il faut découper au maximum et c'est très luxueux.
Évidement, en PRA, on peut regrouper les zones.

Et je suis d'accord que les signaux C11 et C13 sont très très luxueux.
C'est un réseau d'essais et je voulais caser une bretelle double, elle même très luxueuse.

Denis :P

"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

DDEFF

  • Hero Member
  • *****
  • Messages: 822
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #578 le: avril 23, 2025, 09:22:33 am »
Bonjour,

Quand je regarde la programmation avec les nouveaux appareils, je me rends compte qu'il y a plus d'homogénéité dans la description du réseau.
Du côté des zones, pour les voisins, on a :
     - soit une zone seule (ex : "voisP" : "Z220",)
     - soit 2 ArrayList dans une ArrayList (ex : "voisI" : [["Z221","a600","2"],["Z231","a600","0"]],)

Dans chaque ArrayList, les éléments sont toujours les mêmes :
     - un nom de zone
     - un nom d'appareil
     - un numéro de liste
C'est très régulier.

Du côté de l'appareil, on a, pour la liste, une ArrayList contenant plusieurs ArrayList.
Chacune de ces ArrayList a une structure répétitive : un numéro de moteur + (gauche ou droite).

Cette régularité doit simplifier la programmation de la lecture du JSON.

Denis :P
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 385
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #579 le: avril 23, 2025, 11:19:52 am »
Juste une petite remarque, dans les fichiers Json les nombres (entiers ou réels) s'écrivent sans double quote ; 22 3.14

Pierre

DDEFF

  • Hero Member
  • *****
  • Messages: 822
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #580 le: avril 23, 2025, 11:53:44 am »
Bien sûr.
La raison pour laquelle je faisais ça, c'est que je pensais utiliser des StringList au lieu d'ArrayList.
Sauf que, je viens de regarder : C'est JsonArray. Donc, on n'a pas le choix.

Denis :P
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)