Mais pourquoi avoir fait un réseau aussi moche ? 
Je suis bien d'accord qu'il n'est pas beau, c'est le moins que l'on puisse dire…
Je l'ai construit pour pouvoir tester tous les cas complexes, en me disant que, si ça marche avec un tel réseau, ça n'en sera que plus facile avec un réseau "normal".
Voyons dans le détail les pièges qu'il recèle. 
Z0 :Une zone courte pour savoir comment gérer un train long qu'on poserait là pour démarrer.
En fait, c'est comme si le train sortait d'un tunnel et on voit apparaître les véhicules au fur et à mesure de l'avancement du train.
Cet effet n'est utilisé que dans ce cas. Après, plus aucun véhicule ne disparaît (heureusement)
Par ailleurs, c'est une zone mixte qui comporte à la fois des AV (Appareils de Voie) et SAV (Sans Appareil de Voie) et que, comme on ne met pas de signal sur un AV, il est placé automatiquement en retrait du (ou des) AV de fin de zone.
Enfin, côté butoir, la cible apparait également en retrait, ce qui n'est pas le cas à la SNCF.
En effet, si on doit mettre un feu côté butoir, ce feu est SUR le butoir.
Une chose à corriger.
Z1 :Une voie de garage classique.
Vous n'allez pas le croire : quand on part de Z0, c'est la zone qu'on trouve en dernier en recherche d'itinéraires, après 172 itérations !!
Cela est dû au fait que, comme l'aiguille de Z0 est en position tout droit, il faut avoir exploré toutes les autres solutions avant qu'on change la position de l'aiguille dans l'algorithme de recherche et qu'on trouve (enfin !) Z1. Mais cela ne prend que quelques milli secondes.
Z2 :Zone mixte simple. Pour moi, la première fois que l'itinéraire trouvait un pavé "à l'envers".
On voit aussi, à gauche, une cible à moitié "mangée" par la voie du niveau inférieur.
Très facile à régler en décalant d'1/2 carreau vers la droite le niveau inférieur.
Ce bug pourrait aussi être réglé en dessinant les choses dans un autre ordre (les signaux en dernier), mais l'ordre choisi est celui qui est le plus rapide à dessiner et le temps est ce qu'il y a de plus dur à trouver dans un gestionnaire. J'y reviendrais.
Z3, Z4 :Rien à dire de particulier.
Z5 :Une aiguille triple. Plus complexe à gérer, avec une subtilité inhérente à sa construction à partir de formes (l'une des formes est "à l'envers" par rapport aux autres).
L'aiguille aurait pu être liée à la Z4, mais j'ai voulu tester une zone d'aiguille isolée.
Z6 :J'ai volontairement omis le butoir pour cette voie de garage.
C'est une hérésie pour la SNCF, évidemment.
Mais je voulais que ce type d'erreur dans le dessin du réseau ne génère pas de plantage de l'application.
En fait, j'ai résolu le problème en ce sens qu'on ne peut pas sélectionner cette extrémité libre. On ne peut ainsi pas aller vers cette absence de butoir. La seule solution est donc de retourner dans l'éditeur et de rajouter un butoir.
Z6, Z7, Z8 :Rien à dire de particulier.
Z9 :Gestion d'une TJD.
Là, je peux dire que ça n'a pas été facile car il y a, à priori, de nombreux cas à gérer.
Jusqu'à ce que je remarque qu'en fait, on est en présence d'une aiguille simple pour chaque entrée !
De quelque côté qu'on aborde une TJD, on n'a qu'un seul choix : tout droit ou dévié.
En fait, c'est un peu plus complexe, mais l'idée est là.
Le cas d'une TJD qui servirait à faire une boucle de retournement est aussi traité.
Z10, Z11 :Rien à dire de particulier.
Z12 :Il fallait bien traiter le cas d'une zone qui soit sur deux niveaux. C'est le cas ici.
Beaucoup plus complexe qu'on pourrait le penser de prime abord.
De plus, c'est une boucle de retournement (voir Z15 à Z20).
Z13 :La première zone comportant deux aiguilles.
Z14 :Cette zone, coincée entre deux boucles de retournement, n'a pas posé de problèmes particuliers pour la recherche d'itinéraires, mais plus tard, lors de l'affichage des itinéraires.
Il faut afficher, de la bonne couleur et effacer au bon moment.
Z15 à Z20 :Là, on attaque un gros morceau.
Dans l'approche la plus basique de recherche d'itinéraires, si on repasse deux fois au même point, on abandonne la branche concernée.
Dans le fil de Jean-Luc (
http://forum.locoduino.org/index.php?topic=167.30) de … 2016, il explique bien pourquoi il faut tenir compte du sens de passage quand on fait les recherches.
En particulier pour la boucle de retournement, évidemment.
Donc, si, en continuant la recherche en marche avant, on repasse par le même point, c'est qu'on est passé par une boucle de retournement.
On doit donc reculer dans la recherche pour revenir à ce point et repartir en avant pour parcourir la boucle dans l'autre sens !
C'est absolument indispensable pour pouvoir choisir n'importe quel point (signal) de la boucle.
J'ai compliqué le problème en mettant une voie d'évitement, pour pouvoir vérifier que tous les cas soient traités.
Z21 :J'ai voulu vérifier qu'on arrivait bien à positionner les signaux sur un simple pavé, qui plus est en courbe. Et ça marche.
Une telle disposition n'aurait aucun sens à la SNCF, bien sûr. C'est un essai.
Accessoirement, je me suis posé la question de savoir si on devait allumer toute la zone Z21 en rouge (= occupation) si on allait, par exemple de Z23 à Z12.
Quand je dis "toute", je veux parler du pavé arc de cercle 45° qui ne fait pas partie du trajet.
Je ne trouve pas ça d'une esthétique folle, mais c'est indispensable à la logique SNCF : Si une zone est occupée, elle est toute entière allumée en rouge.
Z22 et Z23 :Initialement, je n'avais mis qu'une zone, pour régler un autre problème soulevé par Jean-Luc, toujours dans le même fil.
La question était de ne faire qu'un seul passage dans la recherche d'itinéraires, de ne pas tourner en rond ad vitam aeternam.
Pas de problème, ça, ça marche.
Mais un autre problème, plus sournois, est apparu si on ne fait qu'une seule zone :
Un train dans la boucle et qui voudrait la parcourir (position des aiguilles de Z21 en position tout droit, comme sur le schéma) ne le pourrait pas !!
Si vous regardez bien, les signaux de la boucle seraient tous deux à SEMAPHORE…
Donc, OK pour une boucle ronde, mais avec un minimum de deux zones… et un train plus court que la plus petite des zones (je développerais plus tard cette intéressante question plus générale)
Dernière remarque sur le schéma des zones :J'avais pensé faire afficher par le programme le nom des zones.
Outre que ça n'est pas si évident que ça à faire, je pense que c'est inutile.
Je ne me sers jamais des noms des zones dans le programme et je viens seulement de réaliser ce dessin, en mettant le nom des zones directement à la main dans l'image.
Dans l'éditeur, j'ai bien besoin de nommer les zones (qui sont des ensembles de pavés), mais il faut juste que deux zones n'aient pas le même nom. C'est tout.
Apparaissent aussi les signaux, ce qui va me permettre de parler de la signalisation.
La signalisation
A la SNCF, on étudie la situation de chaque signal et on définit les conditions d'allumage de chaque feu. C'est forcément la meilleure méthode qui résout la totalité des cas rencontrés, y compris les plus complexes. C'est aussi la seule qui réponde à toutes les situations.
Cette méthode est appliquée par Pierre59 dans son article sur un gestionnaire en C++
http://www.locoduino.org/spip.php?article167Y est décrit la façon permettant de se rapprocher le plus possible de la solution SNCF et c'est, en plus, un excellent article pour comprendre la programmation objet.
J'y ai appris de nombreuses choses et je programme aussi avec des objets (c'est génial).
Malheureusement, comme, par définition, je ne connais pas le réseau qui va être décrit, il faut que je travaille avec des règles plus générales, ce qui résout toutefois la quasi-totalité des cas rencontrés et, en particulier toutes les situations tordues de mon réseau d'essai.
Vous remarquerez que le schéma du réseau ne mentionne aucun numéro de signal, parce que ça ne me sert pas :
c'est le programme qui fait les calculs tous seul.Supposons que, d'un coup de baguette magique, je connaisse le signal suivant de chaque signal.
J'ai bien dit le suivant (dans les deux sens de circulation), tenant compte de la position des différentes aiguilles du réseau.
Je peux alors appliquer quelques règles simples (dans l'ordre) :1°) S'il n'y a pas de signal suivant, je mets mon signal au CARRE.
Cela arrive dans le cas des butoirs (ce n'est pas, au sens strict, un CARRE, mais, en tout cas, c'est infranchissable !) et dans le cas des aiguilles prises en talon, lorsque c'est l'autre direction qui est sélectionnée.
2°) Si, pour aller au signal suivant, je rencontre un pavé occupé, je mets SEMAPHORE.
3°) Si le signal suivant est à CARRE ou SEMAPHORE, je mets l'AVERTISSEMENT.
4°) Si, pour aller au signal suivant, je rencontre une aiguille en position déviée limitée à 30 km/h (ou 60 km/h), je mets le signal à RAPPEL DE RALENTISSEMENT (30/60).
5°) Si le signal suivant est à RAPPEL DE RALENTISSEMENT (30/60), je mets RALENTISSEMENT (30/60).
On remarquera un aspect sympa : tout en recherchant le signal suivant, on peut noter, au passage, si on a rencontré un pavé occupé, une aiguille avec ralenti en position déviée. On ne perd pas de temps.
Comment marche la "baguette magique" ?En fait, cela ressemble à une recherche d'itinéraire, mais en beaucoup, beaucoup plus simple :
1°) On ne va pas loin, on va juste au signal suivant.
2°) On ne change aucune position d'aiguille (surtout pas !) et donc c'est nettement plus rapide.
Quand je vous exposerai ma gestion des itinéraires améliorée, je parlerai du cas des carrés manuels automatiques qui s'ajoute aux cas précédents.
PS : si vous avez à gérer des cas qui ne sont pas décrits dans mon réseau d'essai, n'hésitez pas à m'en faire part pour que je les intègre. Je veux que ça marche partout.
