Le gaspillage alimentaire

Formule de Haversine

En ce qui concerne le calcul de distances entre deux points géographiques, il a été nécessaire de passer du temps dessus pour identifier la méthode qui serait la plus adéquate à l’application. Il s’agissait de traiter le plus de points possibles dans le laps de temps le plus court sur toutes les entrées de la base de données. Dans un premier temps lorsqu’il s’agit de calculer la distance entre deux points, la première idée à venir à l’esprit est le théorème de Pythagore mais il s’agit là d’une erreur car le théorème ne s’applique qu’aux surfaces en deux dimensions alors que les coordonnées géographiques en latitude et longitude sont des points de repères sur une sphère (PolyGeo 2016) .

Par exemple si nous prenons pour emplacements sur la Terre, Tokyo et Genève avec le théorème de Pythagore, nous aurions une distance en ligne droite qui passerais au travers de la planète. La distance idéale serait celle qui suit la courbe terrestre comme celle empruntée par les avions. (Murray Bourne 2018) Pour cela il faut utiliser la formule de Haversine qui utilise la latitude et la longitude pour représenter les coordonnées géographiques afin de calculer la distance entre deux emplacements. Pour comprendre comment cette formule fonctionne il faut tout d’abord comprendre le concept de latitude et de longitude. La Terre sera représentée en tant que sphère avec le nord au sommet ainsi que l’équateur à l’angle de 0°N. La latitude est indiquée en degrés et représente un point situé au nord ou au sud de la référence qu’est l’équateur. Les angles vont de -90° (correspondant à 90°S) en passant par l’équateur qui se situe à l’angle 0° et allant jusqu’à 90° (correspondant à 90°N) qui se situe lui dans la partie supérieure du globe. Lorsque tous les points d’une même latitude sont reliés entre eux, cela forme un cercle parallèle à celui de l’équateur.

A noter que 1° de latitude correspond à peu près à 69 miles nautique ce qui équivaut à approximativement 111 kilomètres (longitudestore 2018). Elle peut varier très légèrement en se rapprochant des pôles car la Terre n’est pas parfaitement sphérique mais reste suffisamment précise dans le cadre de l’application. (@natgeofrance 2018) La longitude contrairement à la latitude ne se base pas sur le rapport aux pôles et à l’équateur mais sur le Méridien de Greenwich situé en Angleterre. Elle est cependant aussi mesurée en degrés mais par rapport au Premier Méridien allant de -180° (-180W) en passant par le méridien jusqu’à 180°(180°E). (Murray Bourne 2018) La distance pour 1° de longitude n’est pas fixe, elle dépend fortement de la latitude. Plus les points se trouvent proche d’un pôle plus petit sera la distance entre ces deux sur la même latitude. Pour cela pour 1° il faut calculer : cos(latitude) * 69 pour obtenir le résultat en miles ou bien cos(latitude) * 111 pour la distance en kilomètres. (Alexander Rubin 2018) Une fois ces deux notions comprises il est possible de passer à la suite et effectuer le calcul de distance entre deux points en utilisant la formule de Haversine. Pour deux points sur une sphère :

Structure Ionic

Dans le projet créé sur Ionic, les dossiers contenant les parties les plus importants du front end permettant l’affichage des informations sont au nombre de trois. On y trouve les trois dossiers suivants : app, pages et components. Le dossier app est le premier auquel l’application accède lors de son lancement. Il contient tous les fichiers nécessaires à l’amorçage ainsi que la structure principale de l’application. (Ionic Framework 2017) Le fichier app.component.ts définit la structure principale du projet et ainsi que la redirection sur la page principale de l’application. Lorsque la plateforme ainsi que les plugins sont prêts (Cordova et d’autres plugins natifs), l’application est notifiée et l’utilisation de ces derniers en est possible. Ceci permettant donc l’utilisation de fonctionnalités supplémentaires nécessaires au projet. (Ionic Framework 2017) Le fichier app.html, quant à lui, définit la navigation ainsi que la racine du projet. Il peut aussi afficher du texte, un logo ou toutes autres informations de type HTML contenu dans le fichier lors du chargement des ressources et composants de l’application.

Dans le cas de ce projet, il affiche uniquement le logo ainsi qu’une animation de chargement. (Ionic Framework 2017) Le fichier app.module.ts sert de point d’entrée et permet l’importation du module de Angular2 NgModule. Ce dernier est basé sur TypeScript, langage avec lequel tous les fichiers ayant pour extension .ts sont codés. C’est aussi dans ce fichier que sont faites toutes les déclarations de pages (sauf dans le cas du lazy loading, section 6.1.3 ) components et providers. Cela permet d’assembler les pages du projet, afin qu’elles soient accessibles et liées entre elles. (Ionic Framework 2017) La feuille de style permet de styliser les éléments HTML. App.scss permet dans le cas de ce projet de gérer les propriétés du logo ainsi que l’animation des éléments de chargement. Il est possible de modifier le thème global de l’application en ajoutant des règles spécifiques dans le fichier /src/theme/variables.scss mais ne se fait en aucun cas ici. (Ionic Framework 2017) Le fichier main.ts du répertoire app est un fichier auto-généré par Ionic qui s’occupe simplement de l’amorçage de l’application.(Ionic Framework 2017)

Conclusion

Développer une application avec quelques fonctionnalités peut paraître comme quelque chose de facile, mais c’est surtout lorsque l’on doit assembler le tout et les faire fonctionner ensemble que les choses se compliquent. Il faut avant de se lancer tête baissée à coder notre application, savoir quels sont les différents outils mis à notre disposition et qu’est-ce qu’elles offrent de plus par rapport à un autre, et surtout lesquels nous conviennent le mieux. Une fois les outils en main il faut apprendre à les utiliser et connaître leurs capacités ainsi que leurs limites, essayer de voir ce qui fonctionne et ce qui ne fonctionne pas, mais surtout de comprendre pourquoi. Il faut ensuite commencer à établir les différentes fonctionnalités de notre application et les réaliser. Après l’implémentation des fonctionnalités principales, il faut encore être capable de les relier entre elles pour faire fonctionner le tout ensemble. C’est lorsqu’on met en place tous ces éléments, qu’on réalise qu’il ne suffit pas d’être en possession des pièces du puzzle, mais faut-il encore savoir les assembler. C’est alors qu’une fois les pièces ensemble que l’on peut admirer fièrement son travail. Je ne cesse de penser déjà aux futures modifications que je pourrais apporter à cette application. Enfin, j’espère que ce projet pourra continuer à être développé et être utilisée au sein d’une association qui développe le commerce de proximité et par la suite, si le succès escompté est au rendez-vous la développer ailleurs en Suisse, voire dans le monde.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Mobile based discount tracker app for waste limitation alternative
Déclaration
Remerciements
Résumé
Table des matières
Liste des tableaux
Liste des figures
1. Introduction
2. Le gaspillage alimentaire
2.1 Régions
2.1.1 Monde
2.1.2 Suisse
2.1.3 Genève
2.2 Concurrents
2.3 Différentes alternatives
2.4 Accueil de l’application
2.4.1 Résumé des interviews
3. Analyse des technologies
3.1 Framework de développement applicatif
3.1.1 Framework hybride
3.1.2 Ionic 3
3.1.3 React Native
3.1.4 Comparaison
3.1.5 Choix du Framework
3.2 Web Service
3.2.1 Laravel
3.2.2 API Rest
4. Fonctionnalités de haut niveau
4.1 Autocomplétion
4.2 Géolocalisation
4.2.1 Geocoder
4.2.2 Geolocation
4.2.3 Formule de Haversine
4.3 Google Maps
5. Modélisation des données
5.1 Modèle UML
5.2 Différentes tables
5.2.1 Store
5.2.2 Address
5.2.3 Coordinates
5.2.4 Owner
5.2.5 Credential
5.2.6 Article
5.2.7 Category
5.2.8 Measure_Unit
6. Architecture de l’application
6.1 Front end
6.1.1 Structure Ionic
6.1.2 Pages
6.1.3 Lazy Loading
6.1.4 Components
6.1.5 Assets
6.1.6 Ressources
6.1.7 Index.html
6.1.8 Config.xml
6.2 Backend
6.2.1 Interfaces
6.2.2 Providers
6.2.3 Stockage de données local
6.2.4 Stockage de données distant
7. Interfaces de l’application
7.1 Hiérarchie des pages
7.2 Pages
7.2.1 Accueil
8. Problèmes rencontrés
9. Perspectives d’avenir
9.1 Améliorations envisageables
9.1.1 De Haversine à GeoHash
9.1.2 Maps
9.2 Fonctionnalités supplémentaires
9.2.1 Application vendeur
9.2.2 Réservation d’un produit
Conclusion
Bibliographie
Annexe 1 : Quel avenir pour l’agriculture contractuelle de proximité à Genève ?