Bonjour,
>>d'attributs qualifiant chaque tronçon est souvent très insufisant pour nos >>besoins, quand ils ne sont pas optionnels. Dans ces conditions, on ne peut >>pas raisonnablement faire tourner un algo d'itinéraire. Pas dans l'état >>actuel de la base Ce qu'il veut dire ici, ce n'est pas que le nombre possible de tags est limité, mais que la quantité d'information attributaire renseignée est beaucoup trop faible pour leurs usages. Certes faire du calcul d'itinéraire sur des données OSM ça a déjà été fait. Mais les moteurs de calcul d'itinéraire comme celui de mappy sont beaucoup plus complexes que ceux qui ont été implémentés sur les données OSM, et nécessitent des informations attributaires qui ne sont que peu renseignées dans OSM. >Au delà du retour, qui me semble intéressant, cela m'étonne fortement que la >licence actuelle ne permette pas de conserver ses propres POIs. >Des idées là dessus ? >Est-ce que la clause SA de Creative Commons considère qu'un rendu agrégé (ie >"en une seule tuile raster") des données OSM + des POIs est une oeuvre >dérivée qui doit être placée sous la même licence, alors que le fait de >placer les POIs dans une autre couche (ie "deux tuiles raster" ou "une tuile >raster + des données vecteur au dessus") permettrait de passer outre ? On retombe clairement dans le vieux débat qui date d'avant OSM sur la notion de «produit dérivé», et qui est un cauchemar juridique sans nom, quand il y a des contraintes de licence sur ces produits dérivés, ce qui est le cas d'OSM (la clause SA), mais aussi de l'ign par exemple (clauses bien plus contraignantes). Pour ce qui est agrégé en une seule tuile raster, je n'en sais rien à vrai dire, et effectivement tant qu'une jurisprudence n'a pas vu le jour la dessus ça risque d'être très dur à trancher. Mais sur le problème de fond, cette remarque de mappy est très intéressante : >>il faut analyser attentivement les conditions d'utilisation; nous ne sommes >>pas certains que l'on puisse utiliser des données OSM sans que les points >>d'intérêt que nous y plaçons ne tombent pas dans le domaine public ; or, >>nous n'avons pas l'intention de faire don de nos POI, par exemple les 70000 >>hotels que nous avons acquis, et qui représentent une forte valeur ajoutée. >>Cependant, echaîne François Plancke, il semble qu'une licence alternative >>soit à l'étude pour pallier ce problème. Quoi qu'il en soit, le nombre Ce qui les intéresse n'est de toutes façons pas d'afficher leurs POI au dessus d'une carte OSM. Les POI rentrent directement dans les algorithmes de calcul de Mappy, notamment par exemple pour du géocodage. Pouvoir faire un itinéraire piéton entre «gare de lyon» et «monoprix ledru rollin» par exemple, c'est leur coeur de métier. Ici on utilise donc les POIs pour le geocodage, qui permet de récupérer les troncons associés et de calculer l'itinéraire. Pour faire cela, il faut avoir les POIs et le graphe de réseau routier dans la même base de données. Et ensuite on fait des jointures sur les tables de routier et les tables de POIs. Si le routier est en CC-By-SA, alors les POIs le deviennent aussi dans ce cas. Et ça c'est impossible pour eux. C'est un exemple particulier, mais je connais de multiples acteurs privés qui ont exactement la même problèmatique. Leur utilisation est en générale celle ci : - des données de base, souvent le réseau routier. Ce sont les données de référence - les données métier, construites sur, et avec les données de référence, ainsi qu'avec des données propres. Par exemple des zones d'exposition au bruit, construites par l'utilisation de capteurs ponctuels, et interpolées sur le réseau routier en tenant compte des attributs de celui ci. En général ces sociétés achétent très très très cher les données de référence avec des droits d'utilisation qui leurs laissent faire ce qu'ils veulent avec. Ils ont parfois des contrats de partenariat où ils remontent des données aux producteurs pour baisser la facture. Ils font souvent de la mise à jour, de l'enrichissement, des traitements et adaptations sur ces données car ils en ont besoin, mais ce n'est pas leur métier. Par contre les données métier sont leur coeur d'activité. Ce sont des bases ultra protégées qui ne sortent jamais de l'entreprise et qui constituent sa valeur. Lacher ces données dans la nature reviendrait à une mort immédiate ou une refonte totale de leur modèle économique, chose non envisageable sans 10 ans d'évolution. Ces acteurs sont très intéressés par OSM pour remplacer les données de référence. D'une part pour des questions de cout bien sur, mais pas uniquement. Ils comprennent très bien les concepts de crowdsourcing, la capacité de la plateforme OSM, et les tenants et les aboutissants d'un changement de mode de production de ces données de référence. Ils sont tout à fait prêts à y collaborer, à financer, à apporter de l'expertise. Tant qu'on ne touche pas à leurs données métier. Aujourd'hui la clause SA interdit complètement cela, et c'est fort dommage. C'est le même débat que pour les logiciels entre BSD et GPL ou entre LGPL et GPL. Il est désormais complètement admis dans le monde du logiciel que les bibliothèques de base ne doivent surtout pas être sous GPL sous peine d'être un frein complet au développement plutot qu'un mécanisme d'accélération du développement. La licence LGPL, qui permet les produits logiciels «basés sur» ces composants, sans contrainte de relicencier sous les mêmes clauses, gouverne la plupart des projets de bas niveau. Beaucoup sont même pour du BSD intégral, en disant : ce n'est pas le code qui est important, mais la communauté et l'écosystème. Même si je ne suis personnellement pas un puriste 100%-BSD, je rejoins ce point de vue, que soulignait encore hier Paul Ramsey, développeur de PostGIS, en réaction justement à une présentation de Steve Coast : http://blog.cleverelephant.ca/2010/04/on-road-to-damascus-gpl-to-bsd.html OSM me parait encore plus propice à une libération totale des données en gardant juste l'attribution, en supprimant le casse tête SA qui ne fait que freiner une adoption plus large, et donc des contributions. La plus grande force d'OSM c'est la communauté, son organisation et son l'infrastructure. Les données n'en sont qu'une heureuse conséquence. Vincent _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
