Occurrences of the key direction=forward (or backward) were added on traffic lights at street intersections. According to the wiki, one must use the forward and backward directions only on nodes which are part of exactly one way (which was not the case).

direction=*

Point de vue intéressant, cependant cette piste n’existe plus sur le terrain. La ville de Sherbrooke propose un tracé alternatif qui assure la continuité du réseau. J’associerai donc les trois relations avec le tracé alternatif proposé par la Ville, en mentionnant qu’il s’agit d’une situation temporaire.

Oups, premier lieu bonjour ! -)

L’image n’est pas convaincante. As-tu été sur le terrain pour localiser le nouveau tracé de la piste ? De plus, le site de la ville de Sherbrooke indique que ce tronçon est bel et bien fermé… https://cartes.ville.sherbrooke.qc.ca/pistescyclables/

Mettons d’abord un peu de contexte. C’est ennuyeux, mais c’est un problème connu lié à l’import du produit Canvec. Des discussions ont été tenues (Talk-ca, OSM Wiki) au printemps 2010 pour choisir un modèle géométrique approprié à l’import de Canvec dans OSM. Il faut noter qu’à l’époque, il n’y avait pas de consensus sur le modèle de données souhaité dans OSM. Le résultat des discussions a été documenté à l’époque dans le Wiki [1].

La réponse simple à la question est : non, il n’existe actuellement pas de moyens de corriger ça en masse.
La réponse compliquée est que ça serait possible de corriger la plupart des cas de façon automatisés (bot). Si un polygone (1) natural=water est dupliqué avec la composante sans tags de type «inner ring» (2) d’un multipolygone natural=wood, alors cette composante (2) peut prendre le tag natural=water, et le polygone natural=water (1) peut alors être détruit.

J’aurai peut-être éventuellement le temps de regarder ça, mais sans garantie :-)

[1] osm.wiki/CanVec:_Geometric_Model

I do not understand why you changed the wooded area (surronding the commercial area) from a multipolygon to a standard way, duplicating all the nodes. The multipolygon was checked with JOSM tools before upload.

Bonjour Joël, tu as utilisé les tags access=no et bicycle=yes pour corriger l'accès aux sentiers du Mont Bellevue. Je crois préférable de remplacer access=no par foot=no (ça me semble plus simple et explicite). Qu'en penses-tu?

I see that you are editing features I updates over the last days. What are the problems with these edits, considering you are doing Quality Control over landuse?

Esri world imagery I use is much more recent and accurate than Bing one. Please discuss dataset before removing works of others .

He, I am editing Sherbrooke area and you are deleting/symplifing my edits as I am working on it. Stop it.

Areas ring not closed?
Six years ago I mapped all commercial areas around boulevard Bourque from Sherbrooke to Magog, mostly using multipolygon relations. According to this changeset history, you seem to have deleted about everything I did. Any explanation?

Pas de problème, c’est possible qu’un des deux tronçons de route que j’avais importé ait été détruit avant ton intervention. Il m’est arrivé souvent de voir de mes données détruites (plutôt que modifiées). Je vérifie maintenant. Merci et bonne cartographie :-)

Curieux, J'ai importé tout le tracé du prolongement de l'autoroute 410 le 2011-08-11 (gracieuseté du Ministère des Transports du Québec) mais il semble que mes données ont été détruire et remplacé par tes données. As-tu une explication?

Good! That is as expected.

I am mapping in the Eastern Townships, Sherbrooke is my home port, and I have been using OSMand on a weekly basis for more than 5 years.
I want to be understood. I don’t want to go hunting for the foot paths you added. What I am saying is that I map what exists on the ground (see first line of Map Feature definition [1]) and, if an object does not/no longer exist on the ground, the rule is to eliminate the object. That’s what we would expect from any contributors, isn’t it?
If some of the foot paths you add are placed for the sole purpose of routing, why not use a specific tag/value for that purpose? For example, highway=routing with an explanatory note on this segment. The segment will not appear on the map will be less visible in edit mode (ID, JOSM) and it will be available for you in the database.
This is not elegant but could help you until your application run without these artefacts
[1] osm.wiki/Map_Features

Even Telenav uses highway values that are not valid in their application (highway=undefined; highway=unknown). see osm.wiki/OSM_tags_for_routing/Telenav

There are two things here. The needs of an application and the mapping of pathways. I have no problem with mapping pathways as long as they exist. What I don't like is having fictitious pathways that have been clearly created to alleviate the problems of an algorithm. This is what sparked my interest in some of the pathways you have created. I will keep all the pathways that exist on the ground (I know the area very well) but I could remove those that do not exist when I meet them.

What was your intent when you added a lot of footways that did not exist linking to different types of highways???

Local knowledge required ! There is no railway crossing at 45.3939258, -71.9130619. The cycleway pass under the bridge :-)

Désolé mais je ne comprends pas. Y a-t-il eu un programme (bot) qui a créer les problèmes identifiés?

Il semble y avoir un problème avec ce changeset. Des composantes externes (outer rings) de multipolygones végétation (wood) semblent avoir été créés par un programme (bot) à plusieurs kilomètres du polygone principal de la relation à laquelle ils appartiennent. Voir way/187624619 et la relation/544367.