Tous les photophones enregistrent les coordonnées des photos.
Il reste Í localiser les photos sur une carte.
Jusqu'Í présent, Picasa 3 / Windows le faisait remarquablement, combiné
Í Google Maps, sans aucune manipulation :
https://www.cjoint.com/doc/22_05/LExpEhgfiI0_IMG-20191023-083005782-Recadr%C3%A9e-Localis%C3%A9e.jpg
(C'est moi dans le désert du Wadi Rum en Jordanie, je suis Í droite, le
cheval est Í gauche).
Mais malheureusement, c'est fini car le navigateur Internet Explorer
inclus (en dur ?) dans Picasa 3 n'est pas conforme avec l'API JavaScript
Google Maps :
https://developers.google.com/maps/documentation/javascript/error-messages#unsupported-browsers
Solution ? Linux bien sͻr !
J'explore Linux Mint Cinnamon et je constate que Xviewer exploite les
coordonnées des photos et moyennant des manips plus ou moins évidentes
(détails sur demande), affiche la localisation des photos sur une carte :
https://www.cjoint.com/doc/22_05/LExpSy6YN30_IMG-20191023-083005782-Recadr%C3%A9e-Localis%C3%A9e.png
Ben, c'est pas pour dire mais c'est pas aussi bien.
D'abord, Xviewer affiche une planisphère riquiqui qu'il faut agrandir.
Ensuite, la carte affichée ici est exclusivement en arabe et en hébreu.
Il faut donc apprendre les langues non européennes si on se balade au loin.
Enfin et surtout, la carte affiche une multitude de flèches de
localisation, dont l'une seulement est celle de la photo, mais rien ne
la distingue des autres qui proviennent des autres photos du dossier.
C'est embêtant.
Quelqu'un a-t-il résolu ce problème de localisation, avec un autre
logiciel Linux éventuellement ?
--
Ils y reviendront, au cheval, ils y reviendront, et au galop !
Sergio , dans le message <629a36a6$0$18381$, a écrit :
J'avais trouvé une bidouille "systemd" pour afficher mon htop, mal heureusement Í la version suivante ça me marchait plus... Peux-tu expliquer pourquoi la montée en version a fait foirer ma bidouille alors que celle de systemV a tenu le choc ?
Parce que tu as choisi de faire une *bidouille* basée sur ton expérience de SysV plutÍ´t que de lire la doc et d'écrire une vraie solution.
Sergio , dans le message <629a36a6$0$18381$426a74cc@news.free.fr>, a
écrit :
J'avais trouvé une bidouille "systemd" pour afficher mon htop, mal
heureusement Í la version suivante ça me marchait plus...
Peux-tu expliquer pourquoi la montée en version a fait foirer ma bidouille
alors que celle de systemV a tenu le choc ?
Parce que tu as choisi de faire une *bidouille* basée sur ton expérience de
SysV plutÍ´t que de lire la doc et d'écrire une vraie solution.
Sergio , dans le message <629a36a6$0$18381$, a écrit :
J'avais trouvé une bidouille "systemd" pour afficher mon htop, mal heureusement Í la version suivante ça me marchait plus... Peux-tu expliquer pourquoi la montée en version a fait foirer ma bidouille alors que celle de systemV a tenu le choc ?
Parce que tu as choisi de faire une *bidouille* basée sur ton expérience de SysV plutÍ´t que de lire la doc et d'écrire une vraie solution.
Nicolas George
Stéphane CARPENTIER , dans le message <629a2c24$0$18400$, a écrit :
Avec SysV, c'était la galère Í chaque montée de version. La distribution déployait la nouvelle version du fichier de conf avec les nouvelles options et il fallait que je retrouve mes personnalisations pour merger mon fichier personnalisé avec le nouveau fichier de ma distribution.
Tout Í fait. En plus des spécificités de chaque service, avec un init SysV, chaque script contient beaucoup de code standard, copié-collé de l'un Í l'autre (on dit «Â boilerplate » dans le jragon), juste pour assurer le fonctionnement. C'est une pratique largement et justement considérée comme très mauvaise.
Stéphane CARPENTIER , dans le message
<629a2c24$0$18400$426a74cc@news.free.fr>, a écrit :
Avec SysV, c'était la galère Í chaque montée de version. La
distribution déployait la nouvelle version du fichier de conf avec
les nouvelles options et il fallait que je retrouve mes
personnalisations pour merger mon fichier personnalisé avec le
nouveau fichier de ma distribution.
Tout Í fait. En plus des spécificités de chaque service, avec un init SysV,
chaque script contient beaucoup de code standard, copié-collé de l'un Í
l'autre (on dit «Â boilerplate » dans le jragon), juste pour assurer le
fonctionnement.
C'est une pratique largement et justement considérée comme très mauvaise.
Stéphane CARPENTIER , dans le message <629a2c24$0$18400$, a écrit :
Avec SysV, c'était la galère Í chaque montée de version. La distribution déployait la nouvelle version du fichier de conf avec les nouvelles options et il fallait que je retrouve mes personnalisations pour merger mon fichier personnalisé avec le nouveau fichier de ma distribution.
Tout Í fait. En plus des spécificités de chaque service, avec un init SysV, chaque script contient beaucoup de code standard, copié-collé de l'un Í l'autre (on dit «Â boilerplate » dans le jragon), juste pour assurer le fonctionnement. C'est une pratique largement et justement considérée comme très mauvaise.
