Ce qui se complique encore quand les toponymes ***officiels*** espagnols
utilisent le "/" pour séparer les noms ***co-officiels*** issus de
plusieurs langues, ces deux langues ***devant*** toujours être citées
ensembles et dans l'ordre indiqué sans qu'on puisse en supprimer un ! C'est
alors le même toponyme dans les langues d'origine, les différences
linguistiques étant alors abolies dans la dénomination officielle pour la
même entité (regardez le Pays Basque espagnol par exemple).
Dans ce cas le "/" ne signifie pas non plus "sur", ***même*** en Français.
Comment alors faire un traitement automatique de substitution "pour faire
joli" ?
Oui effectivement le "/" a sa propre sémantique dans ce cas, mais on ne
doit PAS l'utiliser comme s'il s'agissait d'une abréviation, même en
français.
Bref en aucun cas "Argenton / Creuse" ne signifie la même chose que
"Argenton-sur-Creuse" (ne pas oublier non plus les traits d'union ici !)
Car en Espagne et même en français, ce "/" est un séparateur, distingué de
l'autre séparateur trait d'union qui est aussi utilisé pour juxtaposer deux
termes mais avec une autre signification.
L'idée qu'un moteur de rendu peut librement remplacer la ponctuation est
totalement erronée, chacune a sa signification propre mais on ne peut pas
la déduire de la seule façon dont cette ponctuation est codée puisque pour
cela il faudrait coder ***aussi*** la sémantique.
Bref apprenons à utiliser la bonne ponctuation dès le départ, ou corrigeons
pour la rendre la plus précise possible si une version ambiguë a été
utilisée (ce qu'on n'interdit pas, pas plus qu'on interdit de cartographier
la géométrie avec une résolution faible pour ensuite l'améliorer plus tard.
Mais enlever des précisions ç la géométrie est bien une destruction
d'information pertinente.
Dans le même principe remplacer tous les tirets distingués par un seul sera
aussi destructeur de distinctions (et tant pis si le lecteur lambda ne
saisit pas bien la différence, celle-ci existe, de même tant pis si un
utilisateur lambda n'a pas besoin d'une géométrie détaillée, il y en a
aussi qui voudront ces détails pertinents). De même si un utilisateur ne
voit pas l'intérêt d'un tag qu'il ne comprend pas, il ne doit pas l'enlever
sans avoir compris ce qu'il servait à distinguer.
On peut admettre aussi temporairement des abréviations, pour qu'ensuite
quelqu'un les remplace par la forme non abrégée, mais en aucun cas on ne
vas revenir en remplaçant à nouveau le nom correct par des abréviations.
Dans tous ces cas, on n'interdit pas de commencer par des versions
"simples" qui sont ensuite précisés par d'autres. Mais faire une règle pour
dire qu'on interdit de préciser les choses, c'est du même ordre que l'idée
de dire que la base OSM est suffisante et qu'il n'y a plus rien à y ajouter
ou préciser.
L'envie "d'uniformiser" les choses ne justifie rien ici, car il n'y a même
aucun besoin technique de cette uniformisation dans des champs exprimés
dans une langue humaine, non destinés à être lus par des machines. Mais si
les machines veulent le faire (en simplifant les choses pour leur propre
usage), les solutions existent, et cela s'appelle UCA (Unicode Collation
Algorithm). C'est tout à fait ce qu'utilisent n'importe quel moteur de
recherche en plein texte (aucun n'est bloqué par la ponctuation).
La situation est très différente pour ce qui est des identificateurs ou
codes, destinés à servir de point d'entrée fixes dans un index pour un
accès rapide et non ambigu (les ref:* par exemple, mais aussi les URL) sans
que la machine ait à gérer des ambiguïtés : il faut un identifiant UNIQUE,
stable et le plus universel possible, qualifié si nécessaire (ce qu'on
suffixe à la clé "ref:" par exemple), et pour cela aussi on adopte des
conventions les plus strictes possibles (comme un jeu de caractères réduit,
une uniformisation de la casse, la suppression des caractères redondants...)
La contrainte pour les *identifiants* (les attributs name=* ne sont pas des
identifiants, mais les ref:INSEE=* ou les codes postaux en sont, de même
que nombre de valeurs codifiées dans OSM utilisant des _ au lieu des
espaces, plus ou moins abrégés et uniquement en anglais quand leur usage
n'est pas spécifique à un seul pays dans une norme nationale exprimée dans
une seule langue) est complètement différente de celle pour les textes
destinés aux humains et exprimés dans les langues humaines.
Car si on peut (parfois, pas toujours) automatiquement les abréger pour en
réduire la précision (à condition de connaitre la langue dans laquelle ces
libellés sont écrits, ce qui n'est pas le cas de name=* mais peut l'être
pour name:fr=*), le contraire est totalement impossible sans se tromper,
toutes les heuristiques pour le faire ne sont QUE des heuristiques et vont
se tromper. Les moteurs de rendus évitent de telles approximations, et ne
vont tout bonnement pas préciser les choses, mais s'arrangeront pour
afficher au mieux les précisions et auront le droit alors de supprimer des
éléments et d'abréger, ou supprimer des différences de casse (mais on peut
aussi les guider pour qu'ils le fassent correctement dans le cas des
abréviations et des préfixes ou suffixes génériques, avec des attributs
techniques à part, ou quand la langue n'est pas précisée et que ce n'est
qu'une langue "par défaut", par exemple avec short_name=* ou
short_name:fr=* pour une abréviation n'ayant de sens qu'en français).
Le 29 novembre 2012 11:15, Mikaël Cordon <mikael.cor...@gmail.com> a écrit :
> >Oui cela pourrait être une bonne façon d'entrer les données dans la base,
> le "/" serait alors un séparateur de liste et " - " représenterait l'union.
> >Ensuite libre au moteur de rendu d'afficher ça de la bonne manière.
>
> Attention, le caractère « / » a sa propre signification. Et pour les
> cartographieurs qui reproduisent scrupuleusement les panneaux, « / » a pour
> signification dans des version abrégées de « sur ». Exemple : « Argenton /
> Creuse » ou « Argenton s/ Creuse », signifiant « Argenton sur Creuse » ;
> qui deviendrait alors « Argenton — Creuse » ayant une toute autre
> signification.
>
> Cordialement,
> --
> Mikaël Cordon, mickey86
>
>
> Le 29 novembre 2012 11:09, Mikaël Cordon <mikael.cor...@gmail.com> a
> écrit :
>
> Je n’ai pas l’habitude de rentrer dans des sujets chauds aussi tôt dans la
>> conversation… Mais comme je me sens un peu visé par le sujet — en effet,
>> j’utilise la typographie française aussi précisément que je peux — je me
>> permets d’intervenir en faveur du cadratin.
>>
>> >Et je ne vois pas le problème à avoir une typo première version avec les
>> caractères les plus accessibles à tous (-) et un maniaque derrière qui
>> remettra une couche avec le beau tiret cadratin.
>> +1, sachant que ce caractère n’est pas que « beau », mais surtout
>> sémantique (terme souvent repris dans la base OSM).
>>
>> De plus, lors d’un traitement automatique de la typographie — qui est
>> inévitable pour un rendu homogène —, j’imagine tout à fait que l’algorithme
>> gère les espaces multiples, ou les manques d’espaces ; et dans le cas «
>> Maisons-Alfort - Stade » il me semble bien plus compliqué de savoir si les
>> espaces sont trop nombreux ou qu’ils manquent ; alors qu’avec «
>> Maisons-Alfort — Stade » l’ambiguïté est levée et le traitement des espaces
>> est trivial.
>>
>> D’autre part, on a souvent entendu à propos de la base OSM qu’elle doit
>> être, d’une part uniforme, mais aussi préserver les spécificités ; et là,
>> il s’agit clairement d’une spécificité de la langue française (je ne
>> saurais dire si ce caractère a cours dans d’autres langues).
>>
>> Comme l’a justement fait remarqué Philippe, les balises name=* sont les
>> noms locaux/officiels (rayez la mention que vous voulez) des objets
>> auxquels ils sont attachés ; et en tant qu’objets français, ils se doivent
>> être écrits en français. Et même si ce ne sont pas des « codes », avec la
>> typographie qui va bien, leur décodage selon les règles de la langue locale
>> (ici le français) peut tout à fait être systématisé et automatique.
>>
>> 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 dit, je n’imposerai jamais à notre communauté française de
>> cartographieurs OSM ces subtilités ; mais de l’autre côté, je ne souhaite
>> pas me voir imposer la non utilisation de ces subtilités, qui, je le
>> rappelle, lèvent bon nombre d’ambiguïtés !
>>
>> Cordialement,
>> --
>> Mikaël Cordon, mickey86
>>
>>
>> Le 29 novembre 2012 09:56, JB <jb...@mailoo.org> a écrit :
>>
>> **
>>>
>>> Bof, est-ce qu'un néophyte de la typo aura plus tendance à écrire «
>>> Maisons-Alfort - Stade » que « Maisons-Alfort—Stade » ou
>>> « Maisons-Alfort-Stade » ? Il ne comprendra pas plus la différence entre «
>>> Maisons-Alfort - Stade » et « Maisons-Alfort-Stade » qu'entre «
>>> Maisons-Alfort - Stade » et « Maisons-Alfort—Stade ».
>>>
>>> Et je ne vois pas le problème à avoir une typo première version avec les
>>> caractères les plus accessibles à tous (-) et un maniaque derrière qui
>>> remettra une couche avec le beau tiret cadratin.
>>>
>>> On répète à qui veut l'entendre d'utiliser les bons tags et que c'est
>>> aux moteurs de rendus de s'adapter, je ne vois pas pourquoi on changerait
>>> cette règle quand on passe à la typographie.
>>>
>>> JB
>>>
>>>
>>>
>>> Le 29.11.2012 09:19, Vladimir Vyskocil a écrit :
>>>
>>> On 28 nov. 2012, at 19:20, Pieren <pier...@gmail.com> wrote:
>>>
>>> Si on veut distinguer deux entités, on peut aussi bien mettre des
>>> espaces avant et après le tiret pour lever toute ambiguité ("Maisons-Alfort
>>> - Stade" est assez clair).
>>>
>>> Ce compromis me semble tout à fait acceptable car il résout à la fois le
>>> problème sémantique et l'utilisation de caractères typographique
>>> "ésotériques" pour 99.5% des contributeurs.
>>>
>>> Vlad.
>>> _______________________________________________
>>> Talk-fr mailing
>>> listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
