When i said: access=* is applied to all transportation, period. i should have added, no excpetions otherwise this would imply adding extra rules for the engines i talked about.

There should only be one method though since we should ease the contribution process as much as possible via consensus, also for any kind of third part service whether it's map rendering, routing or searching data... Otherwise this means creating several kinds of engines, this would be unmanageable. In extra some people already misuse the tagging, so if we add interpretations we won't have any solid basis.

Yeah what you suggest on your second paragraph, that's the correct way to use the access tags. access=* is applied to all transportation, period.

MalgiK Wiki edits here: osm.wiki/Key:access see the examples in "Transport mode restrictions" section.

LOL have a good day

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