> En fait, ce que Sylvain tente de résoudre avec son problème de oneway > et de carte particulière, c'est un problème général dans OSM qui est > que l'absence d'un tag ne garantie pas l'absence d'une propriété. C'est entre autre pour ça, mais c'est vachement bien résumé je reprendrais ta phrase à mon compte parfois : "l'absence d'un tag ne garantie pas l'absence d'une propriété"
> Pour le résoudre, il y a plusieurs approches: > - ceux qui veulent tout taguer pour être sûr que l'information est > bien fournie par ceux qui sont passés sur le terrain : > "oneway"=yes/no, "name" obligatoire, "maxspeed" obligatoire, > "bicycle"=yes/no (pour les pedestrian), "motorcar"=yes/no (pour les > track), "foot"=yes/no (pour les cycleway), etc... ça, c'est mon cas, sauf que ton "etc..." laisse penser qu'il en reste encore plein, et je ne suis pas sûr que ça soit le cas. Et on peut tout à fait lancer l'idée pour seulement 3 tags "important" et ce sera déjà un grand pas en avant selon moi. >Pour cela, ils proposent la création d'un tag qui réponde > aux outils de vérification : test_ignore=name_present, > [oneway_present]; C'est exactement sur cette proposition que je me suis basé pour faire mon internal= sauf que j'étends la logique de Frederik afin de créer une solution simple et assez universelle pour que les gens qui se foutent de cette "particularité interne" puisse facilement : dans JOSM (un jour) ne pas télécharger ces tags dans un export, ne pas les inclure dans un rendu, ne pas ralentir le rendu ( j'ai espoir, sinon que l'API 0.6 le supporte, au moins que la 0.7 puisse le proposer: ne pas télécharger certains tags ) mais en tout cas osm2pgsql et un DELETE FROM bidule WHERE tag LIKE "internal%" savent déjà le faire ;-) > - ceux qui considèrent que l'absence d'un tag ne garantiera jamais > l'absence de cette propriété, que le projet est basé sur le principe > des contributions volotaires et qu'il y aura toujours des gens dans le > futur pour ajouter une propriété si elle manque; > > Personellement, je trouve la 1ere approche trop lourde car elle > augmente considérablement le travail d'édition, la meilleure façon de > rebuter les nouveaux arrivants. Sauf si l'editeur le fait automatiquement pour certains tags et selon des "par défaut" et "par pays" ( je regrette d'ailleurs que personne n'ai donné suite sur ma page wiki pour discuter de ça ) [Country specific default values] ;-)))) > Faites confiance au principe du wiki qui > veut que si un oneway (ou un n'importe quelle autre propriété) manque > ou a changé, quelqu'un connaissant le terrain corrigera l'erreur tôt > ou tard. Hélas, je ne peux faire confiance à ce système car j'ai déjà perdu du temps que je n'aurais pas perdu sinon. Je ne remets pas en cause le fonctionnement wiki de osm, il me va très bien, mais, à la manière des bots sur wikipedia ou des groupes de "vérificateurs/modérateurs" de wikipedia je pense que osm a à y gagner ( en qualité ET en temps pour tout le monde) à lancer des projets complémentaires tels que : - maplint - noname layer - robot de contrôle - openstreet bugs - mon outils ;-) Et hélas, pour que ces outils fonctionnent bien, il leur faut une "base complémentaire de contrôle" que osm ne couvre pas - certains (openstreet bugs) propose leur propre base séparée - d'autres (le reste sauf moi) propose d'utiliser l'existant de la base osm sans la toucher pour le faire - et Moi : de trouver un compromis : utiliser la base osm existante plus lui adjoindre un/des tag de contrôle, présent(s) uniqument pour le contrôle -- Sylvain Letuffe [EMAIL PROTECTED] qui suis-je : http://slyserv.dyndns.org _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
