Discussion :

[bizulk]

Bonjour,

Je voudrais des conseils sur la façon d'architecturer et développer une application WEB de géolocalisation, en particulier l'intégration de technologies dédiées. J'ai parcouru les FAQS, tutos, livres et forum sans avoir vraiment eu de réponse.

Pour mon profil : je suis surtout compétent dans le développement d'applications embarquées temps-réel mais j'ai participé au développement de site WEB embarqués sur des petites cibles afin d'avoir facilement accès la configuration et supervision (SCADA). J'ai des bases sur PHP, Javascript, CSS, et BDD mais je reste ouvert à d'autres technologies, si cela peut m'éviter de réinventer la roue et d'améliorer la pérennité logicielle.

Avec l'évolution du marché des objets connectés on reçoit des Cahiers de charges sur la supervision et la configuration "temps-réel" d'un parc d'objet connectés. Globalement l'application s'architecture comme suivant :

• une BDD
• un serveur pour la messagerie sécurisée avec les appareils et l'alimentation de la base.
• des clients WEB pour : afficher une cartographique des appareils, administrer les appareils, afficher des statisques et des alarmes, ...

Avec le lots de besoins classiques :

• gestion utilisateurs et authentification
• évolutilité des vues et des calculs statistiques
• besoin en performances sur la base car on dénombre les messages échanges par milliers / seconde.
• sécurité des échanges
• adaptation affichage à des formats plus 'mobiles'

Personnellement je pencherai pour des outils SCADA tel que PC-Vue OU Génésis. Ils ont un coût à l'achat compensé par le développement rapide, la maintenance du produit partiellement déporté par le distributeur, et l’évolutivité est assurée à un coût maîtrisé (dans le périmètre de ce qui est permis).
Mais je comprends qu'un client espère réduit ses coûts à terme en demandant le développement d'une application WEB qui intègre des outils gratuits et assurer lui-même la maintenance.

J'ai certaines idées :

• BDD avec PostGreSQL ( à coupler avec PostGis ?)
• Serveur Web Apache.
• Messagerie : un broker AMQP, OU REST bien que j'ai une vague idée de ce que c'est.
• Géolocalisation : intégrer Leafletjs, gpxpy, ou python-geojson
• Adaptation affichage : CSS.
• Gestion utilisateur : en base, alors j'intègre un CMS comme Joomla! ?

Si je me lance maintenant je crains de réinventer la roue, donc je me pose certaines questions sur ces choix. Si vous pouvez m'orienter dessus, ou me conseiller une documentation spécialiser sur la question, je suis preneur

[bretus]

Bonjour,

Je vois que tu as bien commencé à défricher le terrain, je vais essayer de compléter.

En bref, je vois les bons éléments à l'exception d'un point important : Les flux.

Tu as deux natures de flux en webmapping :
* Les flux image (WMS, WMTS, TMS) : obtenir une image correspondant à une emprise géographique/bbox (rendu côté serveur)
* Les flux vecteurs (WFS, GeoRSS ou variante à base de GeoJSON, de GPX, de JSON, etc.) : obtenir les données correspondants à une emprise géographique (rendu côté client)

A mon sens, si tu veux une solution pérenne, il faut surtout que tu mettes en place des flux standards.

BDD avec PostGreSQL ( à coupler avec PostGis ?)

Intérêt : Avoir des indexes spatiaux (récupérer plus vite les points dans une boite), pouvoir te brancher facilement dans les outils existants (pour créer des flux standard à l'aide de GeoServer, te connecter sur ta base avec des clients lourds du type QuantumGIS)

Adaptation affichage : CSS.

L’interactivité se fait surtout en javascript.

Géolocalisation : intégrer Leafletjs, gpxpy, ou python-geojson

Attention : Géolocalisation = à partir d'une adresse, tu trouves une position (longitude, latitude). Tu parles en fait de webmapping.

Gestion utilisateur : en base, alors j'intègre un CMS comme Joomla! ?

Tu peux faire le choix de prendre/faire une extension d'un CMS pour générer ton flux de données.

Je pense que le mieux est de te faire une idée de la chose en générant du GeoJSON et en l'affichant avec Leaflet avant de te prendre la tête avec des questions d'intégration.

Dans un second temps, tu peux faire un assemblage PostGIS/GeoServer/Leaflet.

[bizulk]

Bonjour,

Merci pour cette réponse et d'avoir d'avoir recadré l'activité sur du webmapping, je trouverai probablement plus de ressources pertinentes en utilisant le bon mot.
En fait mon besoin direct était d'avoir les éléments nécessaires pour établir un chiffrage (part développement / intégration, coût licence) pertinent.
Mais bon je vais peut-être passer mon tour cette fois-ci et réaliser de la veille techno en maquettant comme tu le suggères.

Sur la nature du flux je m'orienterai vers des flux "vecteurs", qui sont à mon avis plus appropriés pour un service supportant plusieurs centaines de client connectés.

Sur les statistiques je me posais un peu la même question sur la distribution de la charge client/serveur pour finalement partir sur cette politique :

• intégrer dans la page un module de calcul et de génération de graphes (à chercher) pour tout ce qui est purement "mathématique sur série statistique"
• lancer une tâche cyclique sur le serveur (ou un trigger) pour les autres calculs, genre des procédures pour alimenter une table extensible.

Pour l'adaptation de l'affichage via le javascript, on me dit que c'est surement plus souple que le CSS (dont le nombre sera limité) parce qu'on peut recalculer la position et la taille des contrôles affichés. C'est ce que tu avais en tête ?

Merci

[bretus]

En fait mon besoin direct était d'avoir les éléments nécessaires pour établir un chiffrage (part développement / intégration, coût licence) pertinent.
Mais bon je vais peut-être passer mon tour cette fois-ci et réaliser de la veille techno en maquettant comme tu le suggères.

Tu auras une meilleure idée des développements à réaliser avec des PoC qui te permettront de prendre connaissance de l'existant. Sans ça, tu auras du mal à définir une architecture qui ne te conduira pas à réinventer la roue.

Sur la nature du flux je m'orienterai vers des flux "vecteurs", qui sont à mon avis plus appropriés pour un service supportant plusieurs centaines de client connectés.

Ils sont surtout plus souple pour faire des interactions riches en JavaScript et c'est plus simple de mettre en place des symbolisations. Tu as une limite plus basse sur le nombre d'objet que tu peux afficher sur une carte qu'en raster.

La bonne question, c'est combien d'objets est-ce que tu vas afficher simultanément sur ta carte?

Sur les statistiques je me posais un peu la même question sur la distribution de la charge client/serveur pour finalement partir sur cette politique :

• intégrer dans la page un module de calcul et de génération de graphes (à chercher) pour tout ce qui est purement "mathématique sur série statistique"
• lancer une tâche cyclique sur le serveur (ou un trigger) pour les autres calculs, genre des procédures pour alimenter une table extensible.

Je ferais presque la même remarque : Fais surtout attention à mettre un cadre pour l'accès des données. Là, j'ai l'impression que tu te demandes comment tu vas faire les caches avant de savoir ce que tu vas devoir mettre en cache. Pour ma part, j'ai tendance à m'arranger pour avoir une URI par objet cartographique en plus des flux standard (http://monapp.org/wfs) :

* Le formulaire pour éditer l'objet cartographique ("feature")

http://monapp.org/feature/<id_feature>

Partant de là, je raccroche les "API" nécessaires pour pouvoir accéder aux données depuis JavaScript :

* Récupération des données pour un graphique de température (JSON google chart friendly par exemple)

http://monapp.org/feature/<id_featur...re?format=json

Avec ce cadre sous forme d'APIs REST, on peut mettre des caches quand c'est nécessaire (dès lors qu'on as un nombre limité de valeurs pour les paramètres).

Pour l'adaptation de l'affichage via le javascript, on me dit que c'est surement plus souple que le CSS (dont le nombre sera limité) parce qu'on peut recalculer la position et la taille des contrôles affichés. C'est ce que tu avais en tête ?

Tu vas vite être amené à écouter des clics sur tes objets cartographiques pour afficher des graphiques, des popups, des fiches d'informations, etc. La position des contrôles, les icônes, etc.; c'est un détail à côté de la gestion des événements sur la carte ("quand on clic sur le marqueur, on affiche la popup").

PS : Tu peux t'inspirer des API OpenData pour définir ces API d'accès aux données (il y a peut-être des standards émergents du côté des objets connectés?)
* Opendata IDF
* Data.gouv.fr
* JCDecaux (Vélib)

[bizulk]

Je ferais presque la même remarque : Fais surtout attention à mettre un cadre pour l'accès des données. Là, j'ai l'impression que tu te demandes comment tu vas faire les caches avant de savoir ce que tu vas devoir mettre en cache.

La bonne question, c'est combien d'objets est-ce que tu vas afficher simultanément sur ta carte?

Je me suis posé la questions mais sans y donner suite car en général les cahiers de charges ne le précisent pas. Mais rien ne m'empêche effectivement de reboucler et donner des limites sur ces points.

En général le client évoque une capacité (exemple : 200 variables d'états, la taille du parc avec des centaines d'appareil) sans préciser ce qu'il souhaite réellement voir sur la carte.
Je prends pour acquis (précision CdC) qu'il souhaite afficher la position de tous ses appareils simultanément, avec deux ou trois variables d'états pertinentes (les autres n'étant affichées qu'à la sélection d'un objet).

J'ai voulu identifier la nature des calculs pour anticiper leur prise en charge, mais je pensais qu'avec cette approche je pouvais me dispenser d'imposer un périmètre très précis. Le client n'aime pas trop s'engager dessus (==avenant) et si on prend du temps à l'étudier on risque de le faire à perte (perte du CdC).

Quelqu'un d'expérimenté saura peut-être d'emblée préciser des limites raisonnables sur l'affichage et les statistiques. Avec le maquettage j'aurai une réponse.

Mais avec tes réponses je vois déjà plusieurs axes de recherches.
Je vais laisser le sujet encore tout frais ouvert qques temps (retour d'expérience) avant de le marquer résolu.

[bretus]

En général le client évoque une capacité (exemple : 200 variables d'états, la taille du parc avec des centaines d'appareil) sans préciser ce qu'il souhaite réellement voir sur la carte.
Je prends pour acquis (précision CdC) qu'il souhaite afficher la position de tous ses appareils simultanément, avec deux ou trois variables d'états pertinentes (les autres n'étant affichées qu'à la sélection d'un objet).

Ça devrait être gérable. Cette carte qui affiche des adresses OSM le prouve.