> > Je les trouve globalement pertinentes mais j'ai tout de même quelques > réserves : > > 4. « Des exemples de réutilisation (fictifs ou réels) sont fournis » >
Je suis aller voir le site et impossible de savoir sur quoi se base l'analyses (quels administrations, organismes...) on a des numéros pour valeurs et anonymiser. quel intérêt? > > > 16. « Aucun dispositif n'est mis en place pour empêcher la récupération > automatique ou programmatique des données » > > Certes, une application doit pouvoir récupérer les données sans qu'il > soit nécessaire de faire intervenir un opérateur. Cependant, ces > requêtes peuvent être - et je dirais même doivent être - plafonnées > d'une ou plusieurs manières (limitation de débit, du nombre de > requêtes simultanées en provenance d'une adresse IP, du nombre de > requêtes par seconde, etc.) afin d'éviter les attaques de déni de > service et d'assurer une bonne qualité de service au plus grand > nombre. Formulée ainsi, la bonne pratique est donc discutable. > Ben c'est du bon sens et ça rentre dans la sécurité du SI. Plafonner le nombre de requête et le débit ça peut (et doit) se faire en amont même de l'api ou du site pour éviter la surcharge du serveur. Après le pompage complet ou empécher la récupération auto c'est débile... D'une part c'est de l'OpenData d'autre par même avec une demande d'authentification et de validation, tu peux faire un script d'automatisation. Aller y mettre un captcha c'est pas forcément intéressant sauf pour le système de commentaire ou de publication. > > 47. « Les jeux de données sont accompagnées d'une licence » > 51. « Les jeux de données sont accompagnés d'un résumé et d'un lien vers > la version complète de la licence » > C'est très con. Oui pour l'accompagnement et j'en parlais plus haut. Non pour le résumé. La licence doit être complète sinon elle ne sert à rien (sauf pour dire: fait ce que tu veux) > > 61. « Si un jeu de données comporte des erreurs, des incertitudes ou est > incomplet, ces informations l'accompagnent » > > Cette pratique me laisse perplexe : > > - En tant que développeur, je dirais qu'une erreur, cela ne se > documente pas mais se corrige. > Tu peux fournir un référentiel et un programme avec des erreurs. Cette info est documentée comme pour les programmes et les services de données si elle est connu sur une version et qu'elle n'est pas corrigé. Comme des problèmes de compatibilités. Une erreur de calage pour des orthophotos peut être défini donc oui ça existe et oui ça se corrige. > > - Des incertitudes sur l'exactitude ou la complétude des données, il > y en a toujours ; je préfère là encore que les personnes en charge > de ces données consacrent leur temps à les améliorer qu'à > documenter leurs faiblesses. > Les incertitudes sont lié au traitement automatique et aux tests (ou inexistence de test) permettant de vérifier la qualité des données. Documenter cette incertitude permet au client de prendre en compte des marge de sécurité. des tracé GPS on une incertitude sur la précision. En altimétrie c'est super important pour éviter qu'un avion se crache sur un obstacle Dans un référentiel on peut (et devrait) définir ce qu'il contient et ne contient pas car cela permet de rapidement appréhender les limites d'une données et de la compléter au besoin. autre exemple: l'imprécision peut être du à une reprojection de données d'ou une perte de qualité géographique. Dans le cas d'un scan, la limite est lié au procédé de génération du précédent document et au matériel d'acqusition, donc difficile de faire un simple patch ;-) > 64. « Il est possible d'obtenir des informations concernant le niveau de > confiance à accorder aux données » > > Cette pratique est redondante avec celle que je critiquais plus haut > et est donc sujette à la même critique (en plus de son caractère > redondant). > Rien de redondant! Si tes données correspondent à des formulaires de saisie effectués par du publique sur des valeurs abstraite comme le resenti tu ne pourra pas prendre cette information comme un critère dure comme des données de capteurs scientifique. C'est le cas de l'analyse de la macrosismie dont les formulaires sont basées sur le ressenti et sur l'observation de dégat. Les formulaires sont ensuite retraité par un expert pour données une valeur. Donc un critère de confiance ou de pertinece est apporté aux données et l'on peut données un pourcentage par niveau de confiance et décrire comment ce critère à lui même été établi > > 67. « Des extraits des différents jeux de données sont proposés au > téléchargement » 70. « Un extrait des données peut être prévisualisé » > Là, je dirais juste « bof... », inutile de perdre du temps à cela. > Là je te rejoins car c'est dans la documentation des données que l'on doit préciser les cas, les exemples, les limites, et les particularités(liés au format de données ou autre). C'est présent dans le cas de données payantes mais dans l'OpenData c'est clairement inutile. Si le référentiel est trop important il suffit d'en faire une décomposition. (Limite de territoire, limite naturel, délimitation par niveau d'exploitation et/ou opérateur) > Sébastien > > > > -- > Sébastien Dinot, sebastien.di...@free.fr > http://sebastien.dinot.free.fr/ > Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! > > _______________________________________________ > 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
