Replies: 5 comments 1 reply
-
Re source of truth: What about adding a field for that? or at least a field like "original"? |
Beta Was this translation helpful? Give feedback.
-
I need to examine Jacob Kalichman's code to comment. It's an odd repo - his "mirror" doesn't have the actual code, it just has tarballs, so i'll need to download. I still don't understand how Jacob's tool isn't just an "exodus tool" for leaving MO. Jacob has no recent obs on MO, since 2.26.23, and I wouldn't be surprised if his few obs since January 2022 were for the purpose of testing releases of the export tool. I understand there may be a use case for bulk export to iNat that does not involve no longer posting on MO, but I don't imagine that is anyone's use case except maybe Alan, who diligently posts both places. To do 1:1 exports or imports, I imagine a Stimulus controller could handle it asynchronously via an API. |
Beta Was this translation helpful? Give feedback.
-
Interesting point about "exodus tool".
I do the same thing as Alan. I haven't checked if there are others like him.
…On Sun, Feb 11, 2024 at 1:07 PM andrew nimmo ***@***.***> wrote:
I need to examine Jacob Kalichman's code to comment. It's an odd repo -
his "mirror" doesn't have the actual code, it just has tarballs, so i'll
need to download.
I still don't understand how Jacob's tool isn't just an "exodus tool" for
leaving MO. Jacob has no recent obs on MO, since 2.26.23. I understand
there may be a use case for bulk export to iNat that does not involve no
longer posting on MO, but I don't imagine that is anyone's use case except
maybe Alan, who diligently posts both places.
To do 1:1 exports or imports, I imagine a Stimulus controller could handle
it asynchronously via an API.
—
Reply to this email directly, view it on GitHub
<#1902 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALDFDHZ2QDTGFUBERQYE3YTEXJVAVCNFSM6AAAAABDDRSDA6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DIMZVGQ3TA>
.
You are receiving this because you commented.Message ID:
<MushroomObserver/mushroom-observer/repo-discussions/1902/comments/8435470
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
I talked with Jacob at NAMA. I think he wants to come back to MO, he just got frustrated with it (haven't we all?). I also think he got grumpy when we turned off access to a lot of pages to non-logged in users. I think if we make the site more efficient (like Nimmo is already doing) and we give him a good reason to come back he will. Especially if he can sync back and forth. Maybe I'm wrong. i really think the voucher slip QR code will make a difference especially if we can keep the site performance up. There are a lot of folks in the mycology community who really don't like iNat. In my view the only people that will leave if we make bulk export available are people who aren't really using MO for what differentiates it. In my opinion that's fine. |
Beta Was this translation helpful? Give feedback.
-
From Alan Rockefeller Feb 12, 2024: It would also be cool if there was an import feature - connect to iNat with an API key and import observations one at a time via observation # or import all observations that don't have a MO URL observation field. |
Beta Was this translation helpful? Give feedback.
-
iNat used to support a tool for moving MO observations to iNat. See https://www.inaturalist.org/posts/20053-18-mushroom-observer-api-key. However, that is no longer supported and according to the comments on that page is no longer available.
There is an existing tool for copying MO observations to iNat that was created by Jacob Kalichman. It's available here https://github.com/JacobPulk/mirror. It is useable, but it really needs to be properly integrated into the MO code base. There should also be a feature for pulling iNat observations into MO. I'm not sure exactly how doable a two way sync is, but at least in theory it shouldn't be too hard. The biggest challenge is going to be after the initial copy since there won't be a "single source of truth" since each of the communities can then update the observation on the given platform. The way I envision addressing that concern is by limiting exactly what is shared (probably to the assignment of names and the addition images). MO would also support a link to the iNat observation. iNat will not necessarily have the same names so there will be observations that cannot be copied to iNat. MO can always add a missing name so there shouldn't be a big issue going from iNat to MO. I expect that users will need to explicitly ask MO to sync an observation. There's an interesting question about essentially sync all of a user's observations. This could be quite slow. It's likely that this process should be handled by a background job queuing system.
I'm no sure whether it would be more valuable to first re-implement Jacob's tool to move things from MO to iNat or if it would be better to start with the other direction first. I think re-implementing should be easier, but going from iNat to MO is a bigger gap in the existing tools.
Beta Was this translation helpful? Give feedback.
All reactions