[OSM-talk-fr] Sur le modèle des adresses (était "Rendu BANO")

[Philippe Verdy]

Le 26 mai 2014 11:27, Pieren <pieren3 at gmail.com> a écrit :

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

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.
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.
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.

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.
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.
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.
On peut même aller vers des intégrations bidirectionnelles.
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
b
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.

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.

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.

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.

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.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20140526/88b56449/attachment.htm>