To stimulate discussion, I have created a page [1] that will be updated daily (via this script [2]) to display the iNaturalist <> OSM mapping table.
The raw data is available (CSV, PY, HTML) in this repository [3].
I should point out that I used AI to help generate these scripts: a skilled human would no doubt have done a better job! But it works well!

[1] https://sylvain-m.github.io/divers/osm/inaturalist/

[2] https://github.com/sylvain-m/divers/blob/main/osm/inaturalist/inat_2_osm.py

[3] https://github.com/sylvain-m/divers/tree/main/osm/inaturalist

> ou can add the OSM Object ID as an observation field within iNat

This is for iNat > OSM link, and I'm agree, it's OK.

But for OSM > iNat link, there is actually no way.

> new iNat observations over time, do we then keep adding more and more iDs to ref:inaturalist.org

Yes, what's the matter with that ?

I think it's the same goal of key:panoramax or key:mapillary keys, for example.

> That should be done on the iNaturalist website.

This is already possible, thanks to the ‘OpenStreetMap (OSM)’ observation field : https://www.inaturalist.org/observation_fields/17260

But this remains invisible to OSM users.

One solution would have been to include a link based on this observation field (such as this one: https://www.inaturalist.org/observations?verifiable=any&place_id=any&field:OpenStreetMap%20(https://wiki.openstreetmap.org/wiki/Tag:OSM)=https:%2F%2Fwww.openstreetmap.org%2Fnode%2F9922802696) but this was considered too complex for a osm.wiki/Tag:url=, for example.

A link based on identifiers seems to me to be the most effective and simplest solution.

> A single relation between an OSM node and an iNaturalist page aggregating all observations of that OSM node would be a lot better. Would that be possible?

This is already possible using a list of IDs (as explained on the wiki page for the tag ref:inaturalist.org). Here is an example:
https://www.inaturalist.org/observations?verifiable=any&id=351263875,207552396,134700522,113752724,93114706,14675031

Here is another example that illustrates the value of adding this information:
https://www.inaturalist.org/observations/344757666

This link between the two platforms is a ‘win-win’ collaboration : users of both platforms will benefit from it. iNaturalist users can view other observations of the same tree, and OpenStreetMap users can view photos and identifications of a tree mapped on OSM.

I’d be happy to explain why adding this external reference seems useful for me.
The nodes associated with these iNaturalist identifiers are almost exclusively trees (natural=tree). These trees may be the subject of iNaturalist observations. In this case, adding the identifiers of these observations to the nodes allows a link to be made between these OSM objects and the observation records, which contain photos and a collaborative taxonomic identification (species/genus).
This adds value to OSM for all users/contributors interested in trees.
This interest has been confirmed on the French-speaking forum at this address: https://forum.openstreetmap.fr/t/inaturalist-osm-arbres

Actually, I didn’t consider it an ‘import’ because I didn’t add any new trees to OSM, and I only updated a single tag for just over a hundred nodes.
I did check the data thoroughly before adding it.
But I understand the caution @mcliquid : if this process needs to be reversed, I’m happy to discuss it in a dedicated forum thread (in French, as I’m less comfortable with English).
Regarding the use of the semicolon (there is not any dot), it seems to me that this is well suited to this case of multiple identifier values:
osm.wiki/Semi-colon_value_separator

You can get all iNaturalist observation with OSM field with this link :
https://www.inaturalist.org/observations?verifiable=any&place_id=any&field:OpenStreetMap%20(OSM)

Hi @mcliquid

This isn’t really a discussion about this import, but rather about the structure of the "ref:inaturalist.org" key :
https://forum.openstreetmap.fr/t/inaturalist-osm-arbres

This changeset is a manual import, but we could envisage this being done automatically via a bot in the future (iNaturalist has an API for this: https://api.inaturalist.org/v1/docs/ )

(je répond depuis mon compte perso, mais c'est bien la même personne)

Tu as raison pour "government=archive" (plutôt que archives), et je n'avais pas fait attention à cette subtilité de pluriel !
Ma question était surtout sur le choix de "amenity=archive" plutôt que "government=archive" :)

Pas de souci, c'est harmonisé maintenant !

Salut @zouloukk
Super d'avoir cartographié toutes ces haies dans le secteur.
Par contre, tu as utilisé le tag natural=tree_row, là où j'aurais plutôt utilisé barrier=hedge :
osm.wiki/FR:Tag:barrier%3Dhedge

Pour moi, "natural=tree_row" est utile pour les alignements d'abres qui ne forment pas de haies (souvent des peupliers ou des platanes par exemple), tandis que les haies ont généralement une strate arbustive dense et impénétrable, jouant le rôle de clôture (d'où la classification dans la catégorie des "barrier").
Mais c'est vrai que la distinction est un peu subjective.
Le sujet a été abordé dans ce fil de discussion :
https://forum.openstreetmap.fr/t/talus-haies-et-bocage
N'hésite pas à y participer si tu n'es pas de mon point de vue !
A+

Sorry, it was in this changeset, already commented :
changeset/125779486

Well done !
You created the node/9999999999 :
node/9999999999
😉

Hi @Chrisi_LE
I notice that most of the ‘natural=water’ features in this changeset are shifted about 100 metres east of the bodies of water visible on all available satellite images.
This is a shame, as they have very high geometric accuracy: could there have been a problem with the projection system at the time of import?

Example with this way :
way/600819564

Salut @Kalepom
Il est mentionné dans cette note [1] que la ligne de bus n'est plus à jour.
N'étant pas à l'aise avec ce type de relations, je me permets de te le signaler, si jamais tu as le temps de te pencher sur la question ?
Tu peux peut-être voir avec l'utilisateur @Mayenne Communaute [2] qui doit avoir le tracé exact ?
Merci à toi !

[1] note/4254678
[2] @Mayenne%20Communaute

Rebonjour @Wytzor
Pour info, on ne mets pas l'adresse complète (avec code postal et commune) sur un chemin. Je viens de le corriger, en le plaçant sur ce chemin :
way/1464323366
Et j'ai surtout ajouté le maraicher local ici :
node/13432236030
Et la ferme ici :
way/1464323367

Comme ça ils seront bien visibles sur la carte, et accessibles par les GPS

> Only a 4x4 car could try to drive on this road

C'est pourquoi elle était taguée "highway=track".

Avec "access=no", la route apparait inaccessible sur les rendus, même si tu as précisé "foot=yes".
Je me suis permis de remplacer "access=no" par "motor_vehicle=no"

Allô @David Crochet ?
Je me permets de te relancer au sujet de la relation relation/2667389
Visible ici par exemple :
https://ra.osmsurround.org/analyzeMap?relationId=2667389
J'hésite à la supprimer 🤔

Salut @ppda
Je suis tombé sur ce sentier :
way/601337310
Son tracé à l'air très improbable, et il n'a aucune visibilité, que ce soit sur Strava, sur les cartes IGN, ou sur la photo aérienne.
Es-tu certain de sa réalité terrain ?

Salut @Mikeecho747
Pour les poteaux électriques [1], je les aurais mis en "power=pole" plutôt qu'en "power=tower", non ?
(ce sont des "poteaux" plutôt que des "pylônes", il me semble ?)

[1] exemple : node/13265177685

Pas besoin de Python ici !
Le plus simple sera que je te montre en live la semaine prochaine 😀
D'ici là, dis moi de quelle espèce il s'agit, et je l'ajoute si tu veux.