En français, je propose d’ajouter un point de géolocalisation sur la majorité des objets dolibarr. Ainsi au lieu d’une adresse postale un tiers pourrait aussi avoir un point GPS.
Petite liste des principaux objets dolibarr qui me semblent concernés par cette idée (ajoutez sur la liste ceux que j’oublie):
Tiers
Contacts (et adresses donc)
Entrepôts
Ressources
Et pour l’instant nous utilisons un « contact livraison » en guise d’adresse mais je propose d’ajouter un point GPS (facultatif) sur les objets suivants:
Bon de livraison
Fiches d’interventions
Projets
Contrat
Évènements
Pourquoi ? hé bien tout simplement parce-que nous pouvons imaginer une intervention réalisée à l’adresse du contact lié à cette intervention le 10 janvier 2022. Quelques mois plus tard ce contact change d’adresse (voir même la société déménage), mais pour autant l’intervention elle a eu lieu à « l’ancienne adresse du contact » et donc pouvoir associer un point gps à l’intervention fait qu’elle reste consistante. Idem pour les autres.
Alors que pensez-vous de tout ça ?
En effet de bord le fait de stocker des points GPS permet:
d’avoir des localisations qui n’ont pas d’adresses postales (monde rural, pays où le cadastre est moins précis qu’en France par exemple etc.)
de faire des calculs de proximité / routage etc. (je vous laisse faire des recherches sur le web)
Mais je serais d’avis de créer un nouvel objet « Geo » et de relier cet objet à ce que l’on souhaite (Tiers, contacts etc), fonctionnement similaire aux contacts qu’on peut relier aux tiers, factures etc.
Cela ouvrirait également la voie à une future possibilité de tracking des produits, par exemple suivi transport, ou géolocalisation de la bétonnière sur un chantier, les possibilités sont nombreuses (j’ai connaissance d’un cabinet d’avocat qui fait du tracking des dossiers, ce qui permet de savoir dans quel bureau et bâtiment il se trouve).
L’objet Geo serait basé sur les spec GeoJSON de la RFC 7946
Je n’ai pas précisé les aspects techniques sur ce fil pour rester dans la zone « user », vous pouvez cliquer sur le lien pour aller sur le ticket github sur lequel je détaille la technique. Pour les aspects techniques, implémentation, base de données, datamodel etc. je propose de rester sur github, et que ce fil du forum reste plus sur les usages, et les besoins…
Bonjour @erics
C’est une bonne idée.
À une époque, @eldy (je crois) avait fait un module qui permettait de localiser les tiers avec gmap; de mon côté,j’avais repris le principe pour un client en adaptant à openstreetmap; je peux te le partager si tu veux, à moins qu’@eldy ait une meilleure idée.
J’aime bien l’idée de pouvoir conserver une trace de l’adresse au moment T. Serait-il possible d’ajouter la souscription des membres dans la liste des objets qui conserve la trace ? Parfois, c’est important pour des questions d’assurance.
Pour commencer, il faut le concevoir pour permettre de choisir plusieurs services de géocodage (google, pelias, nominatim, etc…)
Ensuite, il faudrait avoir l’adresse sur plusieurs champs, avec le champ principale pour l’adresse postale et le/les autres pour les compléments d’adresse inutile au géocodage (PR refusé).
Ce sujet, je l’avais déjà traité il y a un moment (10 ans) et j’ai un module pour ça que je partagerais, mais le code est un peu vieux.
Si j’ai bien compris l’idée de @erics il s’agit d’ajouter une information de géolocalisation aux différents objets (tiers, contacts etc) c’est à dire enregister latitude et longitude d’une manière ou d’une autre.
Le service de géocodage c’est quelque chose de distinct qui peut permettre de renseigner ces données.
En fait le stockage de l’information de géolocalisation ça pourrait faire partie du core de Dolibarr, et l’ajout des services qui permettent de renseigner ces données pourrait être faite par des modules externes.
Pour info, sur le module google, les infos ajoutés sont juste
geo_latitude
geo_longitude
qui sont 2 infos qui seront communes quelques soit le service utilisé pour enregistré la géolocalisation
il y a en plus:
geo_result_code Un code resultat de geolocation. pour stocker le taux de fiabilité par exemple ou raison d’erreur pour ne pas avoir su géoencoder.
geo_degraded Qui vaut 1 quand la géolocation a été faite mais n’est pas fiable (par exemple car elle a du etre faite sur la base de la ville uniquement, et non sur une adresse exacte)
Ces champs seront surement commun à tous les objects. Donc au niveau PHP, il faudra les déclarer via un « Trait » PHP « CommonGeoloc » comme on a fait avec le trait « CommonSocialNetworks » et « CommonPeople »
@eldy j’ai indiqué sur le ticket github qu’il y a en SQL le modèle POINT qui permet de stocker un point géographique et MySQL/MariaDB/PostgreSQL seems to have a POINT datatype for that:
donc la ça serait de rajouter un POINT sur les différents objets plutôt que geo_lat et geo_lon … et oui avec plaisir pour que ça remonte dans le Trait, si vous êtes ok je pense m’y pencher d’ici 2/3 semaines vu mon emploi du temps …
Bonjour
Bonne idée, dans notre cas voila ce que j’ai fait via un ptit module perso.
Nous gérons un parc machine, le client peut déplacer sa machine à sa guise (sur un site qui n’a rien a voir avec son adresse de livraison), ce qui ne facilite pas la vie des tech etc.
Du coup pour chacune de nos machine nous avons les coordonnées dans dolibarr
Mais ce qui serait bien, Laurent, c’est de ne pas faire ce que vous proposez MAIS de lire et tenir compte des informations contenues dans les messages (y compris le mien) … stocker lat et long dans deux champs de la bdd est sous optimal d’après moi
J’en ai parlé au dernier devcamp mais sans doute quand vous n’étiez pas la, les BDD proposent depuis une dizaine d’année pour mysql et bien plus pour pgsql des outils de issus du monde des SIG qu’il serait vraiment dommage de ne pas utiliser
+1 pour le stockage dans une colonne de type POINT, ce qui permet de faire des calculs dessus, au pire avoir les deux colonne lat,lon et une 3eme de type POINT
Merci, mais pas de lon/lat en plus du point ça obligerait de faire des doubles updates avec les risques liés.
La seule grosse vérif à faire avant de se décider sur ce point - c’est ce que je pensais faire après le devcamp vu qu’on en avait parlé - était de re-vérifier quelles versions de mysql/mariadb/pgsql sont nativement capables de stocker un POINT … car ça changera de fait le prérequis minimal pour dolibarr.
Ne pas oublier d’ajouter dans quel système géodésique on se trouve … avoir des coordonnées c’est bien beau mais si on ne sait pas si c’est du WGS84 ou du ED50 ou autre ça ne sert à rien de stocker des données…
Autre raison du « stand-by » de mon côté sur ce sujet j’avais aussi noté de faire une petite analyse / étude préalable pour savoir si ça ne serait pas futé de stocker une collection de points et/ou autre « chose ».
Par exemple pour une adresse d’un contact lié à un tiers on peut-être globalement d’accord pour stocker un point « gps ». Mais pour une ressource, un historique de points serait pas mal. Pour un entrepôt un point « central » pourquoi pas mais peut-être qu’il serait intéressant de stocker la zone couverte au sol et donc pas un POINT mais un peu plus
Voir: (mais il faudrait remonter dans les versions pour voir quel sera le prérequis minimal)
Réponse d’un architecte bdd: la seule chose qui serait éventuellement acceptable serait un trigger sur le moteur de la bdd mais ne jamais dépendre de la couche applicative pour assurer la congruence des données et dans tous les cas stocker la même information sous deux formes différentes est un aveux de bad-design
→ par exemple un utilisateur qui via phpmyadmin change lon/lat et ne « voit pas » le champs point à côté…
Tu veux dire que tu trouves que ceci est mieux en terme de stockage
CREATE TABLE Locations (
location_id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(255),
gps_coordinates POINT NOT NULL,
SPATIAL INDEX(gps_coordinates)
);
Ouép
reste à savoir si on imagine avoir dans la BDD des points géolocalisés selon différents référentiels par exemple WGS84 ou PZ-90 ou GTRF07-08-09-10 ou …
Si on replace dolibarr 20 ans plus tard ça semble pas déconnant d’avoir cette information dans la BD pour pouvoir un jour « migrer » les données d’un référentiels géodésique à un autre (pas certain que WGS84 soit toujours « up » dans X années).
Voir cet article de l’ESA qui devrait faire plaisir aux amoureux des calculs mathématiques avec des formules sympa
Donc bien que ça soit plus lourd j’ajouterais bien un champ pour dire dans quel référentiel est valide le POINT en question … reste à savoir si ce référentiel est une clé étrangère vers une autre table qui serait la liste des référentiels, ou un enum, ou un varchar (« à l’ancienne ») …
