Judge Case

Not all canonical chains in the world can be accurately divided into specific categories such as brand/operator. It's not always clear if an entity is notable enough to be added to the index. Sometimes it's difficult to determine what language or set of data to use. Ambiguity always exists.

Therefore, we often need community discussion and the judgment of the maintainer to determine what the best course of action is for the NSI.

The following is a list of some classic cases to help contributors and new maintainers judge.

---

Notability

At least 30 locations (brands/operators) or instances (flags/transit networks) globally are recommended before including an entity in NSI. This threshold may be lower in some situations such as in a OSM data shortage region, where at least 10 elements (currently or will have in the future) is the recommended threshold.

In any case, entities must have a page on Wikidata to be fully integrated into the NSI, and to show up in editors that use NSI as a reference for tag presets (e.g., OSM's iD editor). As a result, new entity suggestions that do not include a Wikidata tag (*:wikidata) will probably not be accepted.

The nsi_collector project has a threshold of 50 entries in planet.osm (global presence in OSM data) to include a name in its data. See collect_osm.js#L33-L39 (how this data is used is unclear, it seems to have been an early method to populate NSI as it seems to not be updated regularly any more).

See also discussions in #8399, #9002 and #9052.

---

Common situations and scenarios

Many common issues were compiled into a list at #2099.

---

Determining keys and values

Should an entry be under brands or operators?

See discussions at #5625 and #5924.

Is an amenity a restaurant or cafe?

(discussion examples needed)

Is an amenity a restaurant or fast_food?

• amenity=restaurant for a place where a host seats you and a waiter takes your order (aka "table service")
• amenity=fast_food for a place where you order food from a counter (includes "fast casual" style)

See comment to #4987 and OSM wiki for sustenance amenities, restaurant amenities and fast_food amenities.

How many cuisine/clothes values should I add?

Only those values that represent the restaurant or clothing store's defining specialty or theme. You don't need to copy the menu or wardrobe list; after all, NSI isn't a food delivery or fashion website.

---

Adding specific keys

key	Allowed?	Reference/links to further information
vegetarian and vegan	case-by-case basis	#4855 (a long discussion about those two tags); #5727 (rejected case); #5801 (merged case)
contact tags like website or phone	no	Item Property Reference#tags
wikipedia / *:wikipedia	no	#6481; commit e3d25ab
payment	yes, within reason	Entries must "stick to a minimalistic set of tags" when using payment - see #6703. Also, there are some situations which don't need payment: #4696, #4105, #4976, #6701
amenity related tags such as WLAN / wheelchair	TBD	(discussion examples needed)
tags that require an on ground survey, such as outdoor_seating or smoking	case-by-case basis	#7269
old_name	generally no	#9738 (discussion that led to an accepted case); #9939 (discussion that led to matchNames being used instead)
operator / operator:* for brands	generally no	#9716, #9989, #10131 - use Wikidata to specify owners/operators of non-franchised brands (and to store information relating to said owners/operators), and edit OSM directly to specify owners/operators of individual locations of franchised brands

---

Localized topics

Language of an entry

Currently, the decision of which language to use for an entry is mostly based on https://wiki.openstreetmap.org/wiki/Multilingual_names. This is not a hard and fast rule, though, and it may vary from case to case.

Should I use the Wikidata entry of a local branch of a brand or the global brand if both exist？

The local branch's Wikidata entry is OK if it has more correct data associated. See PR #7812 for addition of local McDonald's Wikidata.

Itemized locationSets vs. specifying a "global" presence

This is up to the discretion of contributors and maintainers and should be evaluated on a per-item basis. As a general rule of thumb, if a locationSet for an entity can be narrowed to a few areas, this should be done to avoid potential overlapping with other entities that have the same name. Otherwise, if the name of the entity is unique enough, there is no harm in using the UN M49 code for "global" (001) as the locationSet if the alternative would be specifying a laundry list of various countries from around the world. From a technical standpoint, there is no difference in end-user performance when comparing a custom locationSet to using "001".

See discussion at #7101.