In QLever, it’s trivial to filter boundaries by whether they spatially fall within the United States boundary relation. A query for all the boundaries in the United States of any kind takes less than half a second, and adding geometry to it still comes in at about 2 seconds.
Unfortunately, recursive relation queries tend to blow past memory limits very easily. A recursive query based on subarea
roles will easily time out. This is because QLever is optimized for spatial queries, not for recursing up and down arbitrarily deeply nested trees of relations.
Fortunately, it is also trivial to query for any subarea of any boundary, as long as you only care about each individual membership, not the overall relation hierarchy. Subareas apparently aren’t as popular in the U.S. as they are in Europe and East Asia, but they are being used extensively in a handful of states, as well as the Navajo Nation for the reason I mentioned earlier.
Besides uneven coverage, subareas allow for some flexibility that may not be desirable. These 562 “subareas” don’t even partially lie within or border their containing boundaries. For example, in Austria, Sankt Stefan im Gailtal and Klagenfurt-Land District are spatially disjoint and appear to be unrelated geographically too.
There are even more nonsensical possibilities, such as boundaries being subareas of themselves or forming a reference cycle. Of course, other kinds of nonsensical relations already happen plenty in OSM, such as broken route relations. But we accept those errors as a manageable tradeoff for capabilities that are only possible using relation memberships.
Sophox is not as optimized for spatial queries. In fact, it has few facilities for doing anything with geometry, but it does index relation hierarchies. As a result, you can query for subareas of the United States in about 2 seconds, and you can display the results in a tree:
While this tree is a handy visualization of the relation hierarchies that have been built so far, this is about all you can do with a complex recursive relation structure. I think it hardly outweighs the maintenance overhead; spatial queries hold a lot more promise for OSM.