Relations are not categories
Dear Wikipedia contributor,
you may be used to each article in Wikipedia having at least one category. As soon as you create a new article in Wikipedia without a category, it will either immediately be marked for removal or added to a category. There are people who do nothing else all day than add meaningful categories to Wikipedia entries.
The "relations" we have in OpenStreetMap are not categories. They are meant to model a close (and usually local) relation between objects, for example: This entrance leads to that subway station, or: You cannot turn from this road into that road. We also use them to group fragments of a road, as in: These fifteen parts together make up so-and-so road. We do not, however, create relations that simply collect a loose group of somewhat related items. We don't do "Footways in East Anglia", we don't do "Scottish Lochs". As a Wikipedia contributor, you might feel the urge to find at least one relation for every object you touch - but please resist that urge. Our database is a spatial database; this means that it has intrinsic knowledge about the location of objects. If you want to know about all footways in East Anglia, simply pass in a bounding box of East Anglia and request all footways, and the collection is made for you on-the-fly. Anyone adding a footway just has to make sure it is in the right place and marked as a footway - the fact that this is in East Anglia does not have to be recorded because it is implicit.
In addition, it is very likely that another mapper adding a missing footway in East Anglia adds the footway to OpenStreetMap but does not know that there is a relation collecting all these ways. As a consequence, the East Anglia Footway Relation is incomplete. So, why should data users use such relations if it is very likely that they are incomplete?
There is even one reason more against using relations which just collect some objects: If someone deletes a footway from OpenStreetMap or splits an existing footway, a new version of the relation is created because the member list has to be updated. This happens rather frequently, bloats up the history of the relation and makes it cumbersome.
So, again - please don't do things like "Footways in East Anglia".
But what about group relations that add information, you might ask, like "HSBC ATM machines"? Here, too, a relation is usually unnecessary; if the ATMs are tagged with something like "operator=HSBC" then anyone can easily extract all HSBC ATMs, you do not have to create a relation for that (this will only make editing more difficult and error-prone). Grouping relations really only make sense if the grouping is neither geographical (as discussed above) nor exclusive (like the HSBC example - the cash machine is unlikely to be operated by two different institutions at the same time).
A good example for a valid and useful grouping is the "route" relation, where multiple ways are connected to form a cycle route or a walking route or something else; a way may be part of any number of routes so this cannot be solved by tagging the way with "route=xxx".
Thank you for your understanding,
Those who invented relations.