cqcb.mm.free.fr › cv › barouh-rapport-ptvloxane.pdf Moteur de requêtes pour données GSFMoteur...

Moteur de requêtes pour données GSF

Mémoire d’apprentissage

Master Professionnel SIIC 2007-2008

David BAROUH

Sous le tutorat de Sébastien BEOLET,

Ingénieur de Recherche

Beauchamp, 10 septembre 2008

Contact

David BAROUH

PTV Loxane

271 Chaussée Jules Cesar

95250 Beauchamp

Tel : +33 (0)1 30 40 24 18

Mob : +33 (0)6 17 04 87 64

Mail : [email protected]

Table des matières

1 Remerciements 1

2 Introduction 2

3 Présentation de l’entreprise 3

3.1 Le groupe PTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1.1 Profil du groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1.2 Présence internationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1.3 Le chiffre d’affaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1.4 Domaines d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 La société PTV Loxane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2.2 Quelques chiffres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2.3 Stratégie et savoir-faire . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2.4 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.5 Les domaines d’expertise . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Rappel du sujet : Moteur de requêtes pour données GSF 14

5 Prise en main des outils 15

5.1 C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.2 Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.3 Librairies et objets PTV Loxane . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.4 Création de librairies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6 Etudes des besoins 18

6.1 Couche intermédiaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.2 Fonctionnalités équivalentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.3 Evolution des fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.4 Langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.5 Requêtes géographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.6 Moteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7 Etudes de l’existant 22

7.1 Choix du parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8 Architecture proposée 25

8.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

8.2 Langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

8.2.1 SQLLXN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

8.2.2 Requêtes supplémentaires . . . . . . . . . . . . . . . . . . . . . . . . 26

8.2.3 Requêtes géographiques . . . . . . . . . . . . . . . . . . . . . . . . . 27

8.2.4 Spécifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

9 Développement de la librairie 32

9.1 Prévision de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

9.2 Prise en main du parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

9.3 Nettoyage et conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

9.4 Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

9.5 Création des structures de données . . . . . . . . . . . . . . . . . . . . . . . 35

9.5.1 Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

9.5.2 Requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

9.6 Moteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

9.7 Traitement des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

9.8 Requêtes géographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

9.9 Exemple de script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

9.10 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

10 Interface graphique/OCX 49

11 Gestion de projet 51

11.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

11.1.1 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

11.1.2 Diagramme de PERT . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

11.2 Réunions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

12 Conclusion 54

A Glossaire 55

B Annexes 56

B.1 WKT : Well-Known Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

B.2 Systèmes géographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

B.3 BNF du parser original . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

B.4 Diagramme de Gantt complet . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

B.5 Diagramme de PERT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Table des figures

1 Présence à l’internationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Domaines d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Domaines d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Savoir-faire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5 Organigramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6 Domaines d’expertise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

7 Exemples de clients mobilité . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

8 Exemples de clients logistique . . . . . . . . . . . . . . . . . . . . . . . . . . 12

9 Exemples de clients analyse spatiale . . . . . . . . . . . . . . . . . . . . . . . 13

10 Types d’informations géographiques . . . . . . . . . . . . . . . . . . . . . . . 16

11 Types de fichiers d’informations géographiques . . . . . . . . . . . . . . . . . 16

12 Architecture logicielle actuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

13 Architecture logicielle souhaitée . . . . . . . . . . . . . . . . . . . . . . . . . . 19

14 Architecture proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

15 Architecture librairie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

16 Tri dans le Loxane Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

17 Structure du parser avec la base et les tables . . . . . . . . . . . . . . . . . . 36

18 Structure d’une requête . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

19 Structure des opérations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

20 Exemple d’un arbre d’opérations . . . . . . . . . . . . . . . . . . . . . . . . . 39

21 Structure avec le parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

22 Structure finale du coeur de l’application . . . . . . . . . . . . . . . . . . . . . 41

23 Départements sélectionnés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

24 Villes sélectionnées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

25 Encapsulation de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

26 Interface actuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

27 Diagramme de Gantt réduit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

28 Diagramme de Gantt : première partie . . . . . . . . . . . . . . . . . . . . . . 62

29 Diagramme de Gantt : deuxième partie . . . . . . . . . . . . . . . . . . . . . 63

30 Diagramme de PERT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

1 Remerciements

Je tiens tout d’abord à remercier Sébastien BEOLET, Ingénieur de Recherche et res-

ponsable du noyau applicatif Loxane, pour avoir proposé et encadré ce stage, ainsi que

pour son écoute et ses nombreux conseils et recommandations. Je tiens également à le

remercier pour son regard critique et exigeant sur mes travaux.

Je voudrais ensuite remercier Didier SCELLIER, directeur technique de la filiale PTV

Loxane, ainsi que Maxime BELLEMIN, président de la filiale PTV Loxane, pour m’avoir ac-

cueilli au sein du service technique de PTV Loxane.

Mes remerciements vont également envers l’ensemble du personnel de PTV Loxane,

et plus particulièrement les membres de l’équipe technique, pour leur accueil chaleureux,

l’ambiance et le cadre de travail, favorables à l’accomplissement de mes travaux ainsi qu’à

mon épanouissement personnel dans le monde de l’entreprise. Je voulais également les

remercier pour toute l’aide qu’ils ont pu m’apporter au cours de mon alternance.

1

2 Introduction

Ce contrat d’apprentissage au sein de l’entreprise PTV Loxane s’inscrit dans le cadre

de l’obtention du Master Professionnel SIIC (Systèmes Informatiques Intelligents et Com-

municants) proposé conjointement par l’Université de Cergy-Pontoise et par l’ITIN.

Ce contrat s’est déroulé en alternance sur une période de dix mois, allant de début

décembre 2007 à fin septembre 2008, et m’a été proposé par Sébastien BEOLET, respon-

sable du noyau applicatif Loxane, au mois d’octobre 2007.

Les logiciels PTV Loxane utilisent des bases de données dans des formats proprié-

taires, permettant un contrôle total des données, et ainsi leur sécurisation.

La contrepartie étant que ces base de données ne peuvent pas se reposer sur des

structures d’interrogations existantes, comme par exemple le langage SQL à travers un

système de gestion de bases de données MySQL.

Ainsi tout requêtage nécessite de programmer chaque étape nécessaire au sein de

chacun des logiciels PTV Loxane qui souhaitent effectuer ces interrogations.

Ma mission consistera donc à étudier la possibilité de créer un socle commun à tous

les logiciels PTV Loxane, permettant un requêtage simplifié de ces bases de données, et

à le développer.

2

3 Présentation de l’entreprise

3.1 Le groupe PTV

3.1.1 Profil du groupe

Le groupe PTV, représenté en France par PTV Loxane, a été fondé en 1979 à Karlsruhe

(Allemagne) et affiche un chiffre d’affaires en 2007/2008 de près de 83,4 millions d’euros

pour un effectif de 494 personnes au siège en Allemagne et 17 filiales européennes, soit

environ 700 personnes au total.

C’est aujourd’hui la plus importante société européenne tant en termes de chiffre d’af-

faire que d’effectifs sur les technologies de cartographie liées à la mobilité, à la gestion de

trafic et la logistique.

Plus de 400 sociétés en Europe utilisent les services et technologies du Groupe PTV. Il

représente une expérience unique de l’information géographique dans le monde :

• Plus de 5 millions d’utilisateurs grand public.

• Plus de 50 000 utilisateurs professionnels.

• Plus de 500 projets logistique ou mobilité mis en place avec succès.

3.1.2 Présence internationale

Le groupe PTV possède 17 filiales sur 9 pays européens et 4 continents.

Voici la présence du groupe à l’internationale :

3

FIG. 1 – Présence à l’internationale

3.1.3 Le chiffre d’affaire

Le graphique suivant représente le chiffre d’affaire de PTV AG en bleu d’une part, et du

groupe PTV en violet d’autre part.

4

FIG. 2 – Domaines d’activités

3.1.4 Domaines d’activités

Au sein du groupe PTV on peut distinguer trois domaines d’activités principaux :

FIG. 3 – Domaines d’activités

• Le Trafic : Qu’il s’agisse de routes, de voies ferrées ou de transports publics, la pla-

5

nification et l’utilisation d’infrastructures de trafic représentent les activités principales

du département Trafic. Pour ce métier, PTV travaille principalement pour le compte

de collectivités locales, d’entreprises publiques ou privées ou encore de sociétés de

transports.

• La Mobilité : L’objectif du département Mobilité consiste à aider le particulier et le

professionnel dans ses déplacements. Dans ce domaine, PTV travaille notamment

avec les fournisseurs de services télématiques, les constructeurs automobiles ou en-

core les portails Internet afin de leur fournir des technologies ou solutions de mobilité

(Logiciels, composants et services ASP).

• La Logistique : Le département Logistique a développé des logiciels, des compo-

sants et des services ASP permettant d’optimiser des tournées ou encore de réaliser

de la gestion de flotte. Des solutions de Géo Management viennent compléter cette

offre.

3.2 La société PTV Loxane

3.2.1 Historique

PTV Loxane, société fondée en 1993, est devenu en 2005 la filiale française du Groupe

PTV. A ce titre, PTV Loxane distribue en France les produits des marques PTV, Loxane, et

Map&Guide.

Basée à Beauchamp (95) à côté de Cergy-Pontoise, PTV Loxane dispose également

d’un département services et études basé à Toulouse (31).

Comptant 34 employés et réalisant un chiffre d’affaire de plus de 4,5 millions d’euros,

PTV Loxane s’est imposé comme un leader sur le marché des solutions cartographiques

avec plus de 5 000 références clients, parmi lesquelles : ND Logistics, Mauffrey, Leguevel,

Transalliance, Total Gaz, Butagaz, Auchan Direct, Fresenius Kabi, Tubauto...

Depuis près de 14 ans, PTV Loxane édite une gamme de progiciels destinés aux pro-

fessionnels pour apporter des solutions liées à la mobilité, des individus et dans les en-

treprises. Tous les produits de PTV Loxane s’appuient sur une base progicielle solide pour

permettre la consultation de cartes routières, le calcul d’itinéraire, l’optimisation de tournées

et le positionnement de points d’intérêts ou de véhicules sur la carte. Les logiciels profes-

sionnels sont ouverts et peuvent s’intégrer avec tous types d’applications pour répondre

aux exigences et spécificités d’un métier.

6

3.2.2 Quelques chiffres

Aujourd’hui, PTV Loxane représente en terme de clientèle :

• 1 000 000 licences grand public

• 20 000 licences professionnelles

• 20 000 véhicules suivis en temps réel

• 20 000 ordres de transport optimisés ou dispatchés chaque jour

• Des millions de cartes et de calculs d’itinéraires en lignes

3.2.3 Stratégie et savoir-faire

La mission de PTV Loxane est d’aider les entreprises et les particuliers dans la gestion

de leurs déplacements au travers de ses différents métiers : l’édition et la distribution de lo-

giciels, de composants et de Web services, ainsi que les services d’études, d’installations,

de formations et d’accompagnement.

Pour mener à bien sa stratégie, PTV Loxane peut se baser sur ses différents savoir-faire

représenté par de puissants progiciels : la gamme Way (Way Home, Way Pro, Way Opti-

mum, Way Server, Way X) jusqu’en 2004, suivie par la nouvelle gamme Loxane (LOXANE

Pro, LOXANE Optimum, LOXANE X, LOXANE Geocoder) depuis 2004, suite à une refonte

totale de l’ensemble des applications.

Le savoir-faire et la puissance de ces progiciels sont basés sur des composants, qui

sont des architectures souples et ouvertes, multi supports et environnements, avec une

API documentée et des interfaces OLE, OCX et Web Services.

7

FIG. 4 – Savoir-faire

3.2.4 Structure

Voici la structure actuelle de la société :

8

FIG. 5 – Organigramme

3.2.5 Les domaines d’expertise

PTV Loxane excelle dans trois domaines : la mobilité (le déplacement de personnes),

la logistique (le déplacement de biens) et l’analyse spatiale (le géomarketing), comme le

montre la figure suivante :

9

FIG. 6 – Domaines d’expertise

Mobilité Ce domaine regroupe les activités suivantes :

• L’organisation des interventions.

• La recherche de proximité.

• La navigation on-board et off-board.

• Les atlas promotionnels.

Différents marchés sont visés par ces domaines d’activités, à savoir :

• La sécurité, l’intervention.

• Les transports en commun.

• Les assembleurs GPS.

• Les opérateurs de télécommunication.

• Les constructeurs automobile.

• Les éditeurs de produits grand public d’atlas routiers.

Comme nous pouvons le voir, un grand nombre de marchés sont présent dans cette

liste, et nous pouvons retrouver un grand nombre de ses marchés chez les clients de PTV

Loxane :

10

FIG. 7 – Exemples de clients mobilité

Logistique Ce domaine regroupe les activités suivantes :

• La visualisation de cartes routières.

• L’optimisation des tournées, des rendez-vous.

• La géo localisation de mobiles.

• La recherche de proximité.

• La planification.

• La navigation embarquée.

Les marchés correspondant à ce domaine sont les suivants :

• Les transporteurs de biens par la route.

• La distribution.

• L’agro-alimentaire.

• L’energie.

• L’industrie.

• Les plateaux d’appels.

De nombreux clients ont décidé de faire confiance à PTV Loxane dans ce domaine, et

notamment les suivant :

11

FIG. 8 – Exemples de clients logistique

Analyse spatiale Ce domaine regroupe les activités suivantes :

• Le géomarketing, la géo analyse.

• L’affichage de données statistiques.

• Les analyses stratégiques.

• Les études de flux.

• Les études d’implantation.

• Le ciblage marketing direct, la distribution en BAL.

• L’aménagement du territoire.

Les marchés correspondant à ce domaine sont les suivants :

• Les fonctions de directions commerciale et marketing.

• L’immobilier.

• Les administrations territoriales.

• La sécurité publique.

Voici les différentes références clients dans ce domaine de compétences :

12

FIG. 9 – Exemples de clients analyse spatiale

13

4 Rappel du sujet : Moteur de requêtes pour données

GSF

Les logiciels PTV Loxane exploitent des bases de données cartographiques au format

propriétaire GSF (Geographic Scalable Format). Ces bases de données binaires ont été

structurées de façon modulaire (affichage, géocodage, calcul d’itinéraires...) et indépen-

dante.

Les bases de données d’affichage sont constituées de trois types d’objets distincts

(ponctuels, linéaires, surfaciques) auxquels peuvent être associés des attributs variables

en nombre et en types. Des librairies dédiées permettent l’accès aux données de ces bases

(lecture, écriture, édition...) ; elles sont totalement indépendantes les unes des autres.

Leurs API (interfaces de programmations) respectives rendent possibles des requêtes

cartographiques et attributaires simples, comme par exemple la recherche d’objets à l’inté-

rieur d’une zone, ou par rapport à la valeur d’un attribut. Le but de ce stage est de concevoir

et de développer un moteur pilotable via SQL, permettant d’automatiser des enchaîne-

ments de requêtes et de croiser les informations provenant de plusieurs jeux de données.

Ce moteur doit être facilement intégrable au sein d’applications variées.

14

5 Prise en main des outils

5.1 C++

Au cours de ma formation, j’avais déjà approché de près au langage C, qui est la base

syntaxique du C++. Il m’a donc été facile de prendre en main ce langage. De plus, je sa-

vais déjà développer dans un langage Orienté Objet qui est le java, je possédais donc les

bases de cette notion pour le C++. Cependant de nombreuses particularités de ce lan-

gage m’étaient inconnues. Il a donc fallu que je fasse de nombreuses recherches, et que

je m’entraîne un certain temps avant de pouvoir m’attaquer de manière sérieuse à la tâche

qui m’était assignée.

Je n’ai cependant jamais cessé d’apprendre les particularités de ce langage tout au

long du développement de ce projet.

5.2 Visual Studio

Visual Studio est un IDE (Integrated Development Environment, environnement de dé-

veloppement intégré) développé par Microsoft.

Je ne connaissais pas du tout ce logiciel à mon arrivé chez PTV Loxane, mais étant

donné que tous les projets chez PTV Loxane étaient développés sous cet éditeur, son

utilisation était imposée. Il a donc fallu que j’apprenne à l’utiliser pleinement afin d’atteindre

une efficacité au codage maximale. Cependant utilisant déjà de nombreux autres IDE tels

que Eclipse ou Code::Blocks, je n’ai pas eu beaucoup de mal à prendre en main Visual

Studio, et à coder efficacement. Il a fallu évidemment un peu plus de temps pour connaître

un grand nombre des fonctionnalités particulières de cet IDE, mais ceci n’interférait pas

avec le temps de développement.

5.3 Librairies et objets PTV Loxane

Chez PTV Loxane, les informations géographiques sont principalement regroupées en

trois catégories : Les informations ponctuelles, concernant des points d’intérêts, comme

les cinémas, les hôtels etc., qui sont appelés Landmarks. Les informations linéaires, telles

que les routes, les ponts, les voies ferrées etc., appelés Linears et les informations de sur-

faces telles que les villes, les parcs etc., appelés Landcovers. Ces informations de surfaces

peuvent contenir également des informations linéaires et des “trous”, permettant de repré-

15

senter des étendus d’eaux, avec éventuellement les canaux partant de cette étendue, et

les îles qui peuvent être présente.

Landmark Lineaire Landcover

FIG. 10 – Types d’informations géographiques

Un ensemble d’informations géographiques du même type est regroupé dans un fichier

qui a une extension dépendant du type : lxd pour les Landmarks, lin pour les Linears et

lco pour les Landcovers. Ainsi, par exemple, on peut retrouver tous les hôpitaux d’un pays

dans un seul fichiers, tandis que les cinémas seront dans un autre.

Landmark Lineaire Landcover

.lxd .lin .lcoFIG. 11 – Types de fichiers d’informations géographiques

Pour chacun de ces trois types de fichiers, des API (Application programme interface,

interface de programmation) de manipulation ont été mises en places. Ces API permettent

d’effectuer des fonctionnalités de base, tels que la création, la suppression, la modification,

ou le tri de ses informations.

16

Voici un exemple de ces API pour les landmarks :

�/ / Permet d ’ o u v r i r une base , su ivan t son chemin

bool Open( char∗ in_st rF i leName ) ;

/ / Permet d ’ a j o u t e r un landmark dans l a base

bool AddLandmark ( double in_dX ,

double in_dY ,

unsigned long ∗ out_u l ID ) ;

/ / Permet de récupérer l a va leur d ’ un a t t r i b u t

long ∗ GetLandmarkAttr ibuteValue ( unsigned long in_u l ID ,

unsigned i n t i n _ u i A t t r i b u t e P o s ) ;� �Il a donc fallu que je prenne en main ces API afin de comprendre le fonctionnement

interne de ces bases et leur utilisation, tout cela dans le but de mener à bien le projet.

5.4 Création de librairies

Pour appréhender à la fois le langage et les outils mis à ma disposition, j’ai commencé

par effectuer quelques tests, de plus en plus important, en créant pour commencer une

base de landmarks vide, puis en créant des landmarks et les modifiant, et faire la même

chose pour les linears et les landcovers.

J’ai ensuite décidé, toujours dans le cadre de la prise en main de ces API de développer

des fonctions permettant de leur ajouter des possibilités. Elles n’avaient pas pour but d’être

intégrées dans les API mais auraient pu l’être. Elles étaient orientées vers le cœur du sujet,

pour permettre une transition souple entre la prise en main, et le développement du projet

proprement dit.

17

6 Etudes des besoins

6.1 Couche intermédiaire

PTV Loxane a édité un logiciel appelé Loxane Pro dont le développement continue

actuellement.

Ce logiciel possède de nombreuses capacités, et notamment de l’extraction de données

en fonction de critère et de fusion de données.

Toutefois, son architecture posait un certain problème :

Application

lxd lin lco

FIG. 12 – Architecture logicielle actuelle

Comme nous pouvons le voir sur ce schéma, Loxane Pro comme la plupart des applica-

tions de PTV Loxane, travaille directement avec les librairies de traitement des bases, pour

effectuer ses fonctions de sélections et de fusions, ce qui signifie que si l’on veut implanter

ces fonctions dans un autre logiciel, on sera obligé de les redévelopper entièrement : Tous

les algorithmes sont directement dans l’application.

Le but de ce projet était donc de créer une couche intermédiaire, permettant d’une part,

d’effectuer les traitements de sélection et fusion, et d’autre part, de proposer une interface

graphiques (IHM) aux logiciels qui voudront utiliser ces fonctions, permettant ainsi un re-

port transversal des fonctionnalités en toute simplicité.

18

Voici le schéma de l’architecture finale souhaitée :

Application

linlxd lco

SQLEngineIHM

FIG. 13 – Architecture logicielle souhaitée

Comme nous pouvons le voir sur ce graphe, tous les algorithmes sont à présent dé-

portés et généralisés dans une couche logicielle intermédiaire, utilisable par toutes les

applications de PTV Loxane.

6.2 Fonctionnalités équivalentes

Le deuxième point important consistait dans l’iso-fonctionnalité du projet et du Loxane

Pro : Il fallait qu’au minimum, le projet possède toutes les fonctionnalités de sélection et

fusion du Loxane Pro. Le but était de créer une couche intermédiaire, sans perdre des pos-

siblités.

6.3 Evolution des fonctionnalités

Ce projet devait d’ailleurs apporter des évolutions fonctionnelles par rapport au Loxane

Pro.

19

En effet, les filtres présents dans Loxane Pro permettaient d’extraire des informations

suivant la valeur de champs et de créer des liaisons entre deux bases, uniquement par rap-

port à la distance (comme par exemple trouver toutes les villes à une distance inférieure à

10km d’un cinéma). Ces extractions n’étaient pas vraiment intuitives, et ne pouvaient pas

être enchaînées de façon simple, afin de pouvoir créer une série de résultats rapidement,

et non un seul. De plus, d’autres requêtes de types géographiques n’étaient pas possibles.

Ainsi de nouvelles fonctionnalités devaient être développées pour permettre :

• D’avoir plusieurs fichiers en entrée

• L’utilisation d’un langage particulier

• La possibilité de créer des scripts pour chaîner des opérations

• D’ajouter de nouvelles fonctions géométriques pour la sélection

6.4 Langage

Il a été défini que, pour effectuer simplement ces filtres, un langage de script serait pro-

bablement la meilleur solution, car il permettrait à l’utilisateur de questionner les bases de

données géographiques extrêmement facilement avec très peu d’apprentissage.

Le langage choisit a été le SQL, qui est un langage classique d’interrogation de bases

de données, qui est connu par beaucoup, et est plutôt simple à la compréhension. Il permet

également toute une gamme extrêmement grande de recherches possibles.

Cependant la totalité du langage ne serait pas mis en place. En effet, le langage SQL

permet d’exécuter des fonctions qui vont bien au delà de la sélection de données dans une

base, la plupart de ces fonctions étant inutiles pour les besoins de PTV Loxane.

6.5 Requêtes géographiques

Etant donné le caractère géographique des informations contenues dans les bases,

certains aménagements seront nécessaires au langage SQL pour couvrir ces besoins, et

ainsi pouvoir ajouter au système de filtres un système avancé de sélections grâce aux in-

formations géographiques, comme la position, l’intersection ou la superposition de deux

entités.

20

Ainsi il faudra définir les changements à apporter au langage, qui permettront d’effectuer

toutes les sélections géographiques, tout en conservant une syntaxe similaire au SQL, pour

ne pas perturber les utilisateurs.

6.6 Moteur

Le système d’interrogation étant définit, il restait à prévoir comment fonctionnerait le

moteur qui irait récupérer les données dans les bases. En effet, le langage SQL a été

conçu pour les bases de données relationnelles, et de nombreux moteurs permettant de

récupérer les données dans les bases existent déjà.

Cependant, les bases de données géographiques existant chez PTV Loxane ne sont

pas définies comme des bases relationnelles classiques, et sont dans un format proprié-

taire, unique à PTV Loxane. Il n’existe donc aucun moteur permettant de répondre à un

requêtage.

Cette partie représente une section critique du projet, car c’est d’elle que dépendra le

bon fonctionnement de l’application.

Il faudra que le moteur soit :

– Léger, pour que sa maintenance et son exécution soit le plus rapide possible.

– Portable, pour permettre son fonctionnement sur différentes plateformes dans le futur,

comme Linux ou Windows CE.

– Facilement intégrable dans un environnement de développement C++, dans lequel

sont tous les projets de PTV Loxane.

– Evolutif, pour permettre facilement l’ajout de nouvelles fonctionnalités.

– Avoir un contrôle total sur le code et sur les données générées.

– Pas de dépendance externe, pour toujours avoir un contrôle total sur le projet.

– Que le code soit compréhensible, pour que d’autres développeurs puissent corriger

facilement des erreurs, si nécessaire.

– Enfin, que dans le cas d’utilisation d’un outils externe, qu’il soit gratuit.

21

7 Etudes de l’existant

7.1 Choix du parser

De nombreuses manières de parser les requêtes existaient déjà de manières com-

munes. Parser consiste à identifier chaque élément de la requête. Il ne s’agit que de la

syntaxe, et pas du moteur qui “comprendrait” véritablement la requête.

Lex et Yacc Le premier outils qui a été étudié est le couple Lex et Yacc, qui sont des outils

classiques pour faire un analyseur syntaxique couplé avec compréhension grammaticale.

Cependant ces outils étant payants, nous nous sommes ensuite dirigés vers Flex et Bison

qui sont des équivalents libres de Lex et Yacc.

Flex et Bison Ces derniers étant extrêmement généraux, et évolués, ils auraient permis

de répondre parfaitement aux besoins. Toutefois ces outils ne sont pas évidents à prendre

en mains, et ceci impliquait des difficultés de mises en place et de maintenance, et donc

une évolutivité réduite. De plus, des problèmes de licences auraient pu survenir, du fait de

la licence de Bison qui est en GPL (Flex étant en BSD, il ne posait pas de problèmes).

Regex Ensuite, l’emploi des expressions régulières (regex) a été étudié pour sa rapidité.

Cependant, son usage nécessite l’utilisation de librairies, ce que PTV Loxane préfère éviter

pour rester maître du code. De plus sa mise en place et sa maintenance sont loin d’être

aisées. En effet, par exemple, uniquement pour reconnaître une adresse courriel, la chaîne

regex ressemblerait à ceci :

�( ? : [ a−z0−9!#$%&’∗+/=?^_ ‘ { | } ~ − ] + ( ? : \ . [ a−z0−9!#$%&’∗+/=?^_ ‘ { | } ~ − ]

+ ) ∗ | " ( ? : [ \ x01−\x08 \ x0b \ x0c \ x0e−\ x1 f \ x21 \ x23−\x5b \ x5d−\ x7 f ] | \ \ [ \

x01−\x09 \ x0b \ x0c \ x0e−\ x7 f ] ) ∗ " )@( ? : ( ? : [ a−z0−9 ] ( ? : [ a−z0−9−]∗[a−z0

−9 ] ) ? \ . ) + [ a−z0−9 ] ( ? : [ a−z0−9−]∗[a−z0−9 ] ) ? | \ [ ( ? : ( ? : 25 [ 0 −5 ] | 2 [ 0 −4 ]

[0 −9 ] | [ 01 ]? [0 −9 ] [0 −9 ]? ) \ . ) {3 } (? :25 [0 −5 ] |2 [0 −4 ] [0 −9 ] | [ 01 ]? [0 −9 ] [

0−9]?| [a−z0−9−]∗[a−z0 − 9 ] : ( ? : [ \ x01−\x08 \ x0b \ x0c \ x0e−\ x1 f \ x21−\x5

a \ x53−\ x7 f ] \ \ [ \ x01−\x09 \ x0b \ x0c \ x0e−\ x7 f ] ) + ) \ ] )� �De plus les regex permettent principalement de contrôler la syntaxe, et non pas de séparer

la requête en plusieurs éléments.

22

Temel SQLParser Par la suite, nous avons étudié une classe qui s’appelle Temel SQL-

Parser, et qui permet de séparer certains éléments des requêtes. Cependant cette classe

était un peu simpliste, et ne permettait de distinguer que les éléments principaux, et était

donc beaucoup trop limité pour ce que l’on voulait faire.

Nous avons finalement étudié deux dernières solutions :

“A la main” Soit je devais tout refaire entièrement. Cette solution aurait eu l’avantage de

nous permettre de mettre en place exactement ce dont nous avions besoin, tout en gardant

la connaissance complète sur le code développé. Cependant, cette solution avait comme

inconvénient majeur d’impliquer une réécriture complète, et donc, de réinventer la roue, ce

qui aurait été une perte de temps majeur.

OGR/Mitab Soit je devais prendre une partie des librairies OGR/Mitab, consacrées à la

reconnaissance des champs dans une requête, et à leur vérification (SWQ). Malgré ses

intérêts, cette librairie avait quelques inconvénients : en effet, elle était en C, alors que le

projet devait se passer en C++. De plus, le code devait être modifié pour correspondre aux

standards de nommage de PTV Loxane, et enfin, de nombreux efforts devraient être faits

pour sa compréhension, étant donné son importance, au point de vue taille.

Nous pouvons faire un tableau récapitulatif des avantages et inconvénients des diffé-

rentes méthodes :

23

Méthode Points positifs Points négatifs

Lex et Yacc Classique, généraliste et per-

mettait une analyse gramma-

ticale

Payant

Flex et Bison Gratuit et les mêmes avan-

tages que Lex et Yacc

Difficultés de mises en

place et de maintenance,

problèmes possibles de

licence

Regex Rapidité Utilisation de librairies ex-

ternes, difficultés de mise en

place et de maintenance

Temel SQLParser Simple, léger Simpliste, trop limité

OGR/Mitab Complet, gratuit, portable Assez complexe, a porter en

C++

De zéro Maîtrise totale du code Réinvente la roue, long

Et voici un tableau récapitulant les différents besoins qui ont été satisfait par chaque

méthode :

Méthode Gratuit Léger Portable Evolutif Capacité Intégrable

Lex et Yacc

Flex et Bison

Regex

Temel SQLParser

OGR/Mitab

De zéro

Note : Dans ce tableau, la maîtrise des applications n’est pas indiqué, car nous pouvons

avoir la maîtrise de tous les éléments cité. De plus, “Intégrable” désigne la possible facilité

d’intégration de l’outils dans un projet, en incluant le facteur “temps nécessaire”.

En observant ces tableaux, nous nous sommes rendu compte que la librairie issue

d’OGR/Mitab correspondait le mieux aux besoins, et était un bon compromis vis à vis du

temps nécessaire à la mise en place de cette librairie par rapport aux fonctionnalités ap-

portées.

C’est donc la solution que nous avons choisie.

24

8 Architecture proposée

8.1 Architecture

Voici le schéma de l’architecture globale proposée :

Application

linlxd lco

SQLEngineIHM

DLLOCX

FIG. 14 – Architecture proposée

Le développement devra se diriger vers deux buts :

Tout d’abord développer une librairie (DLL) qui contiendra tout le moteur de l’application.

C’est cette DLL qui s’occupera des accès aux bases de données Landmark, Linear, ou

Landcover.

Toute application pourra directement utiliser cette DLL pour effectuer des requêtes. Son

utilisation sera donc simplifié par rapport aux interrogations directes des bases.

Le deuxième but du développement consistera à créer une interface graphique, repo-

sant sur le moteur, la librairie, encapsulé. Cette interface graphique sera contenu dans un

OCX.

25

Toute application pourra utiliser directement l’OCX pour avoir les menus et boutons

nécessaires à l’exécution de requêtes, et donc nécessitera très peu de nouveaux dévelop-

pements.

Ce choix d’architecture a été motivé par la flexibilité nécessaire aux développements

futurs chez PTV Loxane, pour permettre une réutilisation extrêmement simplifiée et efficace

des travaux passés.

8.2 Langage

8.2.1 SQLLXN

Pour permettre une exécution simplifié d’un script, ou de requêtes, un langage particu-

lier devait être mis en place. Etant donnée qu’il s’agirait d’un langage de requêtage, le SQL

a été évidemment choisi. Les requêtes dans ce langage sont en général de la forme :

�SELECT t o t o .∗ FROM t o t o WHERE t o t o .1 < 2� �

Cependant, ce langage ne contient aucune caractéristique propre aux requêtes géo-

graphiques. Et de plus, bon nombre de fonctions du SQL seraient totalement inutiles sur

les bases de PTV Loxane.

Ainsi, un nouveau langage devait être défini, qui serait à la fois une sous-partie du SQL,

et une extension de ce langage, propre aux requêtes géographiques.

8.2.2 Requêtes supplémentaires

Pour répondre aux besoins de l’exécution à partir d’un script, il fallait pouvoir gérer les

entrées et sorties directement à partir des requêtes exécutées.

Deux nouveaux types de requêtes ont donc été ajoutés aux spécifications, permettant

de répondre à cette attente :

CREATE TABLE Une requête permettant d’ajouter dans la base de données des tables

se trouvant sur le disque dur. Cette requête nécessitait logiquement trois arguments. Tout

d’abord, le chemin de la table sur le disque dur, pour que l’application puisse l’ouvrir. En-

suite, le type de cette table que l’on souhaitait ouvrir, à savoir Landmark, Linear ou Land-

cover. Et enfin, le nom que l’on souhaitait donner à la table dans la base de données. C’est

26

ce nom qui sera utilisé par la suite dans tous les requêtages. Chacun de ces arguments

est séparé par une virgule.

La requête ressemblera donc à ceci :

CREATE TABLE <path>, <type>, <name>

WRITE TABLE Une requête permettant d’enregistrer les tables de la base de données

sur le disque dur. Cette requête possède un argument obligatoire et deux arguments op-

tionnels. Le premier consiste à donner le nom de la table ou des tables à enregistrer sur

le disque dur. Si l’on souhaite enregistrer plusieurs tables, les noms sont séparés par des

virgules. L’argument suivant consiste à donner le nom de fichier que l’on souhaite sur le

disque pour la table. Dans le cas de plusieurs tables, cet argument est ignoré. Et enfin,

le dossier dans lequel on souhaite enregistrer les tables. Cet argument est optionnel, car

l’application possède un chemin par défaut, qui sera utilisé dans le cas de l’absence de cet

argument.

La requête ressemblera à ceci :

WRITE TABLE toto AS table-importante1 IN C:\

8.2.3 Requêtes géographiques

Pour que la prise en charge des requêtes géographiques soit la plus complète et la

plus utile possible, de nombreuses recherches ont été faites, notamment en s’inspirant de

PostGIS, qui est une extension du système de gestion de bases de données relationnel à

objets PostgreSQL qui permet de stocker des objets SIG dans une base. PostGIS permet

donc de gérer des objets spatiaux à l’aide de requêtes dans une syntaxe similaire au SQL.

Afin de sélectionner et de classer les fonctionnalités à implémenter, une demande de

conseils a été effectuée auprès de Pierre-Matthieu PETILLOT, ingénieur développement

chez PTV Loxane, responsable de la cartographie, et qui travaille quotidiennement avec

les technologies d’interrogation de bases géographiques, et notamment PostGIS.

Grâce à son aide, nous avons pu constituer une liste des fonctionnalités suivant trois prio-

rités :

Priorité 1

CONTAINS Cette fonction permet de savoir si un élément géographique en contient

un autre.

27

INTERSECT Cette fonction teste si un élément géographique en coupe un autre.

TOUCHES On peut vérifier avec cette fonction si un élément en “touche spatialement”

un autre. Cela arrive si l’intérieur de deux géométries ne se coupent pas, mais si leurs

contours le font.

Priorité 2

WITHIN Cette fonction permet de savoir si un élément est à l’intérieur d’un autre. C’est

le contraire du CONTAINS

DISTANCE Cette fonction permet de savoir la distance qu’il existe entre deux élé-

ments.

EQUALS Indique si deux géométries sont égales ou non.

OVERLAPS Permet de savoir si une géométrie passe au dessus d’une autre, mais

pas complètement (sinon, ce serait un WITHIN ou CONTAINS).

Priorité 3

POINTONSURFACE Permet de savoir si un point se trouve sur une géométrie en

particulier

AREA Renvoie l’air de la géométrie, dans le cas des surfaces.

NUMGEOMETRIES Permet de connaître le nombre de géométries d’un ensemble,

comme dans le cas des Landcovers, qui contiennent aussi bien des points que des lignes

ou des surfaces.

GEOMETRYN Permet de travailler avec la nieme géométrie d’un ensemble, comme

les Landcovers

GEOMETRYTYPE Permet de connaître le type de géométrie (point, ligne, surface).

28

BOX2D Cette fonction permet de récupérer un carré, correspondant à l’enveloppe de

la géométrie.

Bien entendu, cette liste de fonctions et de priorités n’était présente qu’à titre indicatif.

En effet, du fait de limitations des librairies de PTV Loxane, certaines fonctions ne pou-

vaient pas être mises en place suffisamment facilement et efficacement dans les délais

imposés.

8.2.4 Spécifications

Ainsi, après toutes les définitions de termes à utiliser et de nouvelles requêtes à mettre

en place, nous avons atteint une définition de grammaire qui se décompose en trois par-

ties. Voici donc les différentes BNF (forme de Backus-Naur) du langage mis en place.

Tout d’abord les requêtes classiques, avec les composantes géographiques incluses :

�SELECT < f i e l d − l i s t >

FROM <tab le_def >

[WHERE <where−expr >]

[ SPATIALREF <spa t i a l _ re fe rence > ] ;

< f i e l d − l i s t > : : = DISTINCT < f i e l d _ r e f > | < f i e l d −spec>

| < f i e l d −spec> , < f i e l d − l i s t >

< f i e l d −spec> : : = < f i e l d _ r e f >

| < f i e l d _ f u n c > ( [ DISTINCT ] < f i e l d −re f > )

| Count ( ∗ )

< f i e l d −func > : : = AVG

| MAX

| MIN

| SUM

| COUNT

< f i e l d _ r e f > : : = [ < tab le_ re f > . ] f ie ld_name

29

<tab le_def > : : = [ ’ data_source ’ . ] table_name [ t a b l e _ a l i a s ]

[ , [ ’ data_source ’ . ] table_name [ t a b l e _ a l i a s ] ] ∗

< tab le_ re f > : : = table_name

| t a b l e _ a l i a s

<where−expr > : : = <expression > [ { < l og i ca l _ope ra to r > <expression > }∗ ]

<expression > : : = < f i e l d _ r e f > <operator > <operand>

| < f i e l d _ r e f > < spa t i a l _ope ra to r > <WKT_string>

| < f i e l d _ r e f > < spa t i a l _ope ra to r > < f i e l d _ r e f >

| < f i e l d _ r e f > IN ( <operand>

[ { <comma> <operand > } ] ∗ )

| DISTANCE( < f i e l d _ r e f > ,

<WKT_string >) <operator > <operand>

| DISTANCE( < f i e l d _ r e f > , < f i e l d _ r e f >)

<operator > <operand>

<operator > : : = <

| >

| <=

| >=

| =

| ==

| !=

| <>

| LIKE

< log i ca l _ope ra to r > : : = OR

| AND

| NOT

<spa t i a l _ re fe rence > : : = CS_WGS84

| CS_WGS72

| CS_RGF93

30

| CS_LXN_PROJSIMPLE_NH

| CS_DIRECT_MERCATOR_WGS84

| . . .

< spa t i a l _ope ra to r > : : = CONTAINS

| INTERSECT

| TOUCHES

| WITHIN

| . . .� �Puis les requêtes permettant d’ajouter une table dans la base de données, suivant son

chemin, son type, et son nom :

�CREATE TABLE < dec la ra t i on_ tab le >;

< dec la ra t i on_ tab le > : : = <path > , <type > , <name>� �Et enfin, les requêtes permettant de sauvegarder une des tables de la base directement

sur le disque, pour une utilisation future :

�WRITE TABLE < w r i t e _ t a b l e _ d e c l a r a t i o n >;

< w r i t e _ t a b l e _ d e c l a r a t i o n > : : = table_name [ , table_name ]∗

[ { AS name_on_disk } ] [ { IN <path > } ]� �De plus, dans tous les scripts, un caractère permet de rajouter des commentaires :

�<comments> : : = #<anything >� �A noter également que dans les scripts, chaque requête est terminée par un point-virgule,

et que les espaces ou sauts de ligne n’interfèrent pas avec la requête.

31

9 Développement de la librairie

9.1 Prévision de l’architecture

Une architecture de la librairie a tout d’abord été choisie pour préparer le développe-

ment du projet.

SQLLXN

SQLParser SQLQueryResult

SQLUtilsSQLDatabase

SQLTable

Librairie (DLL)

lxwSQLEngine

FIG. 15 – Architecture librairie

Comme nous pouvons le voir sur ce schéma, le but était de créer une DLL (une librai-

rie), contenant toutes les fonctions nécessaires à la gestion de requêtes et à leur exécution.

Pour cela, différentes structures devront être mises en places :

SQLTable et SQLDatabase Il a été définit une structure permettant de contenir chacune

des tables, tout d’abord séparément (SQLTable), puis ensuite ensemble (SQLDatabase).

32

Ces structures permettront de conserver différentes informations supplémentaires par rap-

port aux tables brutes. Elles permettront également de posséder un niveau d’abstraction

supplémentaire : en effet, si on a besoin d’information sur des tables, on ne devra pas

les interroger séparément, mais on pourra directement demander à la base de données

(SQLDatabase).

SQLEngine Le développement devra également séparer le parseur et l’évaluateur, qui

sera dans le SQLEngine. Le parseur sera issu de celui d’OGR/Mitab mais grandement

remanié. La séparation entre le parseur et l’évaluateur permettra une plus grande flexibi-

lité : En effet, si dans le futur on souhaite changer uniquement l’un des éléments pour un

nouveau plus performant, ce sera faisable aisément.

SQLQueryResult Une structure de donnée sera également importante, pour stocker les

résultats de chaque requête. En effet, dans un premier temps, le développement tendra à

n’avoir qu’une seule table en sortie, mais il n’est pas exclu que dans un second temps la

requête puisse renvoyer des tables dans différents formats (Landmark, Linear, Landcover).

Il faut donc créer une structure appelée SQLQueryResult qui contiendra l’ensemble des

résultats d’une requête donnée.

SQLUtils et SQLLXN Les deux structures restantes pourront contenir d’une part les fonc-

tions génériques qui pourraient être utiles (SQLUtils) et d’autre part, certaines structures

qui seront communes à tous les éléments (SQLLXN).

Quelques fonctions devront être également disponibles pour les développeurs exté-

rieurs, comme par exemple :

�/ / Permet d ’ exécuter un s c r i p t

bool Execu teSc r i p tF i l e ( char∗ in_st rF i leName ) ;

/ / Permet de récupérer l e numéro du de rn ie r r é s u l t a t

bool GetResult ( unsigned long ∗ out_u lResu l t ID ) ;

/ / Permet de supprimer une tab le de l a base

bool RemoveTable ( i n t in_ iTab le Index ) ;� �Je vais maintenant vous exposer comment arriver à cette architecture.

33

9.2 Prise en main du parser

Les sources du parser en lui même se trouvaient dans la librairie OGR/Mitab, sous une

licence qui nous permet la modification et la redistribution de ces sources, sans nous forcer

à rendre publiques les modifications effectuées.

Pour pouvoir entamer le processus de développement proprement dit, une prise en

main de ce parser était évidemment nécessaire avant toute modification. Cette prise en

main a pris un certain temps, du fait du manque de documentation du parser. Toutefois,

après de nombreux essais et un renommage massif de toutes les variables pour suivre les

règles de codages de PTV Loxane, une compréhension schématique de toutes les fonc-

tions a pu être acquise, permettant ensuite leurs modifications.

Une documentation a été écrite pendant cette période, détaillant chaque fonctionnalité

des outils présents dans ce parser pour permettre des évolutions et des maintenances

aisées dans le futur.

9.3 Nettoyage et conversion

La tâche suivante consistait à convertir ce parser du langage de programmation C, vers

le langage C++. Ce dernier est en effet de plus haut niveau, permettant un niveau d’abs-

traction plus élevé, tout en permettant d’effectuer des fonctions plus nombreuses. De plus,

ce langage est celui traditionnellement utilisé par PTV Loxane dans la majorité de ses dé-

veloppements, en dehors de certains cas particuliers.

Ainsi, une très grande part des fonctions présentes dans ce parser devait être réorga-

nisée, pour permettre un fonctionnement optimal et simplifié pour la maintenance. De plus,

de nombreuses parties du code ont pu être supprimées, du fait de leur obsolescence.

9.4 Adaptation

Le parser a été conçu à l’origine pour une sous partie du langage SQL dont la BNF

(forme de Backus-Naur) telle que présente dans le parser original se trouve dans les an-

nexes.

La partie WHERE de la requête n’était pas présente, mais on peut tout de même noter

que en plus des calculs de bases, le parser était capable de reconnaître et d’analyser les

34

requêtes contenant des LIKE comme

select * from toto where toto.dep LIKE "Ai\%"

pour rechercher tous les départements commençant par “Ai” comme l’Ain et l’Aisne, et les

requêtes contenant des IN comme

select * from toto where toto.dep IN ("Ain", "Aisne")

pour trouver les départements étant soit l’Ain soit l’Aisne.

Cependant, certaines fonctionnalités n’étaient pas utiles à PTV Loxane, comme par

exemple l’utilisation du SORT, qui permet traditionnellement de trier les éléments dans les

tables. Les bases de chez PTV Loxane étant indexées suivant certains champs, si l’utilisa-

teur veut trier les données pour une raison ou une autre, il peut toujours le faire en utilisant

les clients graphiques, comme le Loxane Pro :

FIG. 16 – Tri dans le Loxane Pro

Ainsi ces fonctions ont pu être mises de côté pour permettre de ce concentrer sur le

coeur de l’application.

9.5 Création des structures de données

9.5.1 Base de données

Le parser étant fonctionnel, il fallait maintenant mettre en place des structures de don-

nées permettant d’une part, de stocker les bases de données géographiques dans des

structures compréhensibles et accessibles par le parser et d’autre part, de regrouper toutes

ces tables dans une structure qui aura le rôle de base de données, et donc, regroupant

toutes les tables.

35

La structure des tables, de la base et du parser ressemble à ceci :

SQLParser

SQLLXN

SQLDatabase

SQLTable

FIG. 17 – Structure du parser avec la base et les tables

Comme nous pouvons le voir sur ce graphe, le parser (SQLParser) nécessite une (ou

plusieurs) base de données (SQLDatabase) qui elle même nécessite une ou plusieurs

tables (SQLTable). SQLLXN correspond à un fichier contenant des informations néces-

saires à pratiquement toutes les structures du projet. Il permet d’avoir une hiérarchie en

arbre, plutôt que cyclique, en graphe.

Cette structure particulière a plusieurs avantages :

– Du fait de la création spécifique de structures pour le parser, cela lui permettait de vé-

rifier directement pendant l’étude de la requête la validité des champs la constituant.

Ainsi, si par exemple nous cherchions des informations sur la colonne ‘a’ de la

table toto, le parser serait capable d’aller chercher dans les différentes structures s’il

existe bien une colonne ‘a’ dans la table toto, et vérifier le type de données qu’elle

contient pour, par exemple, ne pas pouvoir faire de multiplications entre des chaînes

de caractères.

– De plus, ces structures permettent un niveau d’abstraction supplémentaire. En effet,

si un jour les bases de données géographiques de chez PTV Loxane venaient à

évoluer, le nombre de modifications a apporter à l’application serait minime, vis à

vis du nombre de modifications qu’il aurait fallu appliquer sans l’utilisation de ces

structures.

– Enfin, ce niveau d’abstraction et ce cloisonnement permettent de changer extrême-

ment simplement la structure de stockage des informations dans la base de données.

Si par exemple, une structure plus performante est trouvée, il suffira alors qu’elle

36

implémente les mêmes fonctions, et l’application continuera de fonctionner normale-

ment.

9.5.2 Requêtes

Des structures ont aussi dû être crées pour enregistrer les informations issues des re-

quêtes.

Voici la structure des requêtes :

QUERY

COLUMN_DEFINITION ORDER_DEFINITION TABLE_DEFINITION JOIN_DEFINITION SUMMARY FIELD_OPERATION

FIG. 18 – Structure d’une requête

TABLE_DEFINITION La première étape a été de créer une structure permettant de sto-

cker les informations sur les tables présentes dans la requête. Cette structure stocke par

exemple l’alias de la table, ce qui est unique à la requête, ou son index dans la base de

données, permettant ainsi de conserver ce lien, en vue d’un traitement futur.

Cette structure correspond à la TABLE_DEFINITION du graphe ci-dessus.

COLUMN_DEFINITION Le deuxième point était essentiel au stockage de la requête : en

effet, il fallait à présent sauvegarder les différents champs présents dans la requête. Ces

différents champs permettront d’une part de faire une projection dans les bases de don-

nées, et d’autres part, d’effectuer certaines fonctions, comme la somme, ou la recherche

du maximum.

Cette structure contient évidemment des liens vers les champs correspondants dans la

bases de données. Elle est nommé COLUMN_DEFINITION dans la structure ci-dessus.

SUMMARY Ensuite la structure SUMMARY contient les informations nécessaires à l’établis-

sement de rapports dans les requêtes, c’est à dire que lorsqu’on demande une somme,

une moyenne, ou une valeur maximale, elles seront stockées dans cette structure.

ORDER_DEFINITION et JOIN_DEFINITION Les deux structures ORDER_DEFINITION et

JOIN_DEFINITION ne sont pas utilisées pour le moment et ne le seront peut-être pas. En

effet, ces deux structures sont issues du parser original, et ont été conservées afin de

37

préserver un maximum d’informations, mais la structure ORDER_DEFINITION servait à enre-

gistrer les informations d’ordonnancement de la liste, ce qui n’est pas utile dans le cas des

bases de données géographiques, et la structure JOIN_DEFINITION qui permettait d’enre-

gistrer les informations de jointures, n’est pas encore utilisé, car la fonction de jointure n’est

pas encore implémentée.

FIELD_OPERATION La dernière structure, FIELD_OPERATION, est plus particulière : elle

permet de stocker les informations concernant la partie sélection de la requête (après le

WHERE). En effet, cette partie de la requête représente une suite d’opérations, chargée de

sélectionner les lignes voulues dans la ou les tables de données géographiques.

Cette structure est particulière, car pour stocker efficacement une suite d’opérations

logiques, une structure d’arbre a été choisie :

FIELD_OPERATION

First Sub Operation Second Sub Operation

First Sub Operation Second Sub Operation First Sub Operation Second Sub Operation

FIG. 19 – Structure des opérations

Ainsi par exemple, si nous devions enregistrer la requête suivante, qui permet de sto-

cker les éléments qui valent moins de vingt ou qui sont compris entre cinquante et cent :

SELECT * FROM toto WHERE toto.1 < 20 OR

(toto.1 > 50 AND toto.1 < 100)

38

L’arbre équivalent serait celui-ci :

FIELD_OPERATION

Operator : OR

First Sub Operation

Operator : <

Second Sub Operation

Operator : AND

First Sub Operation

Column : toto.1


Value : 20

First Sub Operation

Operator : >


Operator : <

First Sub Operation

Column : toto.1


Value : 50

First Sub Operation

Column : toto.1


Value : 100

FIG. 20 – Exemple d’un arbre d’opérations

Cette structure nous a semblé le meilleur choix pour plusieurs raisons : tout d’abord, elle

décompose clairement la partie sélection de la requête, ce qui facilite le travail futur. En-

suite, elle permet de conserver l’ordre des opérations, en plaçant les opérations prioritaires

plus bas dans l’arbre, puisque nous commencerons à traiter les opérations en partant du

bas. Enfin, pour permettre de valider ou non cet arbre, un simple algorithme récursif pour

atteindre notre objectif.

9.6 Moteur

Le moteur est le véritable cœur de l’application : c’est cette partie qui est responsable

du choix de chacun des éléments que l’on pourrait avoir en retour de la requête. En effet, le

parser n’est responsable que de l’identification des champs de la requête, et des fonctions

appliquées. Mais ce n’est pas lui qui dans la liste des informations, va désigner celles qui

ont été choisies par la requête.

Ainsi dans un premier temps, il fallait créer des fonctions capable de choisir ou non les

éléments d’une ou plusieurs tables, qui vérifient l’expression logique de la requête.

Cette sélection se passe en deux temps :

Tout d’abord, une présélection, qui permet de choisir les éléments par leurs critères

géographiques, si la requête contient des contraintes à ce sujet. Des fonctions de pré-

sélection se trouvant déjà dans les librairies de PTV Loxane, il suffisait uniquement de créer

un lien entre la requête, et ces fonctions. Effectuer cette sélection géographique avant la

sélection par l’évaluation de la requête permet d’effectuer cette sélection sur un nombre

beaucoup moins important d’éléments, et ainsi gagner un temps non négligeable.

39

Ensuite, les fonctions d’évaluations qui se chargent de la sélection proprement dite

entrent en jeu. Elles parcourent l’arbre des opérations (tel que dans la figure 20 page 39)

en partant des feuilles et résolvant ainsi les opérations atomiques, pour remonter ensuite

jusqu’au sommet, et ainsi résoudre entièrement la requête. Cette séquence d’évaluation

est effectuée pour chaque élément des tables à traiter. Lorsqu’un élément satisfait la re-

quête, il est mis de côté pour le traitement futur.

Une fois tous les éléments choisis mis de côté, il convient de les copier de la table d’ori-

gine vers une nouvelle table que l’on pourra par exemple sauvegarder sur le disque, ou

utiliser dans une requête futur. Pour effectuer cette copie, au lieu de repartir de zéro, j’ai

décidé de réutiliser les librairies que j’avais développées au début de mon alternance pour

me permettre de comprendre le fonctionnement des outils de PTV Loxane (paragraphe 5.4

page 17). Ces librairies ne devaient pas être réutilisées à l’origine, mais comme elles cor-

respondaient à peu de choses près aux fonctions dont j’avais besoin, notamment pour la

copie, j’ai pu les inclure au projet sous le nom de SQLUtils, après quelques modifications

permettant de peaufiner leurs fonctionnalités, et de les intégrer le plus proprement possible.

Voici à quoi ressemblait l’architecture du projet à ce niveau d’avancement :

lxwSQLEngine

SQLLXN

SQLParser

SQLUtilsSQLDatabase

SQLTable

FIG. 21 – Structure avec le parser

40

9.7 Traitement des données

Par la suite, une fois la requête analysée, et la sélection des éléments effectuée, il res-

tait le stockage des tables. En effet, il aurait été facile d’enregistrer directement les tables

en sortie sur le disque, mais comment aurions nous pu faire de nouvelles requêtes sur ces

tables par la suite ? Il aurait fallu manuellement les ajouter à la base de données, tout en

connaissant le chemin de la table sur le disque dur.

Ainsi une nouvelle structure de stockage fut créée, nommé SQLQueryResult, et s’insé-

rait dans l’architecture telle que sur le schéma suivant :

lxwSQLEngine

SQLLXN


SQLUtilsSQLDatabase

SQLTable

FIG. 22 – Structure finale du coeur de l’application

Cette structure avait pour particularité de permettre d’une part d’enregistrer les trois

types de tables générées en sortie (Landmark, Linear et Landcover) dans une même struc-

ture, ce qui autorisait l’accès à l’ensemble des résultats d’une requête en un seul accès, et

d’autre part, de réinsérer directement ces tables dans la base de données pour une réutili-

sation future, sous un nom générique, et distinct à chaque requête.

Il a été choisi qu’à la fin de l’exécution de chaque requête, si elle produit un résultat,

la base résultat sera ajoutée automatiquement à la base de données. Toutefois, comme

l’utilisateur ne peut pas choisir un nom pour chacune des tables résultats, un nom automa-

41

tique sera attribué. Il aura pour forme Result-n-type, avec n correspond à l’identifiant de

la requête (son numéro d’exécution), et le type constitué des trois lettres caractéristiques

du format de la table (lxd pour Landmark, lin pour Linear, et lco pour Landcover). Le type a

été placé là pour permettre d’avoir des tables de différents formats dans le même résultat

d’une requête, et donc avec le même identifiant.

Par exemple :

Result-2-lco

Toutes les requêtes exécutées ont un numéro, même celles ne produisant pas de ré-

sultats, ceci pour faciliter la réutilisation des résultats précédents lors de la conception de

scripts.

9.8 Requêtes géographiques

En parallèle de cette mise en place du parseur et du traitement des données, les re-

quêtes géographiques ont été progressivement implémentées.

Suite à la liste de priorités établie au paragraphe 8.2.3 page 27, et les limitations des

librairies PTV Loxane, il a donc été décidé d’un commun accord avec mon tuteur, d’implé-

menter uniquement les fonctions INTERSECT, WITHIN et DISTANCE, qui ont été jugées les

plus importantes et utiles sur le court terme. Cependant, les possibilités d’évolutions de-

vaient rester ouvertes, afin de pouvoir ajouter facilement les fonctions restantes.

Pour pouvoir les développer, il a fallu passer par plusieurs étapes :

1. Tout d’abord rechercher comment algorithmiquement ces fonctionnalités allaient im-

pacter le parseur, le moteur, les structures...

2. Modifier les différents modules de l’application s’il y a lieu.

3. Effectuer des tests de fonctionnement, permettant de savoir si les nouvelles fonctions

étaient opérationnelles.

4. Effectuer des tests de non régression, permettant de vérifier que l’application dans

son ensemble continue de fonctionner malgré ces modifications.

5. Enfin, éliminer les différentes fuites mémoires qui ont pu être introduites inopinément,

malgré l’attention portée au développement.

Ces étapes ont été suivies tout au long du développement de l’application, pour favo-

riser une grande qualité du code et sa stabilité. Cependant cette procédure a particulière-

ment été marquée pendant cette période d’ajout de fonctions, du fait de la sensibilité des

modifications à apporter sur l’application déjà fonctionnelle.

42

Attribut “Geometry” Avant de commencer quoi que ce soit, il fallait d’abord définir des

termes pour pouvoir poser des conditions sur des géométries. En effet, lorsque l’on veut

tester un attribut, il suffit de donner son nom, mais quel est le nom d’une géométrie ? Il a

été décidé que ce serait “Geometry”, ce qui paraissait le plus logique dans la continuité de

la norme SQL.

WITHIN et INTERSECT Une fois cette norme définie, le travail a pu commencer. Au ni-

veau du parseur, pour les fonctions INTERSECT et WITHIN, il a semblé dans un premier

temps que la tâche serait facile. En effet, ces fonctions avaient à peu près la même struc-

ture que les tests classiques à savoir une opérande, une opération, et une autre opérande,

à savoir par exemple, avec le WITHIN :

toto.Geometry WHITIN titi.Geometry

Cependant, lors de l’étude de la mise en place de ces fonctions, je me suis rendu compte

que le moteur avait besoin des informations concernant la partie géographique des re-

quêtes avant l’évaluation réelle de celle-ci, pour avoir une liste des éléments à discriminer.

Il a donc fallu créer une nouvelle structure dans le parseur, contenant toutes les infor-

mations de la requête concernant la partie géographique, et qui seraient transmises au

moteur, lui permettant de créer des listes des éléments qui correspondent aux critères, et

qui seraient ensuite validés par l’évaluation classique.

DISTANCE La fonction de DISTANCE était plus particulière. En effet, elle n’a pas la forme

des autres fonctions qui ont dû être mises en place : alors que la forme classique était

OPERAND OPERATOR OPERAND

la forme de cette fonction était

DISTANCE(OPERAND, OPERAND) OPERATOR OPERAND

La fonction distance fonctionnait donc dans son ensemble comme une opérande clas-

sique. Il fallait d’abord la calculer, pour ensuite passer dans l’évaluateur de manière clas-

sique. Et pour pouvoir la calculer, il fallait transmettre les données au moteur de manières

distinctes, lui permettant de traiter séparément cette opération. Heureusement, la structure

de données FIELD_OPERATION (décrite sur le schéma 19 page 38) était suffisamment versa-

tile pour stocker les données nécessaires, ce qui a permis de transmettre sans encombres

les données nécessaires au moteur, qui n’avait plus qu’a calculer la distance entre les deux

opérandes pour effectuer ensuite l’opération classique.

Dans la première version de ces trois fonctions, les deux opérandes géographiques

43

étaient constituées d’une part de la géométrie de la table concernée, et d’autre part, d’une

chaîne au format WKT (Well Known Text), qui permet entre autres choses de définir une

entité spatiale au format texte. Ce format est défini dans les annexes. Ainsi, par exemple,

on pouvait écrire une instruction ainsi :

DISTANCE(toto.Geometry, POINT(10, 20)) < 100

ce qui permettait de choisir toutes les géométries de la table toto dans un rayon de 100

mètres autour du point de coordonnées (10,20).

Il a donc fallu mettre en place une reconnaissance des chaînes WKT dans le parseur,

pour éviter qu’une erreur soit renvoyée à l’utilisateur, et créer une interprétation de ces

chaînes dans le moteur pour pouvoir effectuer les différents calculs. Toutefois, grâce au

travail effectué dans le passé par des apprentis, et notamment M. Laurent BRIDELANCE, il

existait dans les librairies de PTV Loxane des outils permettant de transformer ces chaînes

WKT en tableaux de points, plus facilement utilisables en programmation.

Cependant, ces coordonnées ne signifient rien en elles-mêmes. En effet, différents sys-

tèmes de coordonnées existent et peuvent être choisis par l’auteur de la requête. Une liste

de différents systèmes géodésiques ou de projections se trouve en annexe.

Ainsi il a fallu ajouter une nouvelle dimension aux requêtes, à savoir le référentiel spatial

de la requête. Si par défaut, toutes les coordonnées sont traitées comme du WGS84, qui

est le référentiel spatial communément utilisé dans le monde, notamment avec les GPS,

l’utilisateur pourrait vouloir utiliser un autre référentiel.

SPATIALREF Pour cela, une nouvelle clause a été rajouté à la requête : SPATIALREF. Il

suffit à l’utilisateur de rajouter la clause SPATIALREF à la fin de sa requête, suivi du système

géographique souhaité (dont le nom a un format prédéfini) pour que la requête soit traitée

dans le référentiel de l’utilisateur, et que toutes les conversions nécessaires se fassent en

toute transparence.

Par exemple pour la requête soumise

SELECT *

FROM toto

WHERE DISTANCE(toto.Geometry, POINT(10,20)) < 100

SPATIALREF PROJCS_LAMBERT_II_ETENDU

l’application assumera que la chaîne WKT POINT(10,20) indique des coordonnées en

44

Lambert II étendu, et le convertira le cas échéant dans le référentiel de la base toto.

A ce point là, les requêtes géographiques étaient donc possibles, mais il manquait en-

core les requêtes croisées, ce qui permettait le plus grand nombre de possibilités. Ainsi, il

n’était pas encore possible de faire une requête du type “je veux toutes les villes ayant un

hôpital à moins de 2km de distance”.

Il a donc fallu développer un mécanisme pour pouvoir effectuer ce type de requêtes, ce

qui a posé de nombreux problèmes, notamment sur l’intrication des différents algorithmes,

et sur les performances générales de l’application. En effet, lorsque l’on veut effectuer la

requête ci-dessus, qui s’exprimerait ainsi :

SELECT villes.*

FROM villes, hopitaux

WHERE DISTANCE(villes.Geomtry, hopitaux.Geometry) < 2000

Il faut pour chaque ville testée, calculer la distance avec chacun des hôpitaux de la base

de données ce qui demande plus de temps que de calculer pour chaque ville une seule

distance.

9.9 Exemple de script

Suite aux différents développements, nous pouvons avoir un script qui ressemblerait à

ceci :

�CREATE TABLE C : \ Loxane \ Bdd \ TA20077 \ France \ Landcover \ admin3 . lco ,

Landcover , departement ;

CREATE TABLE C : \ Loxane \ Bdd \ TA20077 \ France \ Landmark \ c i t i e s 5 . lxd ,

Landmark , v i l l e s ;

# Sélect ionne tous les a t t r i b u t s de l a tab l e

SELECT w.∗

# Choix de l a tab le département , avec son a l i a s w

FROM departement w

# Sélect ionne les départements à moins de 100km du po in t (1 ,1 )

WHERE DISTANCE(w. geometry , POINT(369377 1986171)) < 100000

# U t i l i s a t i o n du r é f é r e n t i e l s p a t i a l de Lambert I I étendu

45

SPATIALREF PROJCS_LAMBERT_II_ETENDU;

# Sélect ionne tous les a t t r i b u t s de l a tab l e v i l l e s

SELECT x .∗

# Récupère les r é s u l t a t s de l a requête précédente , e t v i l l e s

FROM Result−2− l co w, v i l l e s x

# Sélect ionne tou tes les v i l l e s s i tuées dans les départements

# précédemment c h o i s i s

WHERE x . geometry WITHIN w. geometry ;

# E c r i t l e de rn ie r r é s u l t a t obtenu

WRITE TABLE Result−3− l xd

# Sous l e nom Ci t ies InDep

AS Ci t ies InDep

# Dans l e doss ie r C : \ Tables \

IN C : \ Tables \ ;� �On peut noter que ce script est réellement utilisé dans les différents tests effectués au long

du développement.

Il produira une base contenant toutes les villes contenues dans les départements situés

dans un rayon de 100km du point de coordonnées (369377,1986171) dans la projection

Lambert II étendu, point qui correspond à Bordeaux. Tout d’abord, le résultat de la première

requête concernant les départements sera le suivant :

46

FIG. 23 – Départements sélectionnés

Le résultat de la deuxième requête correspondra aux villes se trouvant sur les départe-

ments ci-dessus. Voici les villes en résultat, superposées aux départements, pour que l’on

voit bien la correspondance :

FIG. 24 – Villes sélectionnées

47

9.10 Encapsulation

Un des intérêts principaux de ce projet, était de pouvoir l’utiliser dans de nombreux outils

de PTV Loxane. En effet, en créant une librairie, l’accès aux fonctions principales serait fa-

cilité, et pourrait être utilisé par d’autres développeurs sans avoir à connaître le programme.

Une librairie est en fait une application complète, qui ne contient pas ce qu’il faut pour

être lancée. A la place, elle contient quelques fonctions d’accès, permettant aux dévelop-

peurs d’utiliser cette application, mais sans connaître les mécanismes en jeux dedans.

SQLLXN


SQLUtilsSQLDatabase

SQLTable

Librairie (DLL)

lxwSQLEngine

FIG. 25 – Encapsulation de l’application

48

10 Interface graphique/OCX

Le grand intérêt d’un OCX est qu’il peut contenir directement une interface graphique

et être intégré tel quel dans une application quelconque, qui nécessite les fonctions implé-

mentées dans celui-ci.

Au moment de l’écriture de ce rapport, l’interface graphique n’était pas finalisée. Cepen-

dant une version d’un outils qui a été développé pour effectuer des tests peut être montré

pour donner une idée d’une interface possible :

FIG. 26 – Interface actuelle

Note : Cette illustration ne représente en aucun cas la qualité de l’interface finale.

Nous pouvons voir sur ce schéma plusieurs modes d’exécution :

Le mode “à la main”, qui consiste à ajouter une table en écrivant la requête correspon-

dante dans le champ ajout de table, et d’écrire une requête.

Le deuxième mode qui est le mode scripté, consiste à indiquer le chemin d’un script,

qui sera exécuté lors du lancement du moteur (après appuis sur le bouton “GO ! ! ! !”).

49

Dans les deux cas, nous pouvons choisir le dossier de sortie des requêtes exécutées.

Cette interface a pour avantage d’être simple à l’extrême, mais trop pour certains. En

effet, une aide à la conception de requêtes pourrait être envisagée pour faciliter l’utilisation

de l’application par le plus grand nombre.

Ainsi, l’interface en cours de développement devra fournir des aides à la conception de

requêtes, comme par exemple un menu contenant tous les champs des tables actuelle-

ment chargées dans le moteur, ou un autre menu incluant toutes les opérations possibles

sur les champs actuellement sélectionnés.

De nombreuses idées peuvent être ajoutées à cette conception d’interface graphique,

comme la complétion automatique du code SQL en cours de frappe, la détection à la volée

des erreurs syntaxiques, etc.

50

11 Gestion de projet

Je vais ici détailler les différents planning que j’ai dû respecter pour atteindre mon ob-

jectif dans les temps, et quels ont été les dispositions prises pour atteindre cet objectif.

Je tiens à préciser que mon projet n’avait pas de contrainte de temps forte, étant donnée

qu’il s’orientait vers la Recherche et le Développement. Cependant ces plannings permet-

taient de marquer les étapes importantes du projet.

11.1 Planning

11.1.1 Diagramme de Gantt

Le rythme de l’alternance compliquait la tâche de création d’un planning consistant.

Cependant j’ai tenté au maximum de compartimenter les tâches durant chaque période en

entreprise, pour éviter de laisser du travail en cours lorsque je devais quitter l’entreprise.

A noter que les périodes à l’université ne sont pas représentées sur ce planning.

Ce diagramme est la version réduite du diagramme de Gantt que j’ai utilisé en entre-

prise. Sa version complète se trouve en annexe.

51

FIG. 27 – Diagramme de Gantt réduit

52

11.1.2 Diagramme de PERT

Le diagramme de PERT (qui signifie Project Evaluation and Review Technique) permet

de visualiser la dépendance de chacune des tâches et ainsi de procéder efficacement à

leur ordonnancement.

Du fait de sa taille, ce diagramme se trouve uniquement dans les annexes. Je recom-

mande par ailleurs une lecture de ce document au format numérique pour que ce dia-

gramme soit lisible.

11.2 Réunions

Au cours de mon alternance j’ai pu participer à plusieurs types de réunions :

• Les réunions générales

Ces réunions étaient organisées à les mois par le Président Directeur Général de la

société, Maxime BELLEMIN, et l’ensemble du personnel était convié. Ces réunions

permettaient de faire un point sur l’état d’avancement des affaires en cours, celles qui

étaient gagnées ou perdues, l’arrivée de nouveaux employés etc.

J’ai trouvé ces réunions particulièrement importantes, car elles permettent de créer

une véritable implication dans la société, et permettent également de découvrir les

autres domaines métiers de la société.

• Les réunions noyau

Ces réunions menées par Sébastien BEOLET, responsable du noyau applicatif Loxane,

permettaient de faire un point sur l’avancement dans le travail de chacun, et d’établir

un planning des tâches à effectuer.

Ces réunions étaient réellement utiles pour permettre d’avoir un aperçu du travail

de chacun, et de voir comment ces tâches devenaient finalement “un tout” sous la

houlette de Sébastien BEOLET.

• Les réunions de bilans

Des réunions étaient régulièrement organisées avec Sébastien BEOLET pour per-

mettre de faire un point sur l’avancement de mon projet et fixer de nouveaux objectifs

à court et moyen terme.

Ces réunions étaient primordiales pour la bonne conduite de mon projet : en effet,

elles me permettaient de reprendre du recul sur ce que j’avais déjà effectué, pour

prendre de bonnes décisions sur la suite du projet.

53

12 Conclusion

Cette expérience a été pour moi l’occasion d’acquérir de nouvelles compétences aussi

bien au niveau technique qu’au niveau des domaines de la cartographie numérique, la

géolocalisation ou le géomarketing, domaines prépondérant aujourd’hui, et présent dans

un grand nombre de secteurs, notamment l’aménagement du territoire, l’aéronautique, les

commerces de proximité...

J’ai pu également voir le fonctionnement d’une équipe au sein d’une entreprise, et com-

ment interagir efficacement avec elle, aussi bien au niveau technique qu’humain.

Plus généralement, j’ai pu voir le fonctionnement global du travail en entreprise et com-

ment chacun des employé constitue un rouage majeur à l’achevement des projets de cette

entreprise.

Pour atteindre ce but, j’ai également constaté que le partage des connaissances était

primordial, non seulement au sein des équipes, mais également entre toutes les équipes,

et les différents départements de l’entreprise.

Enfin, à travers l’achevement de mon projet et les rencontres humaines que j’ai effec-

tuées au long de celui-ci, j’ai enfin pu mettre en perspective tout ce que j’ai appris au long

de mes études pour définir mon avenir professionnel en tant qu’ingénieur en informatique,

et dégager les grandes qualités que ce titre nécessite, à savoir l’adaptivité, l’écoute, et la

coopération. Car ce n’est qu’en utilisant ces qualité que l’on peut progresser, et travailler

efficacement, pour devenir un bon ingénieur.

54

A Glossaire

AG Equivalent d’une société par action en allemand.

Cartographie La cartographie désigne la réalisation et l’étude de cartes. Elle mobilise

un ensemble de techniques servant à la production de cartes. La cartographie constitue

un des moyens privilégiés pour l’analyse et la communication en géographie. Elle sert à

mieux comprendre l’espace, les territoires et les paysages.

Géomarketing Le Géomarketing appartient à une discipline qui se développe autour des

SIG (Systèmes d’Information Géographique) : l’aide à la décision géoanalytique ou géoa-

nalyse. Le Géomarketing est lié au marketing et consiste à analyser le comportement des

individus économiques en tenant compte des notions d’espace.

Géo Management Le Géo Management appartient aussi à une discipline qui se déve-

loppe autour des SIG : il s’agit du management appliqué au monde géographique. Le ma-

nagement consiste à mettre en oeuvre tous les moyens humains et matériels d’un orga-

nisme ou d’une entreprise pour atteindre les objectifs préalablement fixés.

Index Identifiant unique, permettant de retrouver facilement les éléments correspondant

à cet indice.

Librairie Des librairies (ou des API) sont des regroupements de fonctions permettant

d’effectuer une multitude d’actions autour d’objets spécifiques.

Par exemple, les librairies permettant de manipuler les objets Landcovers chez PTV

Loxane donnent accès à des fonctions permettant de créer, supprimer, éditer etc. chacun

de ces objets.

SIG Système d’Information Géographique. Il s’agit d’un outil permettant d’organiser et de

présenter des données alphanumériques spatialement référencées, ainsi que de produire

des plans et cartes.

WKT Le WKT (Well-Known Text) est un langage de balisage destiné à représenter des

objets géométriques sur une carte.

55

B Annexes

B.1 WKT : Well-Known Text

Le WKT (Well-Known Text) est un langage de balisage destiné à représenter des objets

géométriques sur une carte. Ce format a pour principal intérêt de pouvoir être lu directe-

ment par les humains, sans aucune interprétation à travers un logiciel.

Voici la grammaire du WKT :

�<Geometry Tagged Text > :=

| <Po in t Tagged Text >

| < L ineS t r i ng Tagged Text >

| <Polygon Tagged Text >

| < M u l t i P o i n t Tagged Text >

| < M u l t i L i n e S t r i n g Tagged Text >

| <Mul t iPo lygon Tagged Text >

<Poin t Tagged Text > := POINT <Poin t Text >

< L ineS t r i ng Tagged Text > := LINESTRING < L ineS t r i ng Text >

<Polygon Tagged Text > := POLYGON <Polygon Text >

< M u l t i P o i n t Tagged Text > := MULTIPOINT < M u l t i p o i n t Text >

< M u l t i L i n e S t r i n g Tagged Text > :=

MULTILINESTRING < M u l t i L i n e S t r i n g Text >

<Mul t iPo lygon Tagged Text > := MULTIPOLYGON <Mul t iPo lygon Text >

<Poin t Text > := EMPTY

| <Point >

| Z <PointZ >

| M <PointM>

| ZM <PointZM>

56

<Point > := <x> <y>

<x> := double p r e c i s i o n l i t e r a l

<y> := double p r e c i s i o n l i t e r a l

<PointZ > := <x> <y> <z>



<z> := double p r e c i s i o n l i t e r a l

<PointM> := <x> <y> <m>



<m> := double p r e c i s i o n l i t e r a l

<PointZM> := <x> <y> <z> <m>



<z> := double p r e c i s i o n l i t e r a l

<m> := double p r e c i s i o n l i t e r a l

< L ineS t r i ng Text > := EMPTY

| ( <Po in t Text > { , <Po in t Text > }∗ )

| Z ( <PointZ Text > { , <PointZ Text > }∗ )

| M ( <PointM Text > { , <PointM Text > }∗ )

| ZM ( <PointZM Text > { , <PointZM Text > }∗ )

<Polygon Text > := EMPTY

| ( < L ineS t r i ng Text > { , < L ineS t r i ng Text > } ∗ )

< M u l t i p o i n t Text > := EMPTY

| ( <Po in t Text > { , <Po in t Text > }∗ )

< M u l t i L i n e S t r i n g Text > := EMPTY

| ( < L ineS t r i ng Text > { , < L ineS t r i ng Text >}∗ )

57

<Mul t iPo lygon Text > := EMPTY

| ( < Polygon Text > { , < Polygon Text > }∗ )� �

Voici quelques exemples d’objets géométriques définis à l’aide du langage WKT :

• Définition d’un point de coordonnées (10,30) :

POINT(10 30)

• Définition d’un linéaire comprenant quatre points de coordonnées (10,20), (10,30),

(20,40) et (10,40) :

LINESTRING(10 20,10 30,20 40,10 40)

• Définition d’un polygone contenant deux anneaux, un extérieur, un intérieur :

POLYGON((1 1,5 1,5 5,1 5,1 1),(2 2, 3 2, 3 3, 2 3,2 2))

58

B.2 Systèmes géographiques

Un système géographique (ou géodésique) est un système de référence permettant

d’exprimer les positions au voisinage de la Terre.

Historiquement, les systèmes géodésiques étaient déterminés à partir de mesures an-

gulaires et de quelques mesures de longueur. Un système géodésique était associé à un

réseau géodésique, ensemble de points dont les coordonnées avaient été déterminées à

partir des mêmes mesures de base.

Les techniques spatiales ont permis de définir des systèmes géodésiques "mondiaux"

ou "globaux", en combinant les méthodes d’orbitographie précise de satellites, et des me-

sures d’angles ou de distances (ou plutôt, de temps de propagation de signaux) entre ces

satellites et des points du globe ; le "réseau" géodésique est désormais virtuel, et ce sont

les éléments orbitaux des satellites et les positions des stations de trajectographie qui dé-

finissent désormais le système géodésique.

Voici quelques systèmes géodésiques les plus connus :

WGS84 Le WGS84 est le système géodésique associé au système GPS ; il s’est rapi-

dement imposé comme la référence universelle pour la cartographie. Il a été mis au point

par le département de la défense (DoD) des Etats-Unis, et a été conçu par observations

Doppler de points depuis des satellites. Il a une exactitude de l’ordre du mètre.

Le code utilisé chez PTV Loxane pour définir ce système est CS_WGS84

RGF93 Le Réseau Géodésique Français 1993 (RGF93) est le successeur de la NTF. Il

est désormais le système géodésique officiel en France et ce, depuis le 1er janvier 2001

pour tous les travaux de nature publique de plus de 1 hectare, ou dont la plus grande

longueur est supérieure à 500 m. Il atteint une précision de 2 à 3cm sur toute région de

France, où il est équivalent au système WGS84.

Le code utilisé chez PTV Loxane pour définir ce système est CS_RGF93

Loxane Simple Utilisé uniquement chez PTV Loxane. Etablit un repère propriétaire, per-

mettant de protéger les données géographiques sensibles qui n’ont pas été acquises par

les différents clients de PTV Loxane.

Le code utilisé chez PTV Loxane pour définir ce système est CS_LXN_PROJSIMPLE_NH

De nombreux autres systèmes sont utilisés à travers le monde, couplés à différents

systèmes de projection (Mercator, UTM...), dont un bon nombre sont pris en charges par

59

les produits PTV Loxane.

60

B.3 BNF du parser original

Voici la BNF originale du parser OGR/Mitab :

�SELECT < f i e l d − l i s t > FROM <tab le_def >

[ LEFT JOIN <tab le_def >

ON [ < tab le_ re f >. ] < key_ f i e ld > = [ < tab le_ re f > . ] . < key_ f i e ld >]∗

[WHERE <where−expr >]

[ORDER BY < s o r t s p e c i f i c a t i o n l i s t > ]

< f i e l d − l i s t > : : = DISTINCT < f i e l d _ r e f > | < f i e l d −spec>

| < f i e l d −spec> , < f i e l d − l i s t >

< f i e l d −spec> : : = < f i e l d _ r e f >

| < f i e l d _ f u n c > ( [ DISTINCT ] < f i e l d −func > )

| Count ( ∗ )

< f i e l d −func > : : = AVG | MAX | MIN | SUM | COUNT

< f i e l d _ r e f > : : = [ < tab le_ re f > . ] f ie ld_name

< s o r t s p e c i f i c a t i o n l i s t > : : =

< s o r t s p e c i f i c a t i o n > [ { <comma> < s o r t s p e c i f i c a t i o n > } . . . ]

< s o r t s p e c i f i c a t i o n > : : = < s o r t key> [ <order ing s p e c i f i c a t i o n > ]

< s o r t key> : : = < f i e l d _ r e f >

<order ing s p e c i f i c a t i o n > : : = ASC | DESC

<tab le_def > :== table_name

| ’ data_source ’ . table_name

| table_name t a b l e _ a l i a s

| ’ data_source ’ . table_name t a b l e _ a l i a s

< tab le_ re f > : : = table_name | t a b l e _ a l i a s� �61

B.4 Diagramme de Gantt complet

FIG. 28 – Diagramme de Gantt : première partie

62

FIG. 29 – Diagramme de Gantt : deuxième partie

63

B.5 Diagramme de PERT

Du fait de sa taille, le diagramme de PERT ne sera probablement pas lisible au format

papier, cependant le format numérique permettant un zoom appréciable, je vous recom-

mande la lecture de ce document au format PDF.

FIG. 30 – Diagramme de PERT

64

cqcb.mm.free.fr › cv › barouh-rapport-ptvloxane.pdf Moteur de requêtes pour données GSFMoteur...

Documents

Transcript of cqcb.mm.free.fr › cv › barouh-rapport-ptvloxane.pdf Moteur de requêtes pour données GSFMoteur...