Hello! This is just a proposal yet, see: osm.wiki/Proposed_features/Date_namespace
In my opinion it should rather be placed as prefix so that the tags can be sorted out chronologically right away, makes it way easier to see which tags are part of a certain period.

I just checked this changeset, no fields have been deleted, therefore not merged...

Cat-mouse game? Do you mean about the farmlands we talked about? I didn't merge any of "your" farmlands recently and if i did i would pay attention if it's the same culture. Also this changeset is from a month ago, i believe before we had our discussion. Sure, go ahead with the fences, but beware that some electrified fences consist of a simple cable attached to thin poles to make them easy for transportation, therefore are temporary too. Comparing between years will be helpful i guess, as i suggested.

+ tags corrected on Serbian Center

Sorry, forgot to reply. Yeah very possible that the tag was already flawed. Our conversation reminded me though that two years ago i was surprised that actually the directions had changed when i had dropped my mother at the airport. I had to go in the "Parking C / Kiss & Go" whereas before we could drive directly in front of the entrance. Anyway, the tagging on the ways for the authorised directions was inconsistent. I corrected it now and applied the tagging interpretation of access=no+specific=yes, as i said because when it's only authorised for a very specific non public mobility, i don't mind. Otherwise i don't agree because the rendering does not behave accordingly.

As far as i can remember i never had read in OSM's Wiki page for the key "Access" that this combination was accepted, it was only being discussed in the according page (I don't know for the mailing list). But I just checked now again and someone added it only recently on "14:08, 21 July 2020‎ MalgiK talk contribs‎ 32,073 bytes +39‎ →‎Transport mode restrictions: formating". He is new and has very little contributions though according his profile. So i would not trust his edit in the Wiki. Do you know if it has been discussed? We need to resolve the issue that the rendering does not correspond when someone uses access=no+specific=yes.

Hi! Your tagging network in airport is flawed! How do normal vehicles access now the drop & go area? Please correct as i don't know how/where is the correct direction for normal vehicles right now since you've hanged it.

Also normally the tagging combination of access=no or private + specific access mobility types is not correct because access=no/private defines access for all no matter what, hence why for the rendering map it is greyed out even if you add =yes for other mobilities. Proof: if you create a way with these tags high=path + access=no/private + foot=yes it will be greyed out anyway whereas for such highway a pedestrians would be the "least" possible type of mobility. But in the of the airport teh service way won't be used obvioulsy by any other kind of mobility/transportation.

+ tags added

Sorry, my bad! I really didn't expect it and shouldn't have changed it then. I reverted it back to previous state. No need for the photos, i believe you. Thank you for the reply!

Hi!
Unless there has been a new service road constructed, which i doubt very much because of the surrounding wall and the orchard, this way that you had plotted straight as a service road osm.org/way/830090011 is rather a track and ends with a small passage between walls. Can you confirm please? otherwise, please use the correct tag according the consensus in OSM's Wiki as this is very misleading.

+ new elements

Merci!

Bonjour! Tout ce chemin signalé comme étant un pont me semble être une erreur: osm.org/way/89207338

En effet, beaucoup de chemins forestiers ont été refaits l'année dernière à l'Ouest de Saeul. Si vous dites que le chemin à l'Ouest a également été refait, avant c'était clairement un grade3 et que vous suggérez que c'est un grade2, cela me semble tout à fait logique maintenant pour le chemin 891983109. Je l'ai changé en grade2 alors. Pour le chemin à l'extrême Est, j'y suis passé hier soir mais trop tard, il faisait trop sombre et pas moyen de s'arrêter direct sur le bord de la route donc j'ai juste jeté un coup d'oeil et il m'a semblé être un grade3 mais à confirmer plus sérieusement, je repasserai.

Merci pour toutes vos réponses!

+ new elements, tags corrected

Bonjour et bonne année! A propos de ce chemin osm.org/way/891983109 il est typé grade2 mais sur le coté Ouest il rejoint un grade3 et du coté Est un chemin avec pas mal d'herbe à la vue des photos de 2019 (donc grade4 je dirai) osm.org/way/528334397 . Cela me semble illogique car généralement les chemins les plus structurés d'un revêtement sont moins importants au fur et à mesure qu'on s'enfonce dans des zones naturelles. Avoir un portion plus revêtue au milieu entre 2 autres moins revêtues est très rare sauf cas exceptionnel pour un raison précise. Si on continue vers l'Est, on atteint tout de même une zone urbaine et donc je me dis qu'il est probable que le chemin continue en grade2 jusque là bas? Pourriez-vous m'en dire plus, s'il vous plait?

+ merged equal elements

J'ai mis à jour le périmètre de la forêt en question, je voulais dire ici sur la frontière: osm.org/node/1524319606

Bonjour! Bienvenu sur OSM et bonne nouvelle année!

Une suggestion pour vos contributions sur iD: faites attention où vous placez les nodes/lignes, car d'une façon où autre vous aviez superposé la ligne sur elle même de cet élément-ci osm.org/way/894013398 au niveau de la frontière et donc ça risque que les services tiers ne reconnaissent pas la structure et que l'élément ne soit pas rendu sur la carte. Si besoin vous pouvez détacher un élément d'une node qui est partagé avec d'autres éléments en le sélectionnant puis séléctionnez la node à détacher avec Shift+click et finalement bouton D pour détacher.

Vous aviez également transformé le heath en "faux MP" (sans polygone interne, ni d'autres éléments rejoint dans la relation donc inutile d'en faire un MP) avec seulement l'anneau externe en relation composé de plusieurs lignes avec la relation du dit "faux MP". C'est à éviter car ça prend plus de ressources pour les serveurs OSM et risque d'engendrer plus d'erreurs d'autres contributeurs qui ne prêteraient pas attention.

+ tags corrected

the rendering seems coming back