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 _______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
