This was done in rawedit (which still offers no way to add edit comments); this added more evident dictinctions in names, between land areas and admin boundaries

this was done in rawedit (which offers no way to submit edit comment); this added distinctions in names for land areas compared to admin boundaries

Note that Frederik removed "description" and "name" (also "phone" and "email" or contact info) added to address nodes only (housenumbers with street names) that were actually not qualified with actual POI classification (e.g. "shop=*" or "amenity=*" or "office=*").
Some removals are then legit but these names and contact addresse had no use if there was no correct POI qualification.

Note also that there's N-to-N relations between POIs and addresses, also N-to-N between addresses to buildings, and N-to-N between POIs and buildings.

Addresses also have N-to-N relations with landowerships or cadastral parcels (which we actually don't map directly, most parcel ivisions are historic and too many objects and land properties are built on spans of multiple cadastral parcels).

This means that POIs (with correct shop/amenity/office/... tagging) should be tagged as separate node objects (or area objects) with their own contact fields ( including their address which may not match exactly the geographical address) and should never be made on address nodes or buildings, but only on separate nodes (or possibly on landuse areas, for example a school or a retail area including its buildings/parkings/surrounding gardens and private service driveways or storage areas)

Most POIs accessible to the public (or visible from the public domain, or advertized on the ground) should be distinct geolocalized nodes, with name=* (and brand info, operator...), plus contact info (mail, web...),, opening hours...). Keeping them distinct will avoid many later problems. and we can enforce the classification (so that, for example, all shop=* may be removed from a rendered map independantly of names and brands)

Note: this bug was signaled but unfortunately rejected/"resolved" agressively by only one iD developer as invalid, even if it is easily reproduced and not resolved at all.

Please avoid interfering on blocks taken by someoneelse in the HOT TM. Also please cleanup the hashtags when you switch from one project to another (Tanzania here or projects 3389 and 3530 are irrelevant): these old hashtags come from a past edit in iD they cumulate until you remove them, keep only thoese in the default update comment or add those you really want (This is a bug in iD)

Tu t'es complètement trompé en prenant l'imagerie Bing et non les images hautes résolution qui montrent clairement qu'il y a bien des murs et non des chemins, et même des portes !

such comment in not useful if you don't specify "where"

Point 1 is false. You can't cross the solid line evenwhen exiting a private property. The one way must still be respected and you'll have to go to the next crossing where this will be possible.

Point 2 is not relevant at all. The center line is not better than measuring on the center of any lane, and the effect disappears rapidly with the various curves to the left or right. The variation is also affected by the precision of polygonal lines used to approximate the real curves. Any total length distance will not be measured to the centimetric precision where this has a significant effect only on short distances, but where the center line is not relevant at all and the actual lane will be much more precise ! You can have better precision just by adjusting the polygonal lines to better appromixate the curves, but most ways still have too sharp segments zigzagging between the leftside and right side of the roads, including over sidewalk and their exact length is not represented.
Here you'll note that I took the time to imporve the curves to reduce this effect and this cannot be worse than the previous approximation of the "centerline"

But the presence of trafic islands and other separators cannot be ignored: it even helps drivers to be notified earlier of when to take the correct lane: they'll be notified sooner if they know that lanes are separated long before the actual crossing and this is expected. So I don't see the point of where this could really cause any problem to separate these lanes early where they are effectively marked or barred.

Emergency situations may as well take any ways in forbidden directions, could use footways, enter private areas and even pass through unpaved areas (gardens...)

I'd like to know what are the "issues created" that this does not solve, given that there is effectively a separation (and separators are themselves mapped, notably the traffic islands).

En l'occurance c'est bing qui a passé ses indications de date ici de 2016 (où la route n'était pas visible) à 2017 (où elle l'est devenue et parfaitement, comme une route neuve avec juste un peu de traces de poussières qui me semblait normal vu le chantier autour).
De toute façon j'ai marqué à nouveau cette route comme détruite (au lieu de la supprimer), afin de conserver cette indication

Exceptions to this is extremely rare in France.

where, I've looked at all of them individually, may be there's some invisible signs that could say the opposite

Difficile de trouver les dates cohérentes alors dans les imageries qu'on nous donne. visiblement nos fournisseurs s'arrangent pour que les photos qu'ils nous proposent correspondent aux données qu'ils ont dans leurs cartes, ou utilisent ça comme des "Easter Eggs".
Cependant mettre "source=knwledge" n'est pas la solution, il faut dans ce cas faire un relevé avec une autre source plus vérifiable. L'image imgur est plus raisonnable comme source, mais au moins elle montre la trace encore de cette route "temporaire" (et l'effacer complètement ne peut pas aider, il vudrait mieux utiliser un préfixe "destroyed:" et un end_date=* pour dater l'évènement du constat. Sur le site de Rennes2030 (dont les données sont de 2016), cette route y est bien, et il n'y a rien indiquant que c'était temporaire ou que des travaux étaient prévus à terme pour la détruire. On n'a qu'une date estimée montrant qu'elle ne serait plus là à terme en... 2030 (mais rien de précisé sur cette date, la carte montrant encore seulement un projet et aucun travaux "en cours").
Les PDF relatifs à l'aménagement de la zone ne donnent aucun calendrier et ne parlent jamais d'une route temporaire pour les travaux. Le cadastre non plus n'est d'aucun secours.

Bref je conteste totalement tes suppresssions, ta source=knowledge est très contestable et fait référence à l'ancienne route qui n'était pas là (elle passait plus à l'ouest) où tu as supprimé le nouveau chemin tracé qui reliait la rue Jean Marin en passant au nord du parking vers l'avenue des Monts d'Arrée. La route semble bien neuve, en parfait état, et pas du tout en cours de destruction ou en mauvais état

tu as viré un chemin de la coulée verte selon ta "connaissance" mais il est bien là (et parfaitement tracé, pas en cours de destruction) sur les dernières images de mai 2017...

En France, on commente en français...
les valeurs comme plazza sont toujours en discussion. Mais ce qui était avant c'est un morceau de rue (highway)=* fantome que j'ai remplacé par une surface. Il y a eu diverses tentatives pour désigner ces lieux avec place=* ou highway=*. Et pour l'instant il n'y a aucune formalisation stable, ça change régulièrement tant pour la clé que la valeur.
Mais je ne pouvais pas conserver le highway=residential sur un segment parasite.

C'est pas grave j'ai pris ta suggestion pour les 4 ways

No typo, this is documented and part of several presets in editors.
What you sugest would be just equivalent if you had used service=alley; but alley is suitable where it is when driveway is not !

Merci encore; cela ne règle pas le problème des primary sur les quais nord mais c'est plus convaincant en montrant ce qui est exactement autour !