Cela montre que la détection osmose a vraiment du sens, je vous propose de demander à scinder les erreurs avec des messages différents pour lieux guider les utilisateurs. Qu'en pensez vous ? Le 18 oct. 2014 23:39, "Matthias Dietrich" <[email protected]> a écrit :
> Je reprends également point par point. > > Je ne comprends pas groupe comme étant le tag principal, mais simplement > la "catégorie" en quelque sorte. D'ailleurs le lien ne pointe pas vers la > clé highway, mais sur une page listant tout ce qui concerne la voirie. > > Soit nous ne parlons pas de la même chose, soit tu extrapoles ce que dit > le wiki. Pour mountain_pass, le noeud doit certes se trouver sur un way > highway=*, mais le noeud en lui-même ne doit pas porter un quelconque > highway=*. C'est cette soi-disant erreur que rapporte Osmose. > > Pour traffic_sign, relis la partie qui explique comment le taguer sur un > noeud. > > *As a **separate* *node* > > Create a separate node beside the road at the position of the actual sign. > > Et si tu regardes le tableau en dessous dans le wiki, pour > traffic_sign=city_limit seul le cas d'un noeud est prévu. Cela n'aurait > aucun sens sur un way, à moins de micro-tagguer les dimensions du panneau > ... > > Regarde également dans le panneau de droite les "useful combinations". La > clé highway n'y est pas citée. > > Enfin, et j'arrêterai là, ces façons de tagguer les cols et les panneaux > d'agglomération existent depuis longtemps, c'est ce que je voulais dire en > citant les chiffres de taginfo. Taginfo reflète avant tout la pratique des > contributeurs. Avec parfois des incohérences certes, mais jusqu'à > aujourd'hui, on y apprend que personne n'a ajouté de tag highway=* à > mountain_pass ou à traffic_sign=city_limit. > Qu'on veuille les changer, pourquoi pas, mais cela doit passer par une > discussion sur tagging ou autres. Ce n'est pas à Osmose d'imposer une > nouvelle interprétation. > > Personnellement je me moque royalement de devoir ajouter du highway=* ou > pas à ces noeuds s'il y'a un consensus pour le faire, parce que certains > trouvent ça plus clair. Ce qui me dérange, c'est qu'Osmose rapporte comme > erreur ce qui est la pratique majoritaire, documentée et établie depuis > longtemps. > > Le 18 oct. 2014 22:44, "Jérôme Seigneuret" <[email protected]> a > écrit : > >> @Matthias Dietrich je vais juste reprendre point par point >> >> *Après vérification du wiki, il faudrait en effet que information=* soit >> accompagné de tourism=information. * >> >> En effet c'est précisé ici >> http://wiki.openstreetmap.org/wiki/FR:Key:information >> >> PS: quand dans la boite à droite c'est écrit G*roupe : ** c'est que le >> groupe est le tag principal il me semble >> >> *En revanche mountain_pass=yes ne nécessite rien d'autre. Pour golf=* le >> wiki ne dit pas qu'il doit être ajouté à sport=golf par exemple. * >> >> Ça c'est pas vrai! >> >> Premièrement, Pour *mountain_pass *c'est considéré comme attribut d'un >> highway donc il manque aussi un tag! La doc anglaise dit >> <http://wiki.openstreetmap.org/wiki/Map_Features>: >> *Applies to the "highest node" on a highway = >> motorway/secondary/footway/... (could be any appropriate "highway"):* >> Donc highway=* est indispensable >> >> Et en ce qui concerne traffic_sign=city_limit, là non plus il n'est pas >> précisé qu'il doit être ajouté à autre chose. En non, il ne doit pas être >> nécessairement sur du highway >> >> Humm Il me semble que la page dit que c'est un membre du groupe highway. >> Donc highway est indispensable avec highway=traffic_sign! C'est un manque >> du wiki est j'espère que ce sera traité comme tel. >> >> mais à l'emplacement physique du panneau, qui est en général à côté de la >> voirie, comme indiqué dans le wiki. >> >> oui est non : *It is possible to use a node which is part of a way, or >> to create a separate node beside the road. Both methods are used in >> practice.* >> >> Taginfo indique également qu'aucun des quelque 100 000 nœuds >> traffic_sign=city_limit n'est actuellement accompagné de highway=*. >> >> Pour moi c'est une connerie du au fait que ce ne soit pas précisé dans le >> wiki! traffic_sign peut être correspondre à tout les élèments ou partie de >> voirie. dans un way dans tous les cas tu auras un highway. Donc dans les >> noeud isolé pour être cohérent il faut ajouter >> >> >> *Donc en dehors de information=*, Osmose ne devrait pas lever d'erreurs >> sur ces objets (en tout cas pas si on s'en tient aux usages actuels). * >> >> *Taginfo indique également qu'aucun des quelque 100 000 nœuds >> traffic_sign=city_limit n'est actuellement accompagné de highway=*.* >> >> Cela peut aussi être du à un manque dans le wiki... Taginfo ne remonte >> que la manière dont c'est utilisé et pas les incohérence sur l'utilisation. >> Si c'est pas claire tout le monde fera n'importe quoi et on le voit sur >> d'autre tags. Si j'en corrige 75000 highway=traffic_sign , >> considèrera-t-on que c'est ça qu'il faut faire? >> Bref Taginfo permet de savoir combien on a de saisie ou de comparer des >> mode de saisie mais pas de dire que c'est bien ou non. Au moins on sait que >> 100000 noeud seront à revoir... >> >> traffic_sign est une restriction doit-on ajouter des tags restriction >> pour avoir une catégorie principale... ou complètement ignoré les >> restrictions du test... >> >> Voir: >> http://wiki.openstreetmap.org/wiki/Map_Features >> >> >> >> >> Le 18 octobre 2014 20:00, Matthias Dietrich <[email protected]> a >> écrit : >> >>> Après vérification du wiki, il faudrait en effet que information=* soit >>> accompagné de tourism=information. >>> >>> En revanche mountain_pass=yes ne nécessite rien d'autre. Pour golf=* le >>> wiki ne dit pas qu'il doit être ajouté à sport=golf par exemple. >>> >>> Et en ce qui concerne traffic_sign=city_limit, là non plus il n'est pas >>> précisé qu'il doit être ajouté à autre chose. En non, il ne doit pas être >>> nécessairement sur du highway, mais à l'emplacement physique du panneau, >>> qui est en général à côté de la voirie, comme indiqué dans le wiki. Taginfo >>> indique également qu'aucun des quelque 100 000 nœuds >>> traffic_sign=city_limit n'est actuellement accompagné de highway=*. >>> Donc en dehors de information=*, Osmose ne devrait pas lever d'erreurs >>> sur ces objets (en tout cas pas si on s'en tient aux usages actuels). >>> >>> Le 18 octobre 2014 15:22, Jérôme Seigneuret <[email protected]> >>> a écrit : >>> >>> L'ensemble de ces clé doivent normalement être membre des clés >>>> précédemment cités (explicite ou implicite) >>>> >>>> *traffic_sign *n'est pas cité dans la page principale mais *traffic_signal >>>> *oui >>>> ne doit t'on pas mettre : >>>> *highway=traffic_sign *en plus? >>>> >>>> même cas pour *information*: >>>> *highway=information* >>>> *tourism=information* >>>> *etc...* >>>> >>>> Je pense que rajouter n'est pas forcément juste. Sinon il faut >>>> considérer qu'il y a des nouveau types principaux. >>>> Si ce sont des type implicites il faut pouvoir vérifier leurs >>>> correspondance avec l'une des clés principales. >>>> >>>> Exemple pour les trafic_sign il faut forcément qu'ils soit sur du >>>> highway parcontre un panneau d'information est quand à lui positionné sur >>>> des parcelles privé et non sur la voirie. >>>> >>>> A la base le modèle est en XML. N'y a t-il pas un schéma XSD ou JSON? >>>> >>>> en json on peut analyser le contenu avec un correspondance à un schema >>>> https://pypi.python.org/pypi/jsonschema >>>> >>>> On pourra aussi proposer via ça des listes de balises connexes >>>> manquantes >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Le 18 octobre 2014 14:32, Matthias Dietrich <[email protected]> a >>>> écrit : >>>> >>>> Il n'y a pas que les pistes de ski qui sont touchées par cette nouvelle >>>>> analyse, on trouve également des erreurs sur : >>>>> - les cols (mountain_pass=yes + name=*) >>>>> - les panneaux d'entrée d'agglomération (traffic_sign=city_limite + >>>>> name=*) >>>>> - les panneaux d'information (information=* + name=*) >>>>> - les éléments d'un terrain de golf (golf=* + name=*) >>>>> >>>>> Ceci est juste le retour d'un rapide tour d'horizon autour de chez >>>>> moi. Il doit y avoir plein d'autres cas. >>>>> >>>>> Bref, la liste des "tag principaux" est potentiellement bien plus >>>>> longue que celle supportée actuellement. >>>>> >>>>> Le 18 octobre 2014 14:07, Yves Pratter <[email protected]> a >>>>> écrit : >>>>> >>>>>> >>>>>> Le 18 oct. 2014 à 13:44, Jérôme Seigneuret <[email protected]> >>>>>> a écrit : >>>>>> >>>>>> L'erreur devrait donc être : "Objet nommé dont un tag indispensable >>>>>> n'existe pas » >>>>>> >>>>>> ou « tag manquant pour un objet nommé » >>>>>> >>>>>> Osmose considère que seul les objets avec les attributs suivants >>>>>> peuvent être nommés : >>>>>> >>>>>> - aerialway >>>>>> - aeroway >>>>>> - amenity >>>>>> - barrier >>>>>> - boundary >>>>>> - building >>>>>> - craft >>>>>> - emergency >>>>>> - geological >>>>>> - highway >>>>>> - historic >>>>>> - landuse >>>>>> - leisure >>>>>> - man_made >>>>>> - military >>>>>> - natural >>>>>> - office >>>>>> - place >>>>>> - power >>>>>> - public_transport >>>>>> - railway >>>>>> - route >>>>>> - shop >>>>>> - sport >>>>>> - tourism >>>>>> - waterway >>>>>> >>>>>> Pour les pistes de ski, il y a l’attribut *piste:type* mais pas >>>>>> *type*. >>>>>> >>>>>> Il faut donc rajouter piste:type à la liste… ou rajouter un mécanisme >>>>>> qui recherche les attributs se terminant par *:type. >>>>>> >>>>>> Le 18 oct. 2014 à 11:30, Yves Pratter <[email protected]> a >>>>>> écrit : >>>>>> >>>>>> J’essai de comprendre le code mais ce n’est pas très clair (en >>>>>> comparaison à d’autres erreurs): >>>>>> Donc si l’objet à l’attribut « name » et que son parent ne serait pas >>>>>> nommé ?? (je ne pige pas la seconde condition) >>>>>> >>>>>> if tags.get("name") and len(key_set & self.name_parent) == 0: err. >>>>>> append((21101, 1, {})) >>>>>> >>>>>> >>>>>> En fait, l’erreur est produite si un objet OSM à un attribut *name* et >>>>>> qu’il n’a aucun des attributs suivants : *type*, *aerialway*… >>>>>> >>>>>> Donc, le message pourrait être *« tag manquant pour un objet >>>>>> nommé » * >>>>>> >>>>>> — >>>>>> Yves >>>>>> >>>>>> *key_set *est la liste des attributs de l’objet. >>>>>> *self.name_parent* est la liste des objets/attributs qui peuvent >>>>>> être nommé >>>>>> self.name_parent = set(('type', 'aerialway', 'aeroway', 'amenity', >>>>>> 'barrier', 'boundary', 'building', 'craft', 'emergency', 'geological' >>>>>> , 'highway', 'historic', 'landuse', 'leisure', 'man_made', 'military' >>>>>> , 'natural', 'office', 'place', 'power', 'public_transport', >>>>>> 'railway', 'route', 'shop', 'sport', 'tourism', 'waterway')) >>>>>> >>>>>> len(key_set & self.name_parent) == 0 >>>>>> indique l’appartenance cf. A⊆B cf. Utilisation avancée des listes >>>>>> en Python >>>>>> <http://fr.openclassrooms.com/informatique/cours/utilisation-avancee-des-listes-en-python> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-fr mailing list >>>>>> [email protected] >>>>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk-fr mailing list >>>>> [email protected] >>>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Talk-fr mailing list >>>> [email protected] >>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>> >>>> >>> >>> _______________________________________________ >>> Talk-fr mailing list >>> [email protected] >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >>> >> >> _______________________________________________ >> Talk-fr mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/talk-fr >> >> > _______________________________________________ > Talk-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
