Wiki harvesting: how to update ratings and crops

[hyanwong]

We will probably want to be able to manually change the rating of images, and also force re-cropping using Azure, both for src=20 and src=2 images. I'm mostly thinking for the moment about how to change the rating. We could either do this via the process_leaf / process_clade route, by essentially reharvesting, or we could have an independent way to do it.

Against the idea of repeatedly using process_leaf() on the same OTT is that at the moment, if the image has already been harvested into the DB, we skip any modification, even if we specify a different rating. If we do have an independent way of re-setting a rating, I think it would be good to have it as another routine in the get_wiki_images.py file.

I'm not sure what the best approach is here.

[davidebbo]

Yes, if we want a command that simply changes a rating, it's a much simpler operation that doing the full pipeline.

An interesting question is what parameters it should be passed. We can't just pass the ott, since there can be many images for one ott, even within src=2.

Maybe it's best to simply pass it an image name/url and a rating, and have it update all the rows that have that image. Normally it's only one row, unless the same image is used for multiple species, which does happen sometimes. I suppose we could also pass the ott optionally.

If the image is not a URL, it can assume wikimedia. e.g.

get_wiki_images update_rating Canis_simensis_Bale_Mountains_1.jpg
get_wiki_images update_rating https://commons.wikimedia.org/wiki/File:Canis_simensis_Bale_Mountains_1.jpg
get_wiki_images update_rating Canis_simensis_Bale_Mountains_1.jpg 752755

[davidebbo]

Alternatively, this can just be done using a simple SQL script that takes parameters. It's really just an UPDATE statement.

[jrosindell]

This issue somewhat overlaps both tree build and main repo but we have an ongoing issue about how to handle hard to crop images particularly those with extreme aspect ratios. I think solution is to have a tree data system that can serve either the cropped or uncrossed image, and ideally one which knows when the images doesn't crop well. The tree visualisation part of the system can then be built to handle other aspect ratios of images on the leaves and at the same time rethink the signpost visualisations. I actually think in any case that images on signposts should be removed entirely and we should have names on signposts and images on dropped pins dotted all over the tree - it might be much easier to build a dropped pin that allows other aspect ratios of image than anything else.

[hyanwong]

I think the best option in most cases is to try to find a relatively "square" image, but of course that's not always possible (or sometimes desirable).

[davidebbo]

I think the best option in most cases is to try to find a relatively "square" image, but of course that's not always possible (or sometimes desirable).

Yes, that is something worth looking into. Right now, I have heuristic that looks at the title and favors "restauration" or "reconstruction" images, which are usually good for extinct species. But it could also potentially look at the aspect ratio as part of the heuristic.

[hyanwong]

Neat: I wondered how you were getting so many reconstructions, rather than bones.