[OSM-talk-fr] Limites communales dans les DOM - Construction de la limite de guadeloupe

[Philippe Verdy]

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