I see Texas and other states have all of their counties listed as subareas:
While Georgia and other states do not:
Is there a guide somewhere on how to add those?
Subareas are a controversial practice. They are also unnecessary. Subareas exist in some boundary relations but nobody has really taken the time to settle the question either way. I would be opposed to further proliferating them.
3 Likes
This is similar to the, now discouraged, practice of having everything have an is_in tag. They are implied as being sub areas by being inside of the greater TX boundary. We have great tools for figuring out the geographic relationships between objects in the database. Let those tools take care of it and we save ourselves another list to maintain.
4 Likes
Thanks, Brian – What makes it controversial?
Never mind – I think watmildon answered why it was controversial.
2 Likes
If you would like suggestions on how to remove any that you find, I’m happy to help with that 
I agree with Brian - don’t do it. OSM is a geographic database and if you want to find out which areas are in which other areas, you can use geographic algorithms to do that.
The “subarea” craze hails from the same mindset as those “cycle paths in A county” or “bus network of B city” relations - someone wanted an easy handle to (ab)use the OSM API to download them all (via the /relation/$ID/full API call).
3 Likes
In theory, subareas could have been used for aggregation of smaller territorial units into larger ones – instead of defining large ones by specifying each boundary way.
For example, United states would have been defined as a tree of relations:
Boundary United States of America
- Boundary Alabama as subarea
– Boundary Autauga County as subarea
– … - Boundary Alaska as subarea
- Boundary Arizona as subarea
… Boundary Wyoming as subarea
In that way, country and international boundary relations would not contain 1000s of boundary ways, and those ways would not participate in dozens of boundary relations. It would be only marginally more complex for data consumers, who would have to recursively process the tree and find unique ways in order to find a polity’s outer ways.
(Of course, not all boundaries form strict hierarchies, so multiple such “trees” would exist. Still, the whole thing would be much simpler to process and maintain than today, where subarea is not really a thing).
Wishful thinking…
A very similar approach was recently proposed for making time zone boundaries more manageable, but if we implement it, it would actually have the opposite effect, increasing the burden on both mappers and data consumers:
Besides, such a representation would usually be fundamentally inaccurate. While it is the case that the U.S. is composed of “the several states”, its boundary is officially defined as a few linear rings. The boundary description for the contiguous U.S. makes no reference to interior states such as Colorado, but it does refer to rivers, distances, survey lines, and specific coordinate pairs. This is how the vast majority of boundaries are customarily defined in this country’s legal tradition, from the country all the way down to the parcel on which I’m standing.
It makes for a pretty good test as to whether something is actually a boundary: a boundary can be perambulated based on its description, if not in person then from an armchair. My initial hesitation about Connecticut’s “council of governments boundaries” was that COGs in other states are merely membership organizations. Eventually it became clear that what was being mapped was not the COG but rather the planning region for which the COG is responsible, which is defined as a boundary.
Maybe you can guess how I feel about boundary relations that consist of member_state members, such as NATO.
Just about the only situation I know of where a subarea structure might have some advantage would be the subdivisions of an Indian reservation. On some reservations, the local jurisdictions form a sort of “diamond inheritance”, to use a computer science term.
A given boundary relation could be a subarea of both the native and nonnative civil boundary relation structures. But there’s probably an alternative way to solve that problem that doesn’t incur the disadvantages of subareas. The status quo has been to define an alternative primary feature tag for the reservation as a whole, so logically we could also define a secondary key to use in parallel with the boundary=administrative admin_level=* tagging scheme.
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.
3 Likes