FablabSU

Nous retranscrivons ici quelques réflexions autour de la carto et de l'architecture de l'application

Les données cartographiques utilisées sont les données OpenStreetMap (http://www.openstreetmap.org, http://www.openstreetmap.fr). Ce choix nous a semblé évident car nous sommes dans la même logique collaborative et opendata. Nous utilisons la librairie leaflet (http://leafletjs.com/) pour l'affichage de la carte proprement dit, et la représentation des mesures. Depuis une mesure, nous pourrons indiquer un lien pour accéder à des pages de commentaires sur le site collaboratif. Nous aurions pu utiliser OpenLayers mais l'utilisation de leaflet semble plus simple et convenir parfaitement à ce que nous voulons faire. Les tiles (tuiles ou fonds de cartes qui sont téléchargées lors du zoom / scroll) sont téléchargées par leaflet sur les serveurs d'OpenStreetMap

L.tileLayer('http://{s}.tile.osm.org/{z}/{x}/{y}.png', {
    attribution: '&copy; <a href="http://osm.org/copyright">OpenStreetMap</a> contributors'
}).addTo(map);

Nous ne sommes pas censés utiliser ces serveurs dans une logique de production. Il nous faudra réfléchir à quel fournisseur de cartes nous souhaitons : nous pouvons utiliser d'autres serveurs gratuits (MapQuest, …) ou payants, ou alors implémenter notre propre serveur (cf http://switch2osm.org/using-tiles/). Pour ne pas refaire ce qui existe par ailleurs, et pour soulager nos serveurs, nous privilégierons certainement l'utilisation de serveurs externes. On restera ainsi autant que possible dans une logique collaborative.

Dans un premier temps, nous envisagions d'afficher une carte en plein écran sur notre site, avec une sélection ds données affichées et des bornes de la cartes en fonction de l'URL. Cette page avec une carte pleine écran aurait pu facilement être intégrée au sein de l'appli smartphone.

https://open_geiger-c9-chsimon.c9.io/openradiation_embedded/<latMin>/<lonMin>/<latMax>/<lonMax>/<timeMin>/<timeMax>

Cependant, ce fonctionnement nécessiterait pour l'application le téléchargement supplémentaire de code (code html et librairies js dont leaflet) qui n'est pas nécessaire si nous embarquons directement la carte dans l'appli. De plus, le choix de cordova pour le développement smartphone nous permet de le faire sans réécriture de code. Nous n'abandonnons pas cependant l'idée de la carte plein écran au niveau du site, car nous pourrons la proposer en temps que widget pour des concepteurs de sites web qui pourront ainsi facilement embarquer une carte openradiation dans leur site sans développement particulier.

• * Mesures affichées sur la carte : pistes de réflexion **

Pour l'instant, via l'API, nous récupérons toutes les mesures demandées. Nous avons seulement mis une limite de 1000 au niveau des requêtes en base pour ne pas surcharger la base. Nous prévoyons de pouvoir filtrer ces mesures en javascript plutôt au niveau du client (restriction de la plage de temps, filtre sur certaines métadonnées, …).

Cependant, il nous faudra réfléchir à la façon dont on récupère les mesures :

• Outre la limite max, nous envisageons d'améliorer l'API en proposant au client d'indiquer lui-même une limite : ainsi il pourra ne récupérer par exemple que les 10 dernières valeurs s'il le souhaite

• Au niveau du site, nous aurons une page “par défaut”, par exemple l'affichage de la carte de France avec les 500 mesures les plus récentes. Le fait de n'afficher que les données les plus récentes, en un nombre restreint, permet aussi de rendre la carte plus dynamique, et pour les participants au projet de voir rapidement les nouvelles données, et de pouvoir éventuellement les qualifier. Les données de cette page par défaut, très accédées, pourraient éventuellement être mises en cache au niveau du serveur pour soulager la base. Ceci sera à voir après un certain temps de fonctionnement.

• Au niveau du smartphone, il y aura certainement 2 pages par défaut : l'une avec “mes mesures” qui représente l'intégralité des mesures prises par un individu authentifié, l'autre avec “les mesures autour de moi” sur une zone plus restreinte, à définir.

• L'utilisateur, que ce soit sur le site ou le smartphone, devra accéder à d'autres mesures en dézoomant, en scrollant, en étandant la plage de temps, … : ces évènements vont devoir être interceptés pour pouvoir de nouveau requêter l'API si les mesures n'ont pas déjà été récupérées. Un point intéressant pourrait être de récupérer par défaut un peu plus de mesures que celles qui correspondent aux dimensions de la carte, pour que l'utilisateur puisse scroller légèrement sans lag (c'est comme cela que fonctionne l'affichage des cartes google map ou OpenStreetMap par exemple)

• Il pourrait être intéressant de visualiser des données de “référence”. Teleray propose un service de récupération des mesures des dernières données http://teleray.irsn.fr//TelerayService/service/measure (dernières valeurs ou valeurs moyennées sur plusieurs semaines). Ce service pourrait être appelé très facilement directement au niveau du client, sans avoir à “polluer” notre base avec de nombreuses données externes. Il faut cependant ce poser la question de l'intérêt de cela; des données de référence pourraient ne pas être affichées, mais servir de base pour “qualifier” une mesure de manière automatique.

Nous avons vu que nous nous appuierons sur des serveurs externes pour les cartes. Nous essaierons de le faire lorsque c'est possible pour les librairies (jquery, bootstrap, leaflet) utilisées en s'appuyant sur des CDN, ce qui a le double avantage de soulager nos serveurs et d'améliorer la rapidité au niveau des clients (serveurs plus proches, mises en caches possible, …). De ce fait, le travail de l'API sera relativement limité.

Nous envisageons a priori 3 serveurs chez un hébergeur :

- Un serveur dédié pour la base de données, avec un prix actuel chez ovh de moins de 100€ / mois pour un serveur 64Go RAM, 4 cores, 2*2To, 500Mbps de bande passante. La base consiste essentiellement en une table contenant les mesures : nous envisageons environ 5 millions de lignes créées par an avec une moyenne de 100 octets par mesure (on néglige les photos qui ne concerneront que quelques mesures). Sur 10 ans, en multipliant par 2 la taille de la base pour prendre en compte la structure et les index, on arrive à 10Go de stockage, donc l'intégralité des données devrait tenir en RAM. Si on considère une moyenne en cas de pic de 100 mesures par requête, on est capable d'absorber 6000 requêtes par seconde au niveau d'une bande passante de 500Mbps, ce qui semble largement suffisant

- Une machine pour l'API de remontée des données, avec éventuellement l'API de requêtage et la carte : l'intérêt d'avoir 2 machines serait de garantir la possibilité de remonter des données, même si il y a un pic de consultation. De même on peut envisager une réplication de la base pour la consultation par l'API de requêtage. On envisage également du load balancing sur ce serveur pour pouvoir ajouter facilement de nouvelles machines en cas de pic.

- Une machine pour le site collaboratif.

• Article suivant : bibliothèque Eagle
• Retour à l'accueil
• Retour à la chronologie du projet
• Article précédent : Mise en oeuvre de la batterie LiPo