I don’t think this is a big deal. Nothing uses multilinestring relations. Whatever we do about multipolygons we can do about other compound-geometry relation types too.
Even if you plaster a big red warning about how the relation type isn’t for categories, people use them for categories because their goal is to create a convenient page on osm.org or hang a wikidata tag off of it for Kartographer to pick up, and such a generic keyword naturally fits. Besides, we only say relations aren’t “categories” because Wikipedia’s MediaWiki software calls this concept a “category”. In other fields like library science, they’re called “collections”, “facets”, “sets”, or “groups”.
I agree that there are sets of things that people perceive as a single unit for some purposes, like the Great Lakes. But this topic is really about something that’s only superficially similar to those sets. If we want any relation type to be processed in a specific manner – like imputing a fuzzy boundary – then we might as well define a new relation type. Otherwise, why did we bother coining route since collection was adequate for grouping any linear feature?
As a counterpoint, this multilinestring relation represents some bushes arranged to spell “KOREAN WAR MEMORIAL”, part of a prominent decorative feature in a Korean War veterans’ memorial.
The words “KOREAN WAR MEMORIAL” have a total of 17 letters, but this relation has 29 members, because some letters like “K” and “R” require at least two strokes. This relation should be interpreted as either a single message with a MultiLineString geometry (hence type=multilinestring) or as an indistinct, unrelated series of hedges. What I think you’re suggesting is that I should instead turn this into a superrelation of nine subrelations and eight ways representing individual letters. Even if today I might be in the mood to micromap amenity=letters, I don’t see how type=group as a tag would tell a data consumer anything other than “Yes, I really mean it, this is a relation.”
(I did break up the next line word by word, because it doesn’t read as a single phrase. This also allowed me to clarify the abbreviations. In this context, “USA” stands for “United States Army”, not “United States of America”.)
This reminds me of what it would take to derive ZIP code areas from OSM data in the U.S. A user looking up the nearest pharmacy or getting the weather where they’re standing doesn’t necessarily want to enter their specific address but might enter a ZIP code instead. Many street maps label ZIP codes in a similar manner as neighborhood names. For example, the Chicago Metro Area StreetMap (1996) by Universal Map includes ZIP code labels and ZIP code “boundaries” in purple:
Many online maps and geocoders approximate ZIP code areas using the Census Bureau’s ZCTAs, but these geometries are actually based on census blocks, which poorly reflect actual ZIP codes. Since a ZIP code is a collection of unpublished delivery routes that can change at any time, we’re unable to map the delivery area as an area in OSM, but we do tag each individual feature with the ZIP code in its address. A data consumer could use a clustering algorithm or a Voronoi tessellation to derive a more precise approximation of each ZIP code.
I suspect a 2D point cloud relation would be overkill for labeling a mountain range, if that’s all we want to enable in data consumers. But perhaps a point cloud relation would also enable a geocoder to determine that a user location is “in” the Green Mountains with some confidence level. If so, a similar clustering algorithm could allow a data consumer to make sense of such a relation.
.