* (DV 08/02 p.51) - un chantier pourrait être lancé sur la question de "cartographie dynamique". Inexpérience totale de ce qu'il faut prévoir pour coller des données informatiques et des images vectorielle. La première étape serait exploratoire et consisterait à faire de la pédago.

- une petite idée se fait jour quant à la réalisation de "fonds cartographiques" vectoriels (motus la dessus pour l'instant),

* (Pierre Cendret 8 février p.51) - Pour la gestion du positionnement j'ai trouvé l'algorithme GPS -> Carte (France métropolitaine ) (merci IGN) et des cartes de France libre de droit pour utilisation à but non lucratif (merci IGN). Dans un premier temps on pourrait prendre l'information IGN de la commune c'est à dire sa mairie. Prend-t-on en compte l'altitude cela peut-être utile pour connaître le dénivelé d'une ligne ou d'un nœud. Avec un champ indiquant si l'information concerne l'établissement ou la commune.

Cette application fonctionne dans les deux sens car en pointant sur la carte sur un élément (ici une gare par exemple), on affiche les éléments concernant cette gare contenus dans la base de donnée.

Le résultat est impressionnant de convivialité et de réalisme car les cartes existent avec le relief, en plusieurs échelles, plus ou moins renseignées (relief, limites administratives, infrastructure…)

Les logiciels de GIS ont pour inconvénient d’être chers. Du moins pour ceux que je connais. ARCVIEW par exemple (pas d’actions dans le produit…hélas..). Ils sont aussi lourds informatiquement (ordinateurs puissants pour affichage notamment…). Je sais qu’il existe des versions pour Internet qui sont différentes mais je n’ai jamais utilisé…

Au-delà du ou des spécialiste à trouver pour réaliser, il faut des petites mains pour déterminer puis saisir les coordonnées les gares (ou autres) sous une forme latitude longitude, donc longue série de chiffres qui ne supportent pas la moindre erreur

En tout cas cela vaut la peine de se renseigner car c’est vraiment bluffant …

* (Chat 08/02 p.53) Déjà dans un sens, avec affichage d'une portion de carte, c'est un énorme travail. Progressons petit à petit!

Technique : par des gens qui s'y connaissent en informatique (=> je sors...)

Administration : si on m'explique comment marche le bazar, je peux me charger d'une partie de l'administration.

Contrôle des données : là, on peut tourner sur une plus grande échelle. En effet, ce qui se fait en général dans des cas comme celui-ci, c'est de demander à un spécialiste de vérifier le travail de saisie d'un autre spécialiste !

* (CendretP 08/02 p.52)... Tout à fait d'accord avec Canard ! Et de plus, l'administration, si administration il doit y avoir, sera a assumer à plusieurs à tour de rôle bien évidemment ! Mais on en est pas encore là ...

* (GP_91 08/02 p.52) Oui pour une charte graphique

- Pour la base donnée à partir de 2 informations possibles, il faut en général extrapoler à n pour prévoir tous les cas de figure, c'est plus difficile à développer mais plus simple à maintenir (on ne réécrit pas tout le programme si on autorise une date ou saisie 3 dates) et la maintenance d'un produit informatique est d'environ 50% de son temps de développement.

- Le gestion des lignes et nœuds peut être très complexe informatiquement parlant (il faut que je retrouve mes algorithmes du voyageur de commerce) si il n'y a pas de pk et de sens.

- Pour la gestion du positionnement j'ai trouvé l'algorithme GPS -> Carte (France métropolitaine ) (merci IGN) et des cartes de France libre de droit pour utilisation à but non lucratif (merci IGN). Dans un premier temps on pourrait prendre l'information IGN de la commune c'est à dire sa mairie. Prend-t-on en compte l'altitude cela peut-être utile pour connaître le dénivelé d'une ligne ou d'un noeud. Avec un champ indiquant si l'information concerne l'établissement ou la commune.

- La gestion de nom des gares multiples doit être décidé rapidement car l'on passe d'un champ dans un fichier à un fichier ce qui ne se gère pas informatiquement du tout de la même façon et avec toujours dans ce cas d'historique ou de choix multiple le problème "quel nom afficher ? et Quoi rechercher ?"

- Pour les dates, il faut se définir des formats (jj/mm/aaaa, mm/aaaa, aaaa, Trimestre/aaaa) à partir de cela informatiquement tout est possible. Il faudra définir un champ au format date qui reprendra par exemple le début de chaque période (ex 1994 -> 1/1/1994) et un champ précision indiquant le type de saisie (année seul, mois+année) pour conservé l'information d'imprécision. Il vaut mieux éviter le champ libre qui ne permet pas facilement de tri et de recherche.

- Je n'ai pas encore regardé la base de donnée, je n'ai pas Access d'installé je travaille sous SQL Serveur 2005 (Version Beta) et j'ai un pb d'outil d'importation. J'installe Access sur une machine virtuelle et je te dirais quoi.

(9H00) Je dis quoi je viens de voir l'image de la base.

- Le problème est la gestion de l'historique, car cela implique une lecture dans le fichier principal et l'historique, il faut mieux gérer l'information comme pouvant avoir un historique. C'est à dire par exemple que le nom de l'établissement n'est pas définie dans l'établissement mais dans un fichier nom des établissements avec un lien vers établissement un champ date début - date fin (pouvant être vide) et peut être un bool nom usuel pour facilité l'affichage. (Idem pour les informations multiples (plans , photos, ...)

- Le projet de développement devra être monté par étape même si la base est préparée de façon global (principe de l'artichaut soit on le mange en entier et on meure étouffé soit on le mange feuille par feuille et on se régale) .

Il faudra définir les étapes.

(DV 08/02 p.51) Je vais donc un peu jouer au Candide et tâcher de retranscrire en termes non techniques les options prise, afin de suivre si cela colle avec nos idées et prétentions de ferroviphiles. Cela aura le mérite de permettre aux non informaticiens de voir comment progresse le projet et ce que nous pourrons escompter en tirer. 

(chat 08/02 p.52)Mon petit grain de sel dans l'organisation exemplaire de Daniel: la création de trois fils secondaires et spécialisés dans le forum LR.

Ceux qui suivent ce projet d'un peu moins près quand une discussion particulière s'emballe peuvent ainsi suivre les parties qui les intéressent et tout le monde reste donc bienvenu.

Je verrais bien:

- Nomenclature ferroviaire, le coin des bidouilleurs

- Nomenclature ferroviaire, le coin des bénédictins

- Nomenclature ferroviaire, le coin des artistes

... respectivement, pour les informatheux, les saisissants et les photogéographes. 

(chat 08/02 p.52) Le site une fois fonctionnel (je n'ai pas dit terminé) sera une mine incomparable pour pas mal de gens, mais il demandera beaucoup d'efforts de bénévoles et de quelques petits moyens pour vivre sa vie (achat de matos, écot du FAI, voire défraiement de l'administrateur pour un exercice particulier).

Que diriez-vous de quelques bannières strictement sélectionnées et en rapport ferrovico-géographico-touristique avec la ligne affichée par l'utilisateur?

Par exemple, offices du tourisme de la région / des communes, "En voyage", LR Presse…

* (Chat 09/08 p.54) Ce n'est pas un scoop: XTof a bien travaillé, évidemment Cool

Je ferai ici quelques commentaires pour tous quand on aborde des sujets généraux qui peuvent intéresser les passionnés, et les détails techniques passeront directement entre les protagonistes. Si vous voulez éclaircir l'un ou l'autre des termes jargonnants des informatheux, j'ajouterai les explications correspondantes quand je les connais!

Ligne et sous-ligne: XTof, dans son modèle, fait appel à une table de sous-lignes. Cette table décrit le fait qu'une ligne est composée de... lignes! Quand on définit un terme en faisant appel à lui-même, on est dans la question de la poule et de l'oeuf direz-vous.

Ceci ne gêne ni les matheux, ni les informaticiens.

Nous faisons appel à la notion de récursivité.

La table des sous-lignes de XTof décrit la liste des lignes qui composent une ligne donnée. Reprenons un exemple déjà donné.

- Genève-Lausanne est la ligne 149,

- Genève-Nyon, 1er tronçon de celle-ci, est nommé 149.1,

- Pont-Céard-Versoix 12ème tronçon de celle-ci devenant 149.1.12.

Ces trois lignes sont toutes les trois décrites par la table des lignes.

Quand j'utilise la notion de tronçon, j'indique que la ligne 149.1 par exemple fait partie de la ligne 149.

Dans la table des sous-lignes, j'exprimerai ceci par un enregistrement.

Cet enregistrement signifie qu'une ligne est un tronçon d'une autre: et voilà! Très fort, le XTof Cool

C'est l'application du principe de récursivité.

Quel intérêt? Et bien ce principe en a justement beaucoup: plus besoin de trouver un nom pour chacun des niveaux d'agrégation puisqu'il y en a autant qu'on veut.

C'est comme dans un arbre généalogique avec N niveaux de filiation.

Chacun des portraits est une ligne, chacun des traits exprimant une filiation est une sous-ligne.

* (DV le 09/02 p.54) Ligne, nœud, section, établissement, ouvrage et pk : Normalisation, pour verrouiller une fois pour toutes les définitions.

Nœuds et sections permettent de décrire le réseau ferroviaire et tout son maillage. Une notion de hiérarchie est en train d'être établie pour nommer par code des séquences logiques, géographiquement et/ou historiquement, de nœuds et de sections.

Ligne est à mes yeux est la plus grande séquence possible de nœuds et sections, rien de plus. Si l'on veut nommer une sous-ligne, appelons la tronçon. Mais pour moi c'est clair, une section est bornée par deux nœuds à ses extrémités. Elle est élémentaire et n'a jamais de nœud sur son parcours (ce serait alors un tronçon de deux sections).

Etablissements et ouvrages ferroviaires (on retient ouvrage au lieu de 'élément' et 'objet') sont placés sur le maillage.

Les établissements peuvent être confondus à des nœuds (gares de bifurcation ou autres établissements distincts en description mais liés à ces gares par le même pk = gare de Villeneuve-Saint-Georges et triage de VSG), mais il y a des nœuds sans établissements (bifurcations de pleine ligne).

Les ouvrages ferroviaires peuvent être isolés et positionnés par leur pk propre sur une section (viaduc, tunnel), ou bien être des composants appartenant à un établissement et se voir attribuer le même pk de que l'établissement dont ils relèvent (exemple - établissement : gare de Bois-le-Roi = pk x,yyy, composé de BV, HM, Château d'eau reprenant chacun le même pk. x,yyy)

* (Chat 09/02 p.55) D.Vauvillier a écrit:

hem... ben justement, c'est pas pour être désagréable mais il reste un petit problème: j'y viens...

... exact mais au plus bas niveau seulement, c'est à dire le graphe sans tenir compte de la notion de ligne: c'est toute la finesse!

... aux miens, ceci se traduit très différemment, désolé...

-----------------------------------

"Une ligne est définie par:

- n'importe quelle séquence de sections consécutives,

et par:

- une liste de lignes dont chacune est constituée entièrement de sections appartenant à cette séquence."

-----------------------------------

Je m'explique.

Séquence, car l'ordre fait partie de l'information.

Sections exprime le fait qu'une ligne est une agrégation de sections.

Consécutives, car le nœud d'arrivée de la section N doit être le nœud de départ de la section N+1.

Liste, car ici l'ordre est indifférent.

Lignes, car XTof nous a concocté une hiérarchie en utilisant la récursivité.

constituée ... séquence permet de faire comprendre à nos stupides ordinateurs qu'une sous-ligne est un morceau de la ligne.

Corollaire: on peut afficher le nœud de départ et le nœud d'arrivée.

L'utilisateur ne voit que cela, ainsi éventuellement que la suite des sections qui composent la ligne et / ou la liste des lignes filles de celle-ci.

Pourquoi ne pas définir une ligne par ses nœuds de départ et d'arrivée?

Parce que si on fait çà, il faudra rechercher les sections par un algo de plus court chemin alors qu'on avait déjà l'information...

Mais pour l'utilisateur on voit les deux concepts se rapprocher ainsi:

- Une section est définie par ses nœuds de départ et d'arrivée,

- Une ligne est définie par une suite de sections et affiche le nœud de départ du premier et le nœud d'arrivée du dernier.

Une ligne se comporte donc comme une agrégation de sections, que le puriste nommera une section agrégée: c'est l'effet de zoom.

XTof a ajouté à ceci la notion de récursivité dont je vous ai touché un mot... ou deux! 

Oh oui, encore, c'est bon

c'est-à-dire en termes barbares qu'ils possèdent une localisation.

* (Chat 09/02 p.55) C'est vraiment tout un voyage d'entrer dans des cartes comme celles-ci, et n'oublie pas que ce n'est pas très loin de chez moi...

Mais revenons à ta question:

Première mise en garde: mes bagages me permettent de contribuer aux spécifications de structure et d'interface, mais j'ignore beaucoup de choses dans les systèmes géographiques informatisés, donc je peux bien sûr être contredit par plus spécialiste que moi (et par le chef bien sûr).

Au niveau informatique, il est peu réaliste de espérer qu'on obtiendra un tel luxe de détails tels que les courbes de niveau et ombrages, et tout était patiemment dessiné à la main à l'époque...

Pour les classes de localisation, l'astuce à laquelle recouraient les artistes à l'époque était d'attribuer une police de caractères différente à chaque classe - pourquoi pas nous?

En fonction de l'échelle et des possibilités du site, on verrait plus ou moins de choses à l'écran.

Nos géomaticiens pourraient nous fournir une vue simplifiée par des segments de droite (c'est-à-dire vectorielle) pour les sections de ligne, voire selon les données dont ils disposeront, des routes et cours d'eau par exemple.

Quant au carré de 20 x 30, ce n'est qu'un exemple.

On verra ce que nos programmeurs pourront nous concocter en pratique: image de taille fixe ou variable, échelle de zoom continue ou par paliers.

Alors au final, suffisant ou pas suffisant?

Cela dépend de ce que tu cherches à voir, et quand dans la vie courante on choisit une carte de France ou d'état major, ici on pourra choisir l'échelle pour afficher selon la granularité désirée, et selon les informations disponibles.

Chers bénédictins, à vos plumes pour nous alimenter!

* (Chat 09/02 p.55) Parmi les plus beaux panneaux dans lesquels on peut tomber, il y a le très vieux problème de la clôture.

C'est-à-dire, la confusion entre les bornes et les intervalles.

Dans ton exemple, ça y est, paf dans le panneau!

Je m'explique.

D.Vauvillier a écrit:

Ligne-nœud-section

Une ligne est composée de nœuds et de sections intermédiaires,

* (Chat 09/02 p.56) Je suis sûr que notre planificateur en chef le comprend bien:

- Maquette de structure

- Structure (la base est fonctionnelle pour les points non géographiques)

- Maquette d'interface et spécification des commandes

- Interface (le site affiche une page)

- Commandes (le site affiche ce qu'on veut sauf des cartes)

... ensuite, on bosse la géo

* (DV 09/02 p.57) Ça c'est mon plan d'opérations, tu lis dans mes pensées ?

Et l'on va le détailler car on a dit qu'il fallait progresser par modules capacitaires.

Cependant on pourra faire plus malin car j'ai ma petite idée pour que le site vive vite, avec une phase de présentation "plate" (sorte de bande-annonce), une phase de mise à dispo d'une info basique : le fichier Excel trituré par Pierre, puis les phases successives de mise en place des modules.

L'effet à obtenir c'est d'occuper rapidement le terrain, rallier des amateurs, organiser le groupe noyau qui se forme autour du projet, étoffer ce groupe et le mettre en ordre de bataille pour se structurer autour des charges de fonctionnement. C'est pas OPS ça ?

* (Chat 09/02 p.57) Quelques règles d'or et si j'enfonce encore des portes ouvertes, ce qui va sans dire va encore mieux en le disant!

Utiliser le plus possible du code existant, et quand on a le choix entre plusieurs sources (encore faut-il les connaître), choisir un compromis acceptable entre le coût et la pérennité. je refuse d'accepter l'existence d'un développement si ce n'est pas moi qui l'ai fait... Halte à la miséraprogrammation!

S'inspirer des solutions qui marchent et qui définissent les limites admissibles de l'outil.

L'overkilling. On peut tuer les mouches à la Grosse Bertha, mais çà demande beaucoup d'obus avant de choper celle qu'on visait.

Il faut pisser dans le sens du vent. Utiliser ce qui va de soi pour que le site devient intuitif et amusant : c'est d'éditer et d'afficher comme tous les autres.

* (CendreP 10/02 p.58) La carte est-elle compatible Lambert IIe (norme d'affichage de l'IGN pour les cartes françaises).

* (Chat 10/02 p.58) La simulation événementielle par ordinateur.

Dans notre structure, donc dans tout ce que nous voulons faire, l'aspect historique est primordial.

L'histoire, c'est une suite d'événements. Qu'est-ce qu'un événement ?

Un événement, c'est une modification instantanée de l'état d'un système qui intervient en un temps déterminé.

les changements ne sont pas si instantanés que çà, non ?

En réalité non, bien sûr, mais dans notre modèle oui :

Les Bénédictins de notre bande de fêlés ont patiemment cueilli des dates : ce sont des collectionneurs incorrigibles!

Et si on représente ces dates sur l'axe du temps qui est, rappelons-le, la quatrième dimension de notre modèle, eh bien ces dates sont des points et le système a bien deux états différents, avant et après.

La simulation, c'est quand l'utilisateur du modèle utilisera le "curseur des temps" pour se déplacer dans la carte le long de l'Axe du Temps, parce qu'il veut voir l'état du système qui l'intéresse en un temps donné.

Ils calculent, les enfants!

Ils font d'abord l'inventaire des machins qui les intéressent dans l'image qui est affichée à l'écran. Pour çà, ils demandent aux Bénédictins où sont les différents machins et ils ne regardent même pas les autres - çà vaut la peine de se décarcasser, hein les Bénédictins.

Ensuite, pour chacun de ces machins, ils regardent tout ce qui lui arrivé mais ils ne s'intéressent qu'au dernier état avant la date choisie par le curseur.

Enfin, ils demandent aux sectaires isolationnistes de refaire un beau dessin et eux, dessus, ils gribouillent le machin dans l'état où il était à cette date: aucun respect pour les beaux dessins, ces fêlés.

Et ensuite, comme si ça ne suffisait pas, ils gribouillent encore à côté du beau dessin.

Par exemple, quand ils ont regardé les machins qui les intéressent, ils ont bien noté la date du dernier événement avant cette date, et du prochain événement après cette date.

Comme çà, si le vieux schnock qui utilise le beau simulateur événementiel veut afficher l'image précédente ou suivante, il n'a qu'à cliquer sur un bouton avec sa souris.

Pour les informatheux qui font de la simulation événementielle leur spécialité, un historique c'est une file d'attente d'événements décomposée par ressources du système.

* (DV 10/02 p.58) Cartographie, réponse à Pierre.

Je suis convaincu qu'il faut faire très simple. Je jette une idée.

La carte est en vectoriel, certes mais ....

On démarre disons avec 3 jeux de cartes à 3 échelles différentes. Ces jeux sont un assemblage de rectangles d'images bitmap JPG parfaitement jointives.

Mon idée : chaque établissement sera logé dans le rectangle où il est dessiné. (Pas plus de précision à mon avis). On clique où il faut et la carte apparaît, avec le bon rectangle au centre. Une navigation permet de déplacer la carte, au pas des rectangles, H/B et G/D éventuellement diagonal (si ce n'est pas trop compliqué). Un moyen à définir permet de changer d'échelle, passant d'un jeu à un autre. Au passage on reste centré sur le rectangle central de l'échelle précédente.

Pour avoir le bon rectangle au centre, il faut que la fenêtre de visualisation affiche un nombre impair de rectangles dans les deux sens H et L.

Pré requis : savoir découper un grand bitmap en des carreaux exactement à la mesure voulue.

Remarque : il faudra trouver le bon compromis d'échelle et de fenêtre pour que dans le jeu "maxi", la surface soit suffisamment faible afin que l'œil trouve rapidement le nom qu'il cherche.

Restera le problème des zones hyper denses, notamment Île-de-France et région Lilloise où il faudra probablement disposer d'une échelle "super maxi".

Je ne mesure pas ce que requiert, en matière de programmation, l'idée que j'évoque.

Maintenant, à partir de cette idée, les informaticiens ont peut être des propositions intéressantes.

Surtout, restons concrets.

* (CendreP 10/02 p.58) Un carte vectoriel est l'optimum mais demande des moyens financiers ou en temps non négligeable (programmation et saisie). La méthode jpg (image) est la plus simple les méthodes de programmation sont connues et simples. Le programme choisit dans le rectangle à afficher la carte la plus précise. C'est simple, facile à programmer, court en temps CPU (temps de calcul et d'affichage).

* (DV 10/02 p.59) Si tu es d'accord, on part sur cette piste simple et pragmatique.

Décision finale un peu plus tard, laissons le groupe s'exprimer

De mon coté, je valide avec Prof quelques questions d'étalonnage pour choisir les échelles et fixer le pas des carreaux pour chaque jeu.

On est bien d'accord que chaque jeu est un multiple ou une fraction entière de carreaux par rapport à un autre.

* (Chat 10/02 p.59) Des images plus simples en JPG, des cases moins nombreuses à l'écran, une programmation raisonnable, des pas d'échelle simples pour une recherche par dichotomie (c'est-à-dire en divisant toujours par deux, ce que l'utilisateur comprend tout de suite), j'aime...

* (Chat 10/02 p.59) La nouvelle version de structure de XTof très largement épurée et déjà bien plus fonctionnelle (quoiqu'il ait juste oublié que si les nœuds n'ont actuellement que deux variables éditables, le Pk et le nom, celles-ci peuvent faire l'objet d'un historique et les sections affectées aussi).

* (XTofs 10/02 p.59) Faudra-t-il gérer les attentes ?

* (Chat 10/02 p.59) C'est l'histoire de la nomenclature ferroviaire qui était devenue un simulateur historico-géographique d'événements ferroviaires.

Et bien dans notre structure, on va pouvoir supprimer toutes les dates pour les mettre juste à côté, en file d'attente.

Et la table des dates, vous vous rappelez, avec une variable de type date et une variable de type énuméré précision... , et bien on va lui ajouter une variable de type énuméré Type d'événement...

On va créer une énumération des types d'événements dont on veut s'occuper:

- Début de validité,

- Fin de validité,

- Ouverture,

- Fermeture voyageurs,

- Fermeture marchandises,

- Déferrement,

- Électrification,

... et tout ce qui pourra bien passer par la tête.

avec ce changement, si les Bénédictins changent d'avis et rajoutent n'importe quel autre type d'événement, XTof n'aura plus besoin de travailler pour modifier la structure de la base.

Notre ami XTof va nous supprimer toutes les dates de toutes les tables, pour qu'on fasse de cette manière-là partout.

Comme çà, quand on édite un machin de notre modèle et n'importe quel machin, on aura partout la même jolie table d'événements.

Oui, mais alors, on pourra mettre l'événement Électrification sur n'importe quoi ?

Pas du tout, quand l'utilisateur voudra ajouter un événement, il aura un petit bouton Plus pour le faire.

Juste à côté, on lui montrera dans un menu déroulant seulement les types d'événements qu'il peut associer au machin qu'il est en train de modifier.

Et s'il veut changer le type d'un événement qui existe déjà, il suffira de l'éditer à nouveau.

Et s'il veut rajouter un deuxième événement de création de la ligne alors qu'il n'a droit qu'à un seul, par exemple, et bien on l'engueulera.

* (DV 10/02 p.59) Le pk du nœud correspond simplement à sa localisation. C'est le (ou les) établissements qui sont sur ce nœud (avec ce pk, donc) dont il faudra gérer l'historique.

Maintenant, un nœud peut apparaître sur une ligne déjà construite auparavant. C'est le cas pour tout croisement de transversale construite ultérieurement à l'ouverture de la ligne qu'elle croise en ce nœud.

De même, cette transversale peut être fermée alors que la ligne principale perdure, et le nœud n'est plus valide.

* (DV 10/02 p.59) En réponse à Chat;

* (Chat 10/02 p.60) Ceci s'adresse plus particulièrement aux informatheux.

Nous pouvons maintenant harmoniser le nom des tables pour refléter la métamorphose en simulateur : c'est le moment de le faire, puisque nous sommes toujours dans la définition de la structure.

1 -Nous avons en fait quatre catégories d'objets dans notre structure:

- Des ressources (les lignes, sections, compagnies et nœuds),

- Des états successifs de ces ressources (l'historique),

- Des événements, qui modifient l'état de toutes ces ressources,

- Des relations, par exemple la hiérarchie des lignes et leur composition.

2 - Certaines tables sont déjà correctement nommées:

- Compagnies

- Lignes

- Sections

3 - Nous pouvons donc renommer un certain nombre de tables de la manière suivante, qui n'est toujours qu'une proposition:

- Identifiant_Ligne > Ligne_Etats

- Ligne_Ligne > Ligne_Contient

- Lignes_1 > Lignes_Filles

- Compagnie_Ligne > Compagnie_PossèdeLigne

- Lignes_Noeuds > Ligne_ContientNoeud

- Localisation_Noeud > Lieu_HébergeNoeud

- Historique_Sections > Section_Etats

4 - Une table inutile:

- Section_Noeud

... puisqu'il doit y avoir une relation entre nœud et section pour définir les sections issues d'un nœud, ainsi qu'une relation entre section et nœud (une autre instance de la table, XTof) pour définir à quel nœud une section aboutit.

5 - Et de nouvelles tables à créer si tu ne l'as pas déjà fait:

- Ligne_ContientSection

exprime la relation d'appartenance manquante entre les sections et la ligne qui les agrège,

- Localisation_Etats

- Noeud_Etats

expriment la généralisation de la notion d'historique.

6 - J'en ai peut-être oublié: tiens oui, dans les sources c'était déjà tout bon.

7 - Quelques oublis dans mon post précédent :

- J'ai oublié Localisations dans les ressources, et donc Localisation_Etats.

- Ligne_Contient devrait s'appeler Ligne_ContientLigne

... et il y en a peut-être d'autres, mais on verra ça lors de l'interro écrite

* (Chat 10/02 p.60) Le fil Nomenclature ferroviaire avait déjà plus de 50 pages au compteur quand je l'ai découvert.

J'ai trouvé, et je trouve toujours, l'idée complètement extraordinaire.

Pensez... Modéliste peu pratiquant mais modéliste de cœur, je vois une bande de passionnés faire ce dont j'avais toujours rêvé : une carte ferroviaire zoomable et historique, avec toutes les informations que j'en attendais...

Et en plus, le modèle utilisé par cette approche permet d'obtenir un simulateur historique comme effet de bord, c'est-à-dire que visiblement personne dans le groupe ne s'en est encore aperçu!

- Toutes les bonnes volontés sont réunies,

- Une masse de données imposante est déjà collectée,

- Une base de données se prépare,

- Une sortie graphique très intéressante est en très bonne voie.

- La spécification de la base manque un peu de cohérence,

- Elle n'est pas taillée pour que le simulateur fonctionne proprement.

La raison en est double:

- La compétence nécessaire pour élaborer un simulateur n'est pas si courante, même si elle est enseignée depuis trente ans dans les écoles d'ingénieurs en Productique par exemple,

- Les protagonistes du groupe ne sont pas tombés tout de suite sur quelqu'un qui pouvait les aider dans ce domaine.

Et maintenant je dirai notre nomenclature, parce que j'y aurai contribué à la mesure de mes moyens et de mes compétences.

Qu'est-ce que tu crois?

- Je bave d'envie devant les images que Prof nous montre et je l'ai déjà dit plusieurs fois, je serais incapable de produire ce qu'il nous a montré.

- Je suis totalement incapable de monter un site comme il s'en prépare un en sourdine ou presque,

- J'obéis au chef, parce que c'est un plaisir de voir quelqu'un faire avancer un groupe hétérogène dans la bonne humeur (travail bien commandé...).

... et il y a tous ceux que j'ignore et qui ont largement fait leurs 11'360 parts jusqu'ici.

Pourquoi insérer mes explications techniques dans la partie publique du forum?

- Parce que ce sujet me passionne,

- Parce que tels des Mr Jourdain vous simulâtes sans le savoir,

- Parce que le débat était déjà engagé sur la notion de base de données,

- Parce que j'ai eu du plaisir à en vulgariser les notions de manière qui vous a fait sourire de temps en temps j'espère.

Tu ne m'en veux pas trop?