Disposition de l’Arbre des sources¶

cmake/

Scripts cmake utilisés en partie pour notre système de build.

src/

This is the algorithm source tree. Each algorithm should be contained in its on sub-tree with doc, sql, src, and test sub-directories. This might get renamed to “algorithms” at some point.

src/astar/

Ceci est une implémentation de la Recherche A* basée sur l’utilisation de la bibliothèque Boost Graph. Ceci est une implémentation du plus court chemin Dijkstra avec une Heuristique Euclidienne.

src/common/

Pour le moment ceci n’a pas de core in “src”, mais a un certain nombre de codes de wrappers SQL et de codes de topologie dans le répertoire “sql”. Les wrappers spécifiques d’algorithmes devraient être déplacées à l’arbre d’algorithme et les tests appropriés devraient être ajoutés pour valider les wrappers.

src/dijkstra/

Ceci est une implémentation de la solution du plus court chemin Dikjstra utilisant les bibliothèques Boost Graph pour l’implémentation.

src/driving_distance/

Ce paquet optionnel créée des polygones de driving distance basées sur la résolution de la solution du plus court chemin Dijkstra, ensuite en créant des polygones basés sur les distances de coût égal depuis le point de départ. Ce paquet optionnel requiert d’avoir installé les librairies CGAL.

src/shooting_star/

DESAPPROUVE et NE FONCTIONNE PAS et SUR LE POINT D’ETRE SUPPRIME Ceci est une arête basée sur l’algorithme du plus court chemin qui supporte les restrictions de virage. It is based on Boost Graph. Ne PAS utiliser cet algorithme comme il est cassé, utiliser trsp à la place, qui a la même fonctionnalité et est plus rapide et donne des résultats corrects.

src/trsp/

Ceci est un algorithme du plus court chemin avec restrictions de virage. Il a des caractéristiques sympathiques comme vous pouvez spécifiez les points de début et la fin comme un pourcentage d’une arête. Les restrictions sont sauvegardées dans une table séparée des arêtes du graphe et cela rend plus facile de gérer les données.

src/tsp/

Ce paquet optionnel fournit la capacité de calculer les solutions du problème du voyageur de commerce et calcule la route résultante. Ce paquet optionnel requiert l’installation des librairies GAUL.

tools/

Scripts divers et outils.

lib/

Ceci est le répertoire de sortie où les cibles des bibliothèques compilées et des installations sont présentées avant l’installation.

Mise en page de la documentation¶

Comme mentionné ci-dessus toute la documentation devrait être construite en utilisant les fichiers formattés reStructuredText.

La documentation est distribuée dans l’arbre des sources. Ce répertoire “doc” de haut niveau est prévu pour la documentation de haut niveau couvrant les sujets comme :

• Compilation et tests
• Installation
• Tutoriels
• Documentation liminaire du Guide Utilisateur
• Documentation liminaire du Manuel de référence
• etc

Puisque la documentation spécifique de l’algorithme est contenue dans l’arbre de sources avec les fichiers spécifiques de l’algorithme, le processus de la construction de la documentation et la publication va avoir besoin d’assembler les détails avec la documentation de premier rang si besoin.

Aussi, pour empêcher le répertoire “doc” d’être encombré, chaque libre majeur comme ceux listés ci-dessus, doivent être contenu dans un répertoire séparé dans “doc”. Toutes les images ou autres documents liés au livre doivent être aussi mis dans ce répertoire.

Infrastructure de test¶

L’infrastructure de test mise en place est très basique. Voici les bases de comment ça marche. Nous avons besoin de plus de cas de tests. A long terme nous devrons probablement avoir une personne pour installer les frameworks travis-ci ou jenkins.

Voici le graphe des tests TRSP.

Les tests sont lancés via le script au haut niveau tools/test-runner.pl qui exécute tous les tests configurés et pour le moment produit en résultats la structure de test. Cela peut être amélioré par la suite.

Cela suppose aussi que vous avez installé les librairies car les tests requièrent postgresql installé. Il est probablement nécessaire de rendre cela mieux conçu pour que nous puissions essayer l’arbre de build. Je vais essayer de réfléchir à ça.

Simplement chaque répertoire .../test/ doit inclure un fichier test.conf qui est un fragment de script perl qui définit quels fichiers de données charger et quels tests lancer. J’ai intégré certains mécanismes pour autoriser tests et données d’être spécifiques aux version pg et postgis, mais je ne l’utilise pas encore. Ainsi par exemple, core/trsp/test/test-any-00.data est un texte plein généré qui va charger les données nécessaires pour un jeu de tests. C’est aussi le graphe dans l’image de dessus. Vous pouvez spécifier plusieurs fichiers à charger, mais comme un groupe ils ont besoin d’avoir des noms uniques.

core/trsp/test/test-any-00.test est une commande sql qui peut être exécutée. Elle s’exécute ainsi :

psql ... -A -t -q -f file.test dbname > tmpfile
diff -w file.rest tmpfile

Ensuite si il y a une différence, alors un échec de test est reporté.