2009/11/4 Vincent Pottier <vpott...@gmail.com> > > Faut-il qu'OSM soit un SIG comme les autres ? Avec seulement plus de > fourmis à l'entrée ? (et aussi la licence CC, d'accord... ) > L'in des intérêts d'OSM est son accessibilité. Pour la saisie de > données, mais aussi, j'espère, pour leur utilisation, et pas seulement > pour des questions de licence, mais aussi technique. > > J'ai une grande admiration pour les "pros", leur habileté et leur > travail (ils se reconnaîtront), mais s'il faut un bac+7 en géomatique > pour commencer à utiliser OSM, dommage. > > Sans aller jusqu'à un bac +7, quand tu commences a faire une application relativement simple, tu as plutôt intérêt a maîtriser un minimum de chose. J'ai touche a la geomatique il y a juste maintenant un an et demi. Avant cela, je n'avais jamais entendu parler de GIS et du reste. Globalement en programmation, j'ai le point de vue que Visual Basic a été un des pires fléaux que Microsoft ait pu infligé au monde. Pourquoi? Parce que des gens qui n'avaient pas les bases ont pu commencer a bidouiller des applications mal conçues et a produire des programmes en jurant sur leurs grands dieux, qu'ils sont des rois de la programmation. Après, il faut toujours faire la maintenance qui est toujours quasiment impossible car il n'y a eus aucune structure initialement. Je pense qu'il ne faudrait pas reproduire ce genre de schéma avec OSM en facilitant de trop la tache aux programmeurs occasionnels. Il faut apprendre un minimum avant de se jeter dans la gueule du loup. Ce n'est pas un point de vue élitiste mais tôt ou tard il faut faire la maintenance de ces programmes mal conçus. De plus, je suis la première a donner des explications s'il y a besoin plutôt que de voir une mauvaise application apparaître. Car le gros problème c'est qu'une fois qu'une application apparaît, elle commence a être utilisée et il faut optimiser, et a moins d'avoir une vue d'ensemble sur ce que tu veux, c'est très dur.
> L'autre solution, c'est le développement d'une bonne bibliothèque (en > python et php, langage courant chez les non-développeurs) de scripts > pour les requêtes de base. Un légo de la géomatique en quelque sorte, un > jQuery de l'OSM. Ça, c'est du boulot de développeurs à destination de > non-développeurs... > > Oui, enfin, le problème c'est que derrière tu dois avoir une base de donnée pour exploiter ces requêtes de base. Il faut donc configurer cette base de donnée, faire des requêtes qui tiennent debout etc... Ce n'est pas aussi simple que ça. OSM est un format XML mais avant d'être utile il faut le transformer dans une base de donnée, et rien que ça même avec une bibliothèque, tu n'avanceras pas énormément car les non développeurs trouveront toujours un moyen de casser le backend en faisant des requêtes trop grandes etc... par non compréhension de comment ça tourne par derrière. A ce propos, on peut citer la réponse de Frederik Ramm a Peter Miller sur la liste de modération: la demande de Peter mettrait tout simplement a genou le serveur en apportant qu'un avantage très limité. > Avec un tel tas de briques, les usages d'OSM exploseront... > > Peut être, mais je crois que déjà les usages d'OSM explosent. Il y a beaucoup de gens qui interviennent ici qui ont un intérêt professionnel dans OSM et qui ont des projets pour OSM. Je suis pour une augmentation de l'utilisation de OSM, mais je ne suis pas sure que tous les systèmes de base soient présents actuellement. La base n'est pas encore tout a fait stable. Mapnik et le reste fonctionne bien mais il reste encore trop souvent des problèmes. Il y a aussi le problème de la base de donnée. Pour le moment, on a une base de donnée centrale, mais on n'a pas encore trouve comment la décentraliser et de la faire grandir a part en ajoutant plus de matériels. OSM fonctionne bien mais si la croissance continue, on va se heurter a des contraintes techniques plus importantes dans le futur, car sur pas mal de points, c'est encore l'inconnu. Emilie Laffray
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr