FR talk:Robot de traitement

Je ne suis pas assez expérimenté pour voir les implications des changements de true ou false. Pour la question des mots intérieurs aux noms de rue et toponymes, j'ai peur que la liste des soit très difficile à établir parce que le français académique, malgré la légende scolaire, n'est pas tout seul et n'a pas réussi à purifier linguistiquement l'hexagone.
Il y a les innombrables variétés de français d'oil et d'oc, plus l'alsacien, le corse, le breton, le catalan, le flamand, le francique, et j'en oublie sans doute, qui sont employés dans les noms de rue. A la liste déjà donnée, il faut ajouter pour le français, aux et ès (ès = dans les).
Pour le breton, les articles ar, al, an, er, el, en, les prépositions ar et war.
Ne parlons pas des langues comme l'alsacien où les mots vides seraient constitués d'une lettre.
Tout cela n'est peut-être pas insoluble, mais nécessiterait l'avis de spécialistes assez pointus de chaque région ou micro-région.
Mais il faut surtout considérer le cas ou un mot français serait homonyme d'un mot à ne pas modifier.
Il est donc préférable que le robot ne traite qu'une liste limitative de mots hyperfréquents, celle de Sylvain, et donc exclure aux et ès pourtant très répandus dans l'Ouest, pour éliminer quasiment tout risque de collision avec un usage local.. --Ch. Rogel 21:44, 8 December 2008 (UTC)

C'est une très bonne remarque, je tenterais d'en tenir compte. Sletuffe 23:12, 8 December 2008 (UTC)

API 0.6

Elle est arrivée.

• il est impossible de modifier un objet si une version plus récente se trouve dans la base, ça évite que les données venant du planet de la veille ne surcharge des données modifiées dans la journée (optimistic locking)
• l'introduction des "sessions de changement" (changeset) permet de voir facilement tous les objets modifiés lors d'une session (diffset). Mais il n'y a pas de retour en arrière (rollback).

Se limiter à l'hexagone

Et à l'hexagone uniquement avec un multipolygone très précis. Je trouverais anormal qu'on impose nos règles sur les ref=* chez nos voisins belges, allemands, suisses, luxembourgeois, espagnols, italiens ou aux îles anglo-normandes. C'est pourquoi le mieux serait d'utiliser une relation liant tous les ways qui fixent la frontière (la relation existe mais il faut encore fermer la boucle).

Je n'ai pas la prétention de tout corriger, je pensais donc utiliser un polygone très conservatif et dire "tant pis pour les bordures" dans un premier temps du moins Sletuffe 23:12, 8 December 2008 (UTC)

Ca serait mieux d'avoir des règles de correction automatique qui s'appliquent à tout l'hexagone + les îles françaises. Sinon on perd l'argument du "données cohérentes".

Se limiter à des changements simples, indiscutables

Pour:

• trim spaces : supprimer les espaces inutiles dans les clés et/ou valeur (espaces en début et/ou en fin de chaîne)
• mettre l'espace dans les ref, à condition que le premier caractère soit un "D" ou un "N" ou un "C" et que le deuxième caractère soit un chiffre. Éventuellement prévoir le cas "RN6" ou "R.N6" ou "R.N.6" à renommer en "N6" ou "RD21" en "D21". Tous les autres cas sont soit des erreurs, soit des fautes de frappes, soit des indications. Dans tous les cas, ça nécessite l'intervention d'un humain. Prévoir les cas plus complexes comme "D2b" en "D 2b" ou "D 3III". Et quid des ref composés "N 6; D 5" ? Est-ce possible en France ? Je pense que non mais que faire s'il y a un ";" ? Quid des old_ref ?

Pour l'instant je ne pensais pas toucher aux ref, car le sujet, n'a jamais, il me semble, vraiment été tranché sur l'espace Sletuffe 23:12, 8 December 2008 (UTC)

Si le robot touche aux refs, laisser un espace entre la lettre et le chiffre : D 998, N 9, E 4 Gerhard

• corriger les mauvaises orthographes sur les clés les plus connues. Pour cela, il faudra construire une liste des mauvaises orthographes les plus connues manuellement ou automatiquement.

Je pensais le faire, communautairement et manuellement sur les 30 clefs les plus courantes Sletuffe 23:12, 8 December 2008 (UTC)

• Dans les name=*, mettre la 1ere lettre en majuscule : d'accord mais uniquement sur une liste de mots prédéfinis : exemple "rue" devient "Rue", "Avenue", "Boulevard", etc... Ne pas toucher les name:de, name:en, etc qui sont en langue étrangère. Par contre, visiter les name:left ou left:name. Quid des autres tags name comme loc_name, nat_name, reg_name, old_name, alt_name ?

Très bonne idée de ne toucher que à une liste blanche, plutôt que de faire une liste noire Sletuffe 23:12, 8 December 2008 (UTC)

Pourtant, la première lettre du "name" semble devoir être une majuscule, sinon les renderers n'affichent rien du tout. Ça a l'air d'être une convention internationale des moteurs de rendu, et tant pis pour nos habitudes locales :-( Gerhard

Remplacer les underscore (s'il en subsistent) par un espace.

Je pense qu'on puisse mettre en majuscule la première lettre qui suit un apostrophe, mais pas la lettre devant l'apostrophe, sauf si elle est le premier élément du string (début du terme).Gerhard

Contre:

• Dans les name=*, ne pas fixer de règle systématique pour tous les mots en majuscule: avec "d'aboville" on peut avoir "D'aboville" ou "d'Aboville" ou "L'alma"/"l'Alma" (c'est des exemples au hasard sans doute faux mais juste pour montrer les difficultés). Il y a trop d'exceptions en langue française (même pour les noms des communes, voir la doc de l'IGN sur la toponymie pour avoir une idée de toutes les exceptions à la règle).

Gerhard : Il me semble pourtant que ce soit gérable, puisqu'il s'agit de noms propres : Rue de l'Alma, L'Alma, et Alma.

Et mettre "lez", "lèz", "les" et "lès" dans la liste des exceptions, en tant que mot de liaison ça reste en minuscules : Nissan-lez-Esérunes, Saint-Cyr lès Annonay.

Mais ça fait dilemme avec Castelnau-le-Lez :-( , le Lez ici étant un ruis. Même dilemme pour le "y" : en certaines régions, c'est le "et" entre noms, et dans le Cher c'est un ruisseau au nom d'Y, lieudit Pondy ou Pont d'Y.

Ne pas toucher aux traits d'union, c'est quasi ingérable : Nissan-lez-Esérunes, mais Saint-Cyr lès Annonay et Notre-Dame du Port (? sais plus...), mais aussi St Pierre-de-la-Fage.

Pas toucher aux abréviations, pas transformer les "St" en "Saint"-quelque-chose, on risque de se trouver avec des Sainte-Epuration, Saint-Transfo ou Sainte-Balnéaire (voir cartes ign). Ça devient compliqué... :-( Gerhard

Ni pour, ni contre:

• les yes/true/1 : franchement, j'ai toujours pensé que ça n'était pas un problème. Tous les logiciels qui traitent les données OSM supportent les différentes définitions. Mettre tout à "yes/no" n'apporte rien si ce n'est le risque que quelqu'un dise un jour que seul "yes/no" doit être accepté. Sinon je suis d'accord qu'il faut aussi faire attention au -1 du oneway.

J'ai le nez dans les styles mapnik depuis quelque temps et c'est une perte d'énergie que je fais à posteriori alors que je pourrais en faire profiter tout le monde.

Au niveau traitement, ce sont des tout petits coût supplémentaires, mais c'est quand même un coût.

je ne vois pas le problème à ce qu'un jour ce soit les seuls acceptés, highway=autoroute n'est pas supporté, personne ne s'en plein. Mais par contre, il faut laisser du temps au temps, je suis d'accord. Sletuffe 23:12, 8 December 2008 (UTC)

J'en oublie encore sans doute mais c'est un wiki. Je reviendrais si nécessaire. -- Pieren 22:29, 8 December 2008 (UTC)

oneway=-1

En ce qui concerne le oneway=-1, je continue à penser que, comme la page de description l'indique, il ne faut utiliser le -1 que "lorsque le sens de la route ne peut pas être changé" ce qui, en l'occurence, ne m'est jamais arrivé. (Je veux bien une explication de pourquoi on ne pourrait pas inverser l'ordre des nd pour la mettre dans le bon sens et avoir oneway=yes.) Mat 22:57, 8 December 2008 (UTC)

ça ne m'est jamais arrivé non plus, mais j'avais vu passer une discussion d'un cas spécial ou c'était utile, un truc en rapport avec une rue à sens unique pour un véhicule X et double sens pour un véhicule Y :

genre oneway=yes + velo:oneway=-1 (ou un truc du style).

la page oneway dit "c'est possible" je ne prendrais pas le risque d'aller à l'encontre Sletuffe 23:14, 8 December 2008 (UTC)

Il me semble que oneway-1 n'ait un sens, que si la direction des ways est couplée à un sens de rotation nécessaire pour indiquer de quel côté se trouve la surface concernée, comme c'est le cas dans certains sig (conventions comme par exemple, la "surface concernée", lac, forêt ou autre, se trouvent à gauche du way tracé...). Il me semble, qu'osm se soit affranchi de cette contrainte par les tags area, left et right (sauf peut-être pour les lignes côtières). A condition de tenir compte des tags côtiers, et inverser les left/right, il devrait être possible de nettoyer un bon nombre de oneway-1 inutiles. Gerhard