Un prestataire peut répondre en créant un serveur avec une API dont les données ont subi une étape de prévalidation afin de pouvoir intervenir directement sur des aberrations. Il lui faudra mettre en place toute une batterie d'outils (ce qu'a fait MapBox en créant une base dérivée, mais au prix de mises à jour différées). Là je pense surtout qu'il s'agit d'une question d'image: OSM est plus connu que les SIG publics et plus visible. Ce qui est demandé est d'avoir quelqu'un capable d'intégrer correctement dans OSM les mises à jour publiques pour que ces données ne restent pas seulement dans les SIG et prennent du retard avant d'être intégrées et visibles dans OSM. Les indicateurs de qualité sont pourtant possibles même avec la base OSM non modifiée, mais ça demande un développement d'une base de données parallèle pour faire un suivi. Le prestataire en plus n'a pas besoin de suivre le monde entier, juste la zone demandée, et développer ou utiliser les outils de veille qualité et identifier les problèmes. La mesure de qualité peut être les outils de rapprochements (comparables à ceux développés pour BANO) mais d'autres sont certainement à écrire pour fournir ces mesures et aider à définir des seuils de qualité. Le SIG du STIF founit des données avec des mesures quantitatives, et des outils comme OverpassTurbo peuvent faire des recherche dans OSM. Les rapprochements peuvent indiquer les différences et les mesurer. Pour faire ensuite le travail de correction, il faudra des outils d'importation et respecter les règles communes et définir ce qui est acceptable comme différences. Le prestataire aurait intérêt d'ailleurs à mettre ses outils QA à disposition de la communauté pour que ces corrections soient aussi discutées collectivement et ne passent pas comme des imports en masse.
Le 28 mars 2017 à 10:05, Jean-Marc Liotier <j...@liotier.org> a écrit : > On Tue, 28 Mar 2017 07:43:05 +0000 > "HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI > PERFORMANCE)" <denis.hel...@reseau.sncf.fr> wrote: > > > > Extrait du DCE : > > > > 3.2 MODERER LES CONTRIBUTIONS EXTERNES > > De plus, la diversité de la qualité des contributeurs entraîne une > > information renseignée parfois inexacte ou incomplète. La volonté du > > STIF est de mandater un prestataire en charge de modérer les données > > renseignées sur OSM par des contributeurs externes. > > > > Maintien de la qualité des données au sein d’OSM, c’est pas > > suffisant ? > > Les clients expriment généralement le besoin d'avoir quelqu'un sur qui > taper en cas de problème et par conséquent ils désignent leur > prestataire comme responsable des données. Le prestataire a tout > intérêt à améliorer la qualité en amont, au sein d'Openstreetmap - mais > du point de vue du client Openstreetmap n'existe pas et le prestataire > est l'unique fournisseur de données dont il est réputé contrôler la > qualité. > > En pratique et dans l'état actuel d'Openstreetmap j'imagine mal le > client pénaliser le prestataire pour une boite aux lettres manquante ou > un défaut de capitalisation dans le nom d'un restaurant... J'imagine que > la clause a plutôt pour but de s'assurer que le planet béni par le > prestataire ne contient pas un highway=primary gonadomorphe recouvrant > la région. > > Je serai le prestataire, je demanderai quand même de définir un petit > peu plus précisément les indicateurs de qualité retenus pour mesurer > l'exécution du contrat. > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr