On peut aussi taguer à la fois: - pour ce que les outils actuels (malgré leurs défauts) savent faire et interpréter, tout en sachant que ce n'est pas encore l'idéal et que cela devient de plus en plus lourd ou ambigu à interpréter. - ET en même temps commencer à taguer pour ce que les outils devraient savoir gérer et interpréter de façon moins ambiguë (ces nouveaux tags apportant une sémantique plus précise tout en étant à la fois moins lourde à gérer.
Tant que les tags sont différents on s'en sort. Mais au moins cela permet déjà d'avancer sur ce que devraient être les outils à l'avenir et qui vont progressivement apprendre à reconnaitre les nouvelles sémantiques. Sinon on tombe systématiquement dans le piège de l'œuf et de la poule (lequel vient en premier ?). À vouloir toujours ménager à la fois la chèvre et le chou on reste sur la mauvaise rive, on ne franchit pas le fleuve, et on regarde les autres avancer plus facilement que nous et plus vite parce qu'ils ont inventé l'enclos pour garder la chèvre, et engagé un pilote pour faire traverser le chou sur la barque (autrement dit, séparation des tâches par un travail séparable en équipes) tandis que pendant ce temps là les fermiers sont déjà avec les clients pour leur vendre et la chèvre, et le chou, et qu'ils ont déjà commandé un nouveau bateau plus grand pour transporter le tout, tout en ayant prévu la construction d'un pont qui réconciliera tout le monde et rendra obsolète l'ancienne barque tout en permettant d'étendre les élevages et les cultures, et diversifier les espèces produites. ;-> Il faut aussi savoir regarder à côté de nous ce qui marche bien et vite et ne pas rester sur nos seules solutions franco-centrées, voire aussi OSM-centrées (là je parle des autres systèmes SIG, et aussi des systèmes cartographiques concurrents (commerciaux comme Google, ou pas comme les projets forks d'OSM): il me parait clair qu'on évoluera à terme non pas vers une base unique contenant tout, mais vers une galaxie de bases de données permettant des recherches croisées et générant leurs propres couches éditables plus simplement et séparément, et plus facile aussi à vérifier et à conserver dans un étant homogène. Avec une galaxie de bases, les expérimentations comme les migrations vers un schéma plus pratique et plus précis seront aussi bien plus faciles, et il sera plus facile aux nouveaux contributeurs de s'intéresser à une partie des données sans casser le reste qu'il ne maîtrisent pas. Dès lors on ne parlera plus d'imports massifs, les intégrations demanderont moins de travail (au lieu de fusionner les objets, on les rapprochera plus ou moins par des références relationelles interbases seulement là où ces rapprochements seront pertinents. Et dans de nombreux cas, nombre d'attributs actuellement ajoutés directement aux objets géographiques n'auront même plus besoin d'y être puisque pour la plupart ils seront remplacés par des identifiants de référence qu'on pourra lier à des bases de données relationnelles externes (par exemple pour les différentes traductions, ou la tonomymie officielle, ou des données statistiques): les objets actuels de type "relation" pourront encore servir, mais à terme des primitives plus orientées OpenGIS standard feront partie de l'arsenal (sans nécessiter de coûteuses et constantes réparations de géométries ni de conversions complexes à cause des différentes interprétations). OSM en est encore à son enfance et manque de maturité, il y a plein de choses qui vont évoluer dans le schéma et peut être qu'à terme on travaillera directement dans un schéma OpenGIS (sans conversion intermédiaire pour les réimports vers pgSQL), même s'il restera éventuellement encore un serveur proposant une vue (dynamique) permettant de voir le schéma actuel pendant un certain temps pour conserver les outils actuels utilisables. Même nos éditeurs vont faire vite pâle figure à côté de ce qui se fait dans le monde SIG où des normes sont développées (et qui constituent déjà des volumes de données bien plus importants que la totalité d'OSM actuel). Même en France, les outils développés par SANDRE ou l'IGN ou par d'autres bases européennes, sont Open Source (tout en étant beaucoup moins lourds à utiliser et plus productifs et efficaces qu'OSM). Aussi je regrette qu'on en reste encore à ne vouloir pas faire évoluer nos schémas vers une logique d'avantage orientée avec les normes. OSM souffre de gros défauts un peu partout à cause du fait qu'il est trop permissif (juste pour permettre une évolutivité qui en pratique n'a pas lieu car on se noie d'abord dans les problèmes d'évolutivité et de cohérence des données : on ne profite pas du fait qu'au départ c'est une base de données, et donc qu'elle doit pouvoir effectuer des contrôles d'intégrité, des ordonnancements et clasements automatiques, et de la possibilité d'être autoorganisée avec des structures de données mieux adaptées et moins redondantes: le modèle des relations qui ne contiennent QUE des chemins simples pour créer des polygones est un exemple : on l'a utilisé au départ surtout pour permettre d'avoir des chemins plus longs que les 2000 noeuds, mais on y a tout mélangé entre les concepts géométriques de base). Alors puisque les relations sont là pour permettre l'évolutivité des schémas, pourquoi les utilise-t-on encore aussi mal (avec autant de résistances en plus pour que cela change) et pourquoi il y a tant de résistances à même les utiliser au mieux de ce qu'elles pourraient faire ? On les a appelées "relations" et pourtant on résiste encore à en faire des objets "relationnels" (avec tout ce que cela impllique en terme de modélisation relationnelle des données, de contrôles référentiels et d'indexabilité), ce qui est un comble ! A chaque fois on se retrouve alors à devoir faire des mauvais compromis dans les choix d'intégration, ou à sacrifier la qualité voire aussi l'exhaustivité sur des données qui pourtant seraient bien utiles.
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
