flag:colour Yea or Nay?

[michaelblyons]

I noticed that @1ec5 put flag:colour=yellow for the South Vietnam flag. I thought that was neat, so I added it to a set of U.S. State flags where there was a dominant color. Then I double-checked the guidance, although the only place I saw any was flag:name, where it says this (emphasis mine):

The value should be the name of a flag design in the local language. For example, a California flag on a flagpole in California would be tagged flag:name=California. If the flag design has its own Wikidata item, add a flag:wikidata=* tag. Otherwise, add a flag:colour=* tag so that renderers can approximate the flag's appearance.

Is it okay to double-up the tags? Or should we drop flag:colour in hopes that renderers can extract it from Wikidata (and that WD has it tagged correctly)? See flag:wikidata for this:

If the flag is too obscure to meet any of these requirements, use flag:name=* and flag:colour=* instead of flag:wikidata=*.

Beyond the bare minimum, a good Wikidata flag item can also have image (P18), color (P462), and aspect ratio (P2061) statements, which allow the renderer to display the correct design and can help a future mapper verify that the same flag is still flying at a particular flagpole.

But the handful I checked do not have a color in WD.

I'm also ignoring the fact that the two OSMwiki pages have conflicting guidance on whether to use flag:name.

[bhousel]

Good question, I was wondering about this too.. I'm ok with whatever people decide to do.

[1ec5]

I personally use flag:colour in the following situations (which basically restates the guidance on the wiki):

• I can’t identify the flag, so at least I can add its color so that renderers can approximate the flag. (Currently, no renderer recognizes flag:wikidata, but OSM2World recognizes flag:colour.)
• The country key is misleading for historical reasons. flag:colour=yellow overrides the color that OSM2World infers from country=VN on South Vietnamese flags. South Vietnam’s country code was the same as present-day Vietnam’s country code, but rendering a red flag would be politically sensitive to some OSM users today. This is a bit of an edge case: I don’t know of any other prominent examples where the ISO country code got repurposed but the previous country’s flag is still in use by communities that reject the current country’s flag.

It’s possible to use flag:colour in other situations, but I haven’t prioritized it. In my opinion, it’s like tagging the color of McDonald’s’ golden arches. If a renderer is unable to apply a realistic texture based on the flag’s design from Wikidata’s image property, then the next best thing would be to synthesize a texture based on the color property and its qualifiers. However, we aren’t quite there yet with the current crop of renderers.

But the handful I checked do not have a color in WD.

A bunch do, but Wikidata has gaps just like OSM does. It would be more efficient to tag the flag’s entity with a color in Wikidata than try to get all the individual flags in OSM tagged with the same information. However, OSM2World is only able to automatically detect a color for national flags based on country. While in general I would prefer to lean on Wikidata, the fact is that OSM2World would otherwise render South Vietnamese flags in a politically insensitive way.

I'm also ignoring the fact that the two OSMwiki pages have conflicting guidance on whether to use flag:name.

I wrote both passages but didn’t intend for there to be a conflict. One page is basically saying how you would hypothetically set flag:name, while the other says when the key would be especially useful. I didn’t mean to say one way or another whether you should use flag:name in cases where there’s already a flag:wikidata key.

That said, flag:name may be challenging for an editor to support automatically, because it’s supposed to be in the local language. NSI uses brand as a human-readable alternative to brand:wikidata, but localization is not as much of an issue for brands, because multinational brands tend to remain consistent across languages, if not writing systems. To me, it would’ve been reasonable for NSI to omit flag:name from entries that have flag:wikidata, but I know some mappers have strong opinions about relying exclusively on QIDs.

[bhousel]

That said, flag:name may be challenging for an editor to support automatically, because it’s supposed to be in the local language

Would it be ok if we just use a tag like flag:name:en for all of them?

[michaelblyons]

The country key is misleading for historical reasons. flag:colour=yellow overrides the color that OSM2World infers from country=VN on South Vietnamese flags.

I see. So the South Vietnam flag color wouldn't only be blank for renderers who skip Wikidata, it would be wrong if they load color from country code? That makes sense. There are also other entities that have changed flags in recent memory.

I'm happy to strip flag:colour from the ones that do not have a direct conflict. Or to leave it. I am not (at least in this instance) one of the "strong opinions about QID" mappers.

Would it be ok if we just use a tag like flag:name:en for all of them?

I feel like this is a reasonable compromise. But if a native speaker adds a localized flag:name (here or on an OSM node), so much the better!

[michaelblyons]

But if a native speaker adds a localized flag:name (here or on an OSM node), so much the better!

I just realized that adding it to NSI is not helpful for 001 flags. Presumably OSM wants flag:name localized in the place the flag is flown, not the place the flag comes from. 😞 It could still be helpful for regional flags, but so far all of them are [geo-restricted to the local-language area] anyway.