<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Le 26 mai 2014 11:27, Pieren <span dir="ltr"><<a href="mailto:pieren3@gmail.com" target="_blank">pieren3@gmail.com</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

2014-05-24 15:04 GMT+02:00 DH <<a href="mailto:dhelfer@free.fr">dhelfer@free.fr</a>>:<br>
<br>
> Ainsi, par exemple, je n'avais pas assimilé l'intérêt des<br>
> relations AssociatedStreet, maintenant si.<br>
<br>
Au risque de me répéter, il y aurait un grand danger à vouloir<br>
généraliser les relations associatedStreet dans OSM pour des raisons<br>
que j'ai déjà expliqué par ailleurs mais que je vais résumer ici:<br>
- c'est plus difficile à modifier. Ceux qui les ajoutent utilisent<br>
josm et c'est vrai que c'est facile d'emploi avec cet éditeur. Mais je<br>
les défie de modifier ces relations avec iD ou P2, ne serait-ce que de<br>
déplacer un numéro d'une rue à sa voisine. C'est très difficile et<br>
chia.. même pour les habitués. Et ne parlons pas des nouveaux<br>
contributeurs ou irréguliers.<br>
- l'argument sur l'intégrité est correct dans l'immédiat mais ne tient<br>
pas au long cours. On le voit avec toutes les relations comme les<br>
limites administratives, toutes les relations de type "route" ou même<br>
les multipolygones (pensez landuse corine), elles sont plus difficiles<br>
à maintenir parce qu'elles sont souvent cassées par les néophites. Ou<br>
pire, si l'éditeur est préventif à l'égard de toute modification comme<br>
dans JOSM, elle bloquera la bonne volonté du débutant.<br></blockquote><div><br></div><div>Contrairement à toi je pense qu'il faut aller vers ce modèle même s'il est plus complexe pour le débutant. Mais cette complexité vient des défauts des outils en question qui ne font pas assez de validation, pas du modèle lui-même.</div>

<div>Je n'aime pas du tout iD à cause de ça: on lui en demande trop, il présente aux débutants une idée fausse de ce qu'est la cartographie.</div><div>Si on veut utiliser iD, à mon avis il ne devrait même pas être utilisé pour alimenter directement la base OSM principale mais alimenter une autre base plus simple pouvant ensuite servir de source d'intégration.</div>

<div><br></div><div>Le modèle de la base unique dans OSM a vécu il va falloir qu'OSM s'ouvre à des bases multiples plus spécialisées, plus faciles à maintenir et plus facile à rapprocher et intégrer avec de plus en plus d'outils d'intégration multiniveau.</div>

<div>Et sans doute la base OSM principale devra ne plus être que le produit de l'intégration d'un certain nombre de couches maintenues séparément. Et à terme ne sera plus qu'une API présentant l'union de plusieurs sources qualifiées.</div>

<div>L'intégration devra être de plus en plus automatique pour que le contributeur humain, lui s'occupe de ce qui est le plus intéressant: travailler sur des sous-bases plus homogènes, plus cohérentes, plus faciles à maintenir.</div>

<div>On peut même aller vers des intégrations bidirectionnelles.</div><div>Pour ça on peut développer des tas de sites ou d'applis et militer pour que toutes ces solutions puissent coexister et faire des échanges et comparaisons</div>

<div>b</div><div>Je pense qu'ID est trop mal fichu pour notre base commune et devra aller vers un travail sur une base séparée utilisant un jeu réduit de données et une modélisation plus spécifique. L'utilisateur lambda est trop noyé sous des tas d'infos qu'il ne peut plus maitriser et qui rendent ses contributions de pus en plus difficile.</div>

<div><br></div><div>Je pense même qu'à terme OSM devrait aller vers un modèle GIS natif et abandonner son modèle qui ne sera plus que virtuel dans une API d'interrogation destiné aux rendus et analyses mais plus du tout en mode écriture: l'utilisateur lui pourra tout voir dans des claques transparents, mais travaillera sur des sous-calques spécialisés.</div>

<div><br></div><div>Et OSM devra supporte un système de versionnement collaboratif, façon Git, permettant aussi des innovations par l'expérimentation sans casser le reste. Et on pourrait s'épargner totalement les imports en permettant d'accéder directement aux bases sources et à leur propre API de contribution collaborative, même si on utilise un même outil visuel où on aura choisi les couches qui nous intéressent et qu'on peu maitriser. Très vite, plus personne ne sera en mesure de tout maitriser dans ces données et cela devient de plus en plus complqué de maintenir la cohérence et gérer les mises à jour car on manque d'états de synthèse.</div>

<div><br></div><div>Alors que faire ? En finir avec l'id d'objet unique et passer aux objets liés par des URNs, autrement dit des ids spécialisés par source, et vers une solution où OSM au lieu de stocker les objets deviendra plutôt un "résolveur" permettant de référencer des tas de bases ouvertes, ou un moteur de recherche permettant de les découvrir. C'est tout le modèle de données d'OSM qui est à revoir, il montre aujourd'hui clairement ses limites et coûte trop cher à maintenir (tant en moyens nécessaires qu'en terme de moyens humains), cette base étnt de plus en plus compliquée à aborder par des humains, même experts dans leurs domaines de compétence.</div>

<div><br></div><div>OSM pourrait s'inspirer des projets comme Wikidata (qui commence à devenir aussi une base de données cartographiques en tant que tel tout en étant ouvert à plus d'utilisations). Le gros du travail de Wikidata est encore fait par des bots d'import, mais cela va se tarir et c'est vers de nouvelles interfaces utilisateurs plus spécialisées et plus simples qu'il faut aller.</div>

<div><br></div><div><br></div></div></div></div>