Name-suggestion-index: Facebook logo: type=large offers higher resolution than type=square

Created on 18 Mar 2019  路  9Comments  路  Source: osmlab/name-suggestion-index

https://github.com/osmlab/name-suggestion-index/blob/e4bd2327d95c08d8ed3a94b13707e8b0401487e3/fetch_logos.js#L129

Is there a reason why you are using type=square rather than type=large?

type=large offers a better resolution than type=square:

type=square | type=large
--- | ---
|

Though the size of the file of course also increases 馃槃

question

Most helpful comment

Is there a reason why you are using type=square rather than type=large?
type=large offers a better resolution than type=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..

All 9 comments

Good question - it's to fit inside this 60x60px space in iD's sidebar:

Screenshot 2019-03-18 12 52 27

Or this 40x40 space on iD's new ribbon:

Screenshot 2019-03-18 12 52 07

I think the square option returns a 100x100 icon.

Some more details about logos:

  • Facebook/Instagram profile URLs can be fetched from Facebook's Graph API. It has a GET endpoint that anybody can use without authentication. This is nice! iD actually could construct these URLs on the fly if it wanted to.
  • Twitter profile URLs can be fetched through the Twitter API however you need an app key to use their API and there are some strict rate limits, so that is why we need to cache the logo urls. I'd rather not!
  • Wikidata's logo URLs can be anything - it's just whatever URL people attach to property P154. They are often not at all square, and sometimes just pictures of the front of a building or a plate of food.

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 | Facebook | Twitter
--- | --- | ---
| |

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 than type=large?
type=large offers a better resolution than type=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..

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tordans picture tordans  路  5Comments

matkoniecz picture matkoniecz  路  9Comments

kymckay picture kymckay  路  6Comments

roshavagarga picture roshavagarga  路  4Comments

bhousel picture bhousel  路  4Comments