Prefer Wikidata SVG logos over social media icons for brand presets

[1ec5]

When a brand entry in the name-suggestion-index has an SVG image as its Wikidata logo, prefer that image over any Facebook or Twitter logo.

Official Facebook and Twitter accounts are not always as reliable as Wikidata items for brand logos. A brand may adopt a non-logo as its social media photo as part of a marketing campaign. However effective the marketing message may be in the context of a social media profile, it’s simply jarring when it appears in iD preset search results, where the user isn’t expecting an advertising message.

Wikidata on the left.

Here, the SVG logo from Wikidata is much more recognizable than the profile picture KFC is currently displaying on Facebook and Twitter, which is meant to be viewed in the context of a larger profile cover photo. As I understand it, the point of putting these icons in the search results is to increase the presets’ recognizability.

KFC’s marketing campaign may be ephemeral, but some brands choose social media photos that are still less recognizable than a logo would be:

This isn’t to say that logos in Wikidata are always the most suitable for iD. But most of the time, an image from Wikidata would be unsuitable because it’s a photo of a store location or a very wide logo. To mitigate these issues, we could keep the current behavior whenever the Wikidata logo has an illegible aspect ratio like 1:6 or wider, or when the Wikidata logo is a JPEG or PNG.

iD/build_data.js

Lines 253 to 260 in ddc9d16

	let logoURLs = nameSuggestionsWikidata[qid] && nameSuggestionsWikidata[qid].logos;
	if (logoURLs) {
	if (logoURLs.facebook) {
	logoURL = logoURLs.facebook.replace('?type=square', '?type=large');
	} else {
	logoURL = logoURLs.twitter || logoURLs.wikidata;
	}
	}

[bhousel]

For the record, I see absolutely nothing wrong with this 😆

[bhousel]

ok.. So I did this, and it didn't work as well as I had hoped..
The main problem is that these wiki commons logos are often really not square. I left the code in build_data.js commented out for now, because it was producing noticeably worse results.

commons:

facebook:

[matkoniecz]

Is non squareness sole problem or is it worse?

[bhousel]

Is non squareness sole problem or is it worse?

That's the sole problem. They just don't look good in the space where we are using them, in the way that a profile picture would..

[matkoniecz]

Is allowing only relatively square ones too complicated or is it just case "someone needs to code it"?

[BjornRasmussen]

Is allowing only relatively square ones too complicated or is it just case "someone needs to code it"?

Currently, iD only flags buildings if they are very close to being square (some corners are almost 90°), don't have too many nodes, and aren't connected to other buildings. A triangular building, for example, would not be flagged

[bhousel]

Is allowing only relatively square ones too complicated or is it just case "someone needs to code it"?

We'd need to fetch the images to determine their dimensions.
Also they can change at any time, and I wouldn't expect the Wikipedia folks to change all their logos to accommodate iD. I understand the appeal of using Wikipedia commons logos, but it really feels like a dead-end to me.

[bhousel]

Currently, iD only flags buildings if they are very close to being square (some corners are almost 90°), don't have too many nodes, and aren't connected to other buildings. A triangular building, for example, would not be flagged

This issue isn't about buildings - it's about logos. 😆

But for the record.. iD can detect and square triangular buildings just fine 👍

[BjornRasmussen]

Yikes! I confused two issues I've been following - plus I'm used to people not understanding the square validation.
I meant above that a triangle with only 60° angles won't get turned into a square.

[1ec5]

We do have some triangular logos in the index, but thankfully they’re encased in rectangular images. 😉

We'd need to fetch the images to determine their dimensions.

The Wikimedia Commons API can fetch file metadata in bulk without fetching individual images: osmlab/name-suggestion-index#2641.

[1ec5]

KFC is back to being… less buff… but now Burger King has joined in on the fun: osmlab/name-suggestion-index#2798.