28. iPhone uplodder

https://www.inaturalist.org/observations/15613866 iPhone camera with voorzetlens
I am thinking a combination of the existing iPhone uploader and the website uploader. Organize the photos, add the ID and annotations, then either upload a batch of observations or upload all of them. This seems like it could result in quicker times to organize photos and a much lower risk of a crash losing the work. Upload times would of course be the same, but it would be possible to just have it run in the background.

I can confirm this - other than uploading the photos, the main bottleneck seems to be loading the metadata. I found that I had to limit my batches to about 25 observations to make the process workable. But even then, I still found it was taking far longer than it really should do, and every now and I would have to abort it due the browser locking up.
So in the end, I went down the same route as @glmory and wrote my own uploader. It also uses python, but not pyinaturalist, since I wanted more control over how the inat apis 1 are used. Doing things this way dramatically reduces the total upload time, and I can just run it in the background while I do other things. It also allows me to add annotations at the same time and simplifies the process of grouping multiple photos.
Even if the issue with loading metadata was somehow fixed, I doubt whether I would want to use the web interface for uploading again. The only major thing missing from the current apis seems to be ID suggestions using inat’s computer vision - but I very rarely use that, so that’s not a big deal for me.

That seems unusually excessive - what sort of internet connection do you have? It might be worth trying some of the online speed-testers to see what your upload speed is like (download speed is less relevant). And what is the average size (in megabytes) of the photos you are uploading? Do you crop them first?

My uploader is part of a bigger program at the moment so I’m not able to share it. But in any case, I don’t think it would help you much if you don’t have a reasonably good internet connection.
= = = = = = = = = = = = = = = =
The system has to resize images that are too large, and that will contribute greatly to the processing time of an upload. You could test it by doing a similar size batch but with the photos all pre-scaled to the iNat maximums. I know my camera is set to take photos that are nearly double in size (or 4x the qty of pixels!) to the iNat max. But even then, mine would not take more than 30 mins tops to upload 100 obs with approx 200 photos.

I think bottlenecks are going to be (in order of impact):
upload speed
activity on the site at time of upload
image size
I think the upload might be staggered, meaning that it doesn’t all get processed at once and the site come to a grinding halt for everyone else while it processes. This might explain why an external uploader might be getting faster results. If this is the case, do we really want large processing volume burdens being developed? It’s fine for occassional situations, but if the number of people using it grows, then you might be getting faster processing of your uploads, but causing unacceptable delays in other parts of the system such as in just loading observation views! I would encourage you to contact the developers to make sure your impact will not be detrimental.

If you have questions about how iNat works, please just ask. Regarding the website uploader, we do not resize images in the client. Well, actually we do, but only to make a thumbnail to upload for vision suggestions. The final cutdowns happen on the server, and yes, there are performance implications for the site as a whole. Improving server-side image processing is definitely on our radar, though frankly, it only creates serious problems during periods of extreme usage, like the CNC or the Penang Incident. A third party client that cuts everything down to 2048x2048 before upload might feel a bit faster due to reduced server-side processing time… or it might be faster b/c you’re uploading less data. We also only upload a max of 3 observations at a time in the website uploader, so if a 3rd party uploader creates more simultaneous upload requests it might get the whole job done faster, but could theoretically function as a Denial of Service attack if it swamped all our server processes.

I don’t know why the uploader is so slow for some people. I’m sure we all have our theories, but what would help us address the problem are concrete examples including excruciating amounts of contextual info: what browser you’re using, what your internet connection speed is like, specifically what files you’re trying to upload, etc. Some issues might be solved by a third party uploader, but not things like connection issues. While diagnoses might be helpful, reproducible examples will always be more helpful. There are a lot of variables.

Finally, we’re not going to make a standalone uploader, or at least not any time soon. We’ve toyed with the idea of a desktop app a lot, but ultimately, of the many potential uses for such an application (offline use, backups, etc.), faster image upload has never been on our radar. If you have the bandwidth to upload and the website’s not working, we should fix the website, not make more software that works better.

For folks interested in continuing to talk about standalone uploaders, using the API, or if you have other questions about rules around 3rd party apps feel free to check the documentation, message help@inaturalist.org, or ask/discuss in the General category after reading up at:


*and, please remember to keep discussions on topic. If you want to have a one on one unrelated discussion, you can always directly message someone privately or start a new topic.

= = = =
OK, here is how you can see your options: In the Community ID box, click "compare", then set the Place to "South America", and for Taxon, type in Calycopis, you'll get: these 4 matches in that genus: C.origo, C.isobeon, C.caulonia, C.cerata. But then try "Lycaenidae" (the larger family), and you'll get Ministrymon azia, and Strymon melinus added to that list of 6 very similar species. You may need a more local expert.
= ==
It is possible using the unobserved_by_user_Id parameter in the observations view.

2 caveats

if you do a species view, you are restricted to the 500 most frequently seen species unless you start filtering down (ie add birds or beetles etc)
the ‘unseen’ is not geographic specific, it counts you as having seen it if you have seen it, but not in the location you specify.(so for example in the list below, Grey Kingbird will not appear, even though I have never observed one in Ontario, just elsewhere)
For excample this url shows all the birds reported from Ontario that I personally have not seen (or more accurately not recorded an iNat record for as I have actually seen some of them)

https://www.inaturalist.org/observations?place_id=6883&subview=table&taxon_id=3&unobserved_by_user_id=cmcheatle&view=species 9

you can add additional filters for hrank and lrank equals species if you want to get rid of the genus level records.

In addition to the unobserved_by_user_id search filter for the website, you can try out the “Missions” feature on the Android app.


Tijdperk, Periode Betrokken Librarie Geraakte onderdelen
Tot November 2019 Alleen RestKit Library Library Aanwezig in Guides, Projecten en Waarnemingen.
November 2019 Alleen RestKit Library Gidsen overgezet naar Swift
Januari 2020 Van Reskit naar Swift iNat 2.8.7, Project Overgezet naar Swift
Maart2020 Van Reskit naar Swift iNat 2.8.7, Project Overgezet naar Swift



Publicado el 10 de abril de 2019 a las 10:14 AM por ahospers ahospers


No hay comentarios aún.

Añade un comentario

Entra o Regístrate para añadir comentarios