[OSM-talk-fr] article sur un point de vue d'un dev sur l'usage d'OSM

[marc marc]

Bonjour,

Le 09. 04. 18 à 13:43, Nicolas Bétheuil a écrit :
> Ce n'est pas pour déclencher ici une polémique ou un troll velu mais
> plus pour partager un point de vue, au cas où cette article n'est pas
> remonté dans votre veille
> https://www.killiankemps.fr/fr/blog/faut-il-un-nouveau-openstreetmap

Je reste fortement sur ma faim à la lecture de l'article car je me 
demande bien en quoi la solution du titre résoudrait les problèmes de 
fond évoqués.

l'auteur exprime plusieurs problèmes :

- le fait que des logiciels "amateur" (dans le sens "fait comme loisir
et donc avec un temps limité" par opposition à "comme métier payant 
permettant d'y consacrer x h/semaine") ont des bugs ouvert en attente de 
"ressource".
changer de logiciel ne résout en rien cela.
tout au plus pourrions nous en conclure qu'il faudrait soit diminuer 
l'excessive diversité pour avoir au moins une brique stable par fonction 
(je veux dire par là par exemple que malgré la grande diversité 
d'éditeur sous ios aucun à mes yeux n'a une qualité exaltante)
soit trouver plus de sponsor pour avoir du financement,
comme ont une grande quantité d'acteurs dans l'opensource.

- la qualité des données dans osm (l'exemple d'un poi sans nom)
je ne vois pas en quoi changer de logiciel va résoudre cela.
si un contributeur veux introduire un café sans nom dans osm-bis,
cela revient à la même situation. la seule solution serrait d'imposer 
une liste de tag obligatoire (par exemple le nom) et dans ce cas, on se 
retrouve parfois comme pour les changeset où quelqu'un a mis "a" comme 
commentaire à de nombreux changeset parce que pas envie de décrire.
on a aussi le cas sur le wiki ou des opérations de masse sont faite sans 
descriptif parce que son auteur estime qu'à ses yeux, c'est pas utile,
avec les grincements que cela provoque régulièrement.
On peux difficilement éviter ceux qui pense que "les règles de l'art" ne 
sont pas pour eux ou ceux qui n'ont parfois simplement pas le temps ou 
pas l'info pour complèter tout (qui n'a jamais eu le cas d'avoir passé 
une soirée dans un lieu sans se souvenir de toutes les infos le lendemain ?)

- les adresses : oui c'est un gros problèmes, cfr la discussion 
précédente sur le sujet.
Sur ce point, il est vrai qu'il semble bien compliqué de proposer
un nouveau schéma puisque même un changement cosmétique de l'actuel
est compliqué même a argumenté.
mais que résoudrait un basculement vers osm-bis ?
soit osm-bis a un schéma qui résout ce problème, et celui ci pourrait 
aussi résoudre le problème dans osm. soit il ne le résout pas et rien ne 
change.

- les id non stable dans osm : problème résolu depuis longtemps,
cfr overpass stable id.
la vrai question est qu'est-ce qui doit être stable ?
un POI qui déménage 2 rues + loin, c'est le poi qui garde l'id même s'il 
bouge ? ou c'est le lieu qui garde l'id même s'il change de type ?
Pour l'instant ce serra au cas par cas. donc utilisation réduite.

- résistance au changement
Le seul vrai soucis que je vois c'est la résistance au changement,
par exemple quand le nom d'un tag est mal choisit (exemple 
highway=bus_stop), il y a une énorme résistance au changement pour 
modifier l'existant. c'est sans doute la seule chose où un osm-bis 
pourrait agir.
Par analogie avec apache<>ngix, osm n'est pas qu'un brique logicielle 
qu'il suffit de changer par "désinstalle apache, installe ngnix",
changer apache par ngnix n'a de sens que si les 2 sont capable de servir 
une page html.
de même la plus-value d'osm, c'est surtout sa db.
et pour résoudre cela, à court terme, on peux envisager un convertisseur 
(ou préprocesseur) qui corrigerait une série d'anomalie pour éviter que 
chaque utilisateur des données doit construire son préprocesseur.
Cependant, cela ne motive pas grand monde, suffit de voir les nombreuses 
opérations "tag de la semaine" que j'ai lancé pour corriger 
ponctuellement un problème de tag, c'était le jackpot quand on arrivait 
à 3 personnes actifs, hélas.
Faire un osm-bis ne résoudrait pas là non plus beaucoup les choses.
tout au plus cela pourrait mettre en place un autre de vote des schémas.
Finalement faire un préprocesseur, c'est le même travail que faire une 
édition de masse (hormis le problème de territorialité)
Et la bonne nouvelle à ce sujet, c'est qu'aucune opération d'édition de 
masse proposée en francophonie récemment n'a jamais subit la "résistance 
au changement".
donc il y a qu'à proposer pour améliorer ce qui peux l'être à ce niveau.

Cordialement,
Marc