[OSM-talk-fr] Test panneaux de signalisation Osmose-Mapillary

[Frédéric Rodrigo]

J'ai trouvé un bug, ça signale a tord des maxheight/maxweight et des 
traffic_calming, la mise à jour devrait passer demain dans la journée.


Le 17/07/2017 à 08:42, François Lacombe a écrit :
> Hello,
>
> C'est une super initiative Frédéric
> Comme tu le soulignes, il faut encore que les positions des panneaux 
> soient consolidées avec les différentes prises de vues.
> Mapillary m'a dit qu'ils travaillent dessus. Ce n'est qu'une question 
> de patience
Il le font un peu déjà, mais c'est pas vraiment parfait ;-)

>
>
> Le 16 juillet 2017 à 23:03, marc marc <marc_marc_irc at hotmail.com 
> <mailto:marc_marc_irc at hotmail.com>> a écrit :
>
>     Cela rouvre le débat sur tager le panneau exactement là oü il est
>     (avec
>     l'imprécision gps d'autant plus criante) ou tager le panneau en
>     fonction
>     de son effet (sur le chemin concerné) afin de le rendre utilisable par
>     le routing (le routing ne cherche pas les panneaux situés à proximité)
>
>
> Même sur la ML internationale il n'y a plus trop de doutes : il faut 
> taguer les deux.
> Le panneau en lui-même parce que c'est un objet visible et d'intérêt, 
> ne serait-ce que pour savoir que l'espace est occupé
> Et ensuite l'effet sur les routes/voies concernées, parce qu'on est 
> difficilement capable de déduire l'effet d'un panneau avec sa simple 
> position.
C'est aussi aussi une idée que j'avais, signaler les panneaux manquants.
Puis une analyse qui vérifie la cohérence interne à OSM entre panneaux 
et les effets de ces panneaux.
Mais je pense que c'est un peu overkill pour l'instant.

>
>     est-ce que les tag source ne gagnerait pas être sur le changeset ?
>     c'était un peu l'ancienne méthode de mettre la source de la première
>     modif sur l'objet et ensuite elle y reste même quand la modif
>     suivante a
>     une autre source
>
>
> +1 sur le changeset
Je sais. Mais c'est expérimental. J'ai fait au plus simple en 
réutilisant ce qui est déjà fait pour l'OpenData. Du coup le code 
supplémentaire pour faire ça ridiculement petit vu ce que ça fait.
Pour les curieux (attention, il n'ya beaucoup de code mais c'est ce qui 
se fait de plus compliqué dans Osmose):
https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merge_traffic_signs.py
https://github.com/osm-fr/osmose-backend/blob/master/merge_data/mapillary-traffic-signs.mapping.csv

Frédéric.