Closed ENT8R closed 5 years ago
Good question - it's to fit inside this 60x60px space in iD's sidebar:
Or this 40x40 space on iD's new ribbon:
I think the square
option returns a 100x100 icon.
Some more details about logos:
So for the purposes of showing a logo in iD, I'll probably do Facebook/Instagram first, Twitter as fallback, and Wikidata as next fallback.
I know this is heavily biased towards iD.. but if other projects want to use the logos, I'm happy to change what we do in name-suggestion-index to make it more useful for other projects too. For #2472 I will be moving all of the cached Wikidata properties and logos into a separate file.
👉 A very useful thing that anybody can do is go through the browsable index http://osmlab.github.io/name-suggestion-index/brands/index.html and for each brand missing a logo, look up the brand's Facebook/Instagram/Twitter/etc accounts and add them all to the brand's Wikidata page. I was doing this last night, and got through a bunch of the cafes. It's very easy to do!
Are you going to be adding Instagram to the catched icon tables in the list of what we have or not? It would be nice to know which ones still need them added to their Wikidata articles.
Are you going to be adding Instagram to the catched icon tables in the list of what we have or not? It would be nice to know which ones still need them added to their Wikidata articles.
The reason I didn't is because Instagram and Facebook are essentially merged now. But I can see how it would be useful to add it for checking the brand for completeness.
Thank you for your very detailed response!
I think the
square
option returns a 100x100 icon.
It seems to be 80x80 but that does fit too 👍
So for the purposes of showing a logo in iD, I'll probably do Facebook/Instagram first, Twitter as fallback, and Wikidata as next fallback.
I don't know if this is the best order because sometimes some brands don't have their logo as a profile picture but some kind of advertisement. Can be seen e.g. at Burger King at the moment:
Wikidata | ||
---|---|---|
Otherwise I don't really know how to prevent this...
BTW: the documentation of the endpoint is this one: https://developers.facebook.com/docs/graph-api/reference/app/picture and not https://developers.facebook.com/docs/graph-api/reference/user/picture/
sometimes just pictures of the front of a building or a plate of food
Maybe accept only svg and small png and refuse 3000px x 2000 px jpg files? This should drop some blatantly wrong data.
sometimes just pictures of the front of a building or a plate of food
Maybe accept only svg and small png and refuse 3000px x 2000 px jpg files? This should drop some blatantly wrong data.
The thing I said above is significantly easier than trying to outsmart the users 😆
Or maybe we could fix the entries on Wikimedia's side that are suppose to be icons but aren't.
Or maybe we could fix the entries on Wikimedia's side that are suppose to be icons but aren't.
Yes, this 💯!
Is there a reason why you are using
type=square
rather thantype=large
?type=large
offers a better resolution thantype=square
:
Update on this - @quincylvania got them working in iD and the large
size really does look much better than the square
size - so I'm going to switch the url in build_wikidata.js
and refetch them..
https://github.com/osmlab/name-suggestion-index/blob/e4bd2327d95c08d8ed3a94b13707e8b0401487e3/fetch_logos.js#L129
Is there a reason why you are using
type=square
rather thantype=large
?type=large
offers a better resolution thantype=square
:type=square
type=large
Though the size of the file of course also increases 😄