Brian, as someone who worked on these national rail relations (and still does, to some extent, though only around the edges), I agree with you that "very large" relations (in Amtrak we say that one route is >2500 relations and meets that standard of "very large") do exist. And, they are unwieldy, especially for those who edit with "only" moderate (or less!) compute resources. Such demands are partly why open mapping didn't happen until the 21st century: our computers are just keeping up (as they do: compute power fills niches of computing that the tech / hardware / software development only catches up to, it then begins to be used for those applications). Desktop computers and Java / early JOSM / Potlatch 1 and 2 around 2005 were an OK match for each other. OSM has grown these from there. (Nicely, in my opinion, though there are always newer, faster technologies and software platforms to harness them).
AI on "bigger iron" is real today with what Facebook is doing in OSM with its machine learning toolchain. Data structures must keep up. Physics had to look to the ancients and see that 10 to the 100th power wasn't so big, there are Sanskrit words from long ago for what we consider fairly large numbers today. And so OSM must keep up with inventing its future (of data structures) capable of "keeping up with Earth as data." Super-relations do seem the way to go: so far, so good. I don't know about "200 deep" but as things go much wider (but not much deeper than perhaps several "relation-levels" for now, let's say "great-great-grandparents" I can hold in my mind for now), they seem like they will suffice. If we need that many "dimensions" (relations "deep," not necessarily wide, as data simply ARE wide, not necessarily deep, though we should be prepared to go deep if we need to) we can, as you say "go hundreds deep." But yes, doing so both preserves the legacy of relations of relations (and even "of relations...ad infinitum") we don't need to do that very often. However, in train routes, there are now super-routes that exist that are "grandparents," so three deep. This seems to be happening with bicycle routes, too and perhaps road routes, I'm not quite enough of a road geek to say yes or no, but I think so. Luckily, relational databases (like OSM) give us ways to link them all together, "walking up and down the chain of hierarchy." Some software, use cases, routers, whatever...will be sophisticated to do this walking and "be smarter for doing so," presenting a much fuller, richer, complete universe of data, some (software) will not and will present a more "flat" view of the world (OSM's data, really, similar to looking at ways or nodes only but ignoring relations). We both have and use methods to do this, so, "good." But you are right to be talking about it, as data consumers, use cases, "those downstream" will need to have their antennae tuned to be paying attention to these "more sophisticated" ways of embedding hierarchy in our data. We have been doing this since relations were developed in OSM, some data consumer softwares pay attention, some don't. It's a real thing. I like, for example, the way that Lonvia (in the www.waymarkedtrails.org series of overlay layers) allows and displays a view of relations and super-relations in the table of routes presented. That's called "paying attention" and it's great when developers pay attention to these richnesses in the structure of our (sometimes hierarchical) data (so, thank you again, Sarah). Being aware there IS a hierarchy is the first step to "walking it" and presenting its complexity to data consumers in ways that make sense for that sort of structure. We'll solve coastline / water edges, it'll be mostly legacy (we've done it like this for quite some time) with a bit of "new methods of thinking about things" going forward. This is how OSM works. Talking about it is fine. We're generating light, not heat. A lot of people (Simon, Phake, Dave F, Clay, Mateusz, Christoph, Brian, Seth, Richard, more...) are quite right here. Let's listen to each other. We're all much MORE in agreement than disagreement. SteveA _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
