Je suis entièrement d’accord du point de la séparation donnée/rendu.
Le but du jeu c’est de pouvoir comprendre la donnée de façon univoque !
On sait que tant que ce seront des humains qui saisiront des données dans
la base, il y aura des erreurs. Et les erreurs sont d’autant plus
nombreuses qu’elles ne sont pas clairement visibles (je parle ici des
espaces) ; ou que les règles sont méconnues.
Beaucoup d’algorithmes automatiques sont justement là pour corriger ou
pallier à ces erreurs. Ils font des merveilles pour rajouter ou supprimer
des espaces ou de la ponctuation devant tel ou tel caractère, changer la
casse (Rue saint-Antoine), même reconnaître des erreurs évidentes telles
que « aveneu » à la place de « avenue ».
Seulement voilà, ces algorithmes ont leurs limites devant une ambiguïté
telle que « Maisons-Alfort - Stade » ; je trouve que tenter de lever une
ambiguïté à l’aide de l’espace qui est un caractère particulièrement enclin
à générer des erreurs n’est pas du tout judicieux.
Les lettres, les articles de journaux, et autres éditions françaises ne
sont pas traités automatiquement comme le sont les données d’OSM ; dans les
journaux, c’est l’humain au final qui lève les ambiguïtés grâce à sa
mémoire colossale et sa capacité de reconnaissance à la volée ; les
algorithmes automatiques d’aujourd’hui ne sont pas capable d’un tel prodige
à moins d’efforts démesurés pour les concevoir (parole de développeur).
La base OSM est tellement grosse, que malgré la puissance du cerveau humain
personne ne peut corriger la base. Et quand bien même il le pourrait, vu
que c’est un humain, il fera des erreurs. Donc, c’est bien un algorithme
qui traitera toutes ces données si on veut supprimer les erreurs.
Je pense qu’on ne peut pas demander aux contributeurs bienveillant
d’appauvrir leurs données sous prétexte que la majorité ne peuvent pas
atteindre cette précision ; d’autant que cette précision est bénéfique et
utilisable. Et là, je ne parle pas que de typographie !
Je pense qu’utiliser les bons caractères au bon endroit est un bonus !
Cordialement,
--
Mikaël Cordon, mickey86
Le 29 novembre 2012 11:53, Pieren <pier...@gmail.com> a écrit :
> 2012/11/29 Mikaël Cordon <mikael.cor...@gmail.com>:
>
> > Enfin, je rajouterai que je suis également adepte de l’utilisation des
> > différentes espaces (fines, insécables, etc…), l’apostrophe française et
> des
> > guillemets français.
>
> Ceci explique cela ;-)
> Je remarque qu'il y a parmi le public des contributeurs français une
> très petite minorité d'adeptes de la belle typographie française, qui
> en connaissent les règles et les moyens de saisie. D'ailleurs, ils
> viennent souvent de wikipedia. Mais le tag "name" n'est pas un article
> wikipedia, le tag "name" ne sert pas à imprimer les panneaux de
> signalisation, le tag "name" n'a pas à respecter les règles
> typographiques des imprimeurs. Parce que dans OSM, on sépare donnée
> factuelle et rendu. OSM, c'est de la donnée brute pour le monde
> entier. Et il n'y a qu'en France que je vois autant de tirets longs
> pour faire de la sémantique. Alors que oui, ce caractère existe dans
> tous les pays, même en chinois (—— 破折号) mais il risque de ne pas avoir
> le même emploi !
> On a déjà discuté règles typographiques ici et on a constaté que 1.
> elles étaient en contradiction avec les règles de toponymie ("Rue
> Saint-Antoine" devrait s'écrire "Rue saint-Antoine") 2. qu'il n'y
> avait pas de standard universel même en France puisque l'académie a
> ses règles, les grands journaux ont les leurs, les éditeurs/imprimeurs
> aussi, etc-
>
> Pieren
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
