Peut-être que l'outil de validation pourrait faire un test minimal sur la validité de codage chaque chaîne (possible au moins pour l'UTF-8). En cas de violation une analyse de probabilité: en France ça doit être de l'ISO 8859-1 ou du CP-850 et les changements d'interprétation sont certainement le plus souvent sur des lettres accentuées très courantes dans la toponymie (é, è, à, ê, î) et une base de mots fréquents (allée, église, cimetière, hôpital, dépôt, etc.) ou polygrammes finals de mots fréquents (/.*ées?/, /.*ères?/, etc.) doit pouvoir remédier à l'ambiguité pour tenter une réparation automatique, mais dans tous les cas ne laisser aucun encodage invalide et au minimum considérer que la source est du Windows-1252, et en dernier lieu du CP850 (presque tout les octets sont valides hors des contrôles C0), avant de convertir en UTF-8, afin de laisser ces caractères visibles distinctement (même si c'est encore du "mojibake") afin que le correcteur humain puisse s'en apercevoir (qui sait si une source n'a pas utilisé par erreur lors de la saisie un autre codage moins probable comme un jeu latin d'Europe centrale en ISO ou page de code Windows ou OEM, ou a fait une erreur d'utilisation dans un outil d'export ou une base intermédiaire)
Dans tous les cas, un journal de signalement devrait être réalisé pour permettre au minimum un contrôle humain et une validation et un retour d'informations vers la source de ces données boguées (toutes les sources font des erreurs, même OSM lui-même, via des contributeurs internationaux qui utilisent nativement divers claviers et langues et des logiciels obsolètes ou mal configurés). Le mer. 25 mars 2020 à 18:11, Frédéric Rodrigo <fred.rodr...@gmail.com> a écrit : > > Le 25/03/2020 à 17:27, Yves P. a écrit : > > Bonjour, > > > > Je viens de regarder le résultat de la dernière PR. > > Ici > > <http://osmose.openstreetmap.fr/fr/map/#zoom=12&lat=46.6952&lon=5.0938&item=8330%2C8331%2C8340%2C8341%2C8350%2C8351&level=1%2C2%2C3&tags=&fixable=>les > > localisations ne correspondent pas du tout aux adresses. > > Ce sont les positions du fichier proposée en opendata. C'est bien pour > ça que l'on passe par de l'intégration manuelle. > > > > > > Les accents sont aussi manquants (champ subtitle): > > C'est donc que l'encodage n'est toujours pas bon. Il y a peut être > plusieurs encodage dans le fichier. > > > > _______________________________________________ > 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
