I would suggest to do this by starting a proposal to deprecate relation type=network, rather than picking them off one-by-one. That would also clarify whether there is community consensus for deleting networks.
I do not agree. It all hinges on your definition of these terms.
Obviously all highway objects in OSM, taken together, form “a network”. As do many possible sub-groups of that, for example “all primary roads in Italy” form a “network”. Yet we don’t allow a relation called “primary roads in Italy” (with 25 translations of the term “primary roads in Italy”) - it would be a collection, and an arbitrary one at that.
Now, at what point does an arbitrary collection become a “network” in the sense that you think it should be given its own relation in OSM? If the mayor of $SMALLTOWN sits down at their desk and muses about the five hiking trails they have and says “we should really put something about our $SMALLTOWN hiking network on our web page”?
I think that for something to be a “network” it has to be maintained as a network by someone, it has to have some sort of “life” of its own. Whereas the “international e-road network” is, according to today’s version of the English wikipedia, a “numbering system for roads in Europe”. This doesn’t sound like a network in my eyes.
I think that if objects are added in keeping with standard editing practices then their risk of being deleted down the line is small. If, however, someone bends an existing practice or definition and adds data that many others would not add because they think it is not a good fit for OSM, then they can either seek community consensus at the time (hey folks, I am thinking about adding a relation for this thing, what do you think) or they can just go ahead, but that carries a risk that the thing is removed again later. Just because anyone can add anything to OSM, doesn’t mean that everything will stay in OSM. And that is a good thing!
2 Likes
Physician, heal thyself. Please let us know once the German community has reached a consensus on type=network and deleted relations like Relation: Radverkehrsnetz Gem. Kalbach (17784275) | OpenStreetMap which consists of a bunch of route=bicycles and some tourism=guideposts
why you think that @woodpeck endorses this relation (or that he was even aware of it)?
There are many objects in Poland that I would delete if I would have time to deal with them (in fact I started this discussion as this relation was pointed out during deleting relation categories in Poland).
And far more that I am not aware that they exist.
1 Like
That’s just one example of many network relations in Germany. I perceive the German OSM community as generally well organized and on top of things, so I don’t expect that many things are widely used without meeting community consensus.
I think it would be better to have a wider discussion about deprecating network relations rather than discussing them separately. Is there a reason you haven’t done so?
1 Like
This type of relation may be minimal usefull but I see no reason to delete it.
I would suggest to concentrate on real collection relations with thousends of ways directly included.
Based on the text of the European agreement and the map published by UNECE, Wikipedia is correct while OSM is not.
Do we at least agree that Roads of South Korea is inappropriate for OSM? It’s unnecessary and a distraction from actual route and network mapping. Data consumers are poorly equipped to make use of such a relation even if they had a reason to. Unfortunately, the reliance on network relations in East Asia discourages mappers from using network tags that are more readily usable.
I’m unprepared to throw the baby out with the bath water. I recognize that there are instances in which a network relation is the only geographic representation of a network that we can come up with. That makes it all the more important that we avoid diluting the relation type with lists of routes.
In my opinion, this discussion is about where to draw the line. The E road network strongly resembles most of the road networks we’ve simply tagged as network=*. On that basis alone, we should strive for consistency with those other networks. On the other hand, the primary/non-primary route system in the UK is essentially unmapped and may benefit from some kind of network modeling, since data consumers currently have to resort to fuzzy heuristics in order to detect the presence of these routes (for influencing the color of road number shields or other purposes). Some scenic=yes and lcn=yes usage is probably hiding what could also be more reasonable uses of network relations.
ones I deleted already were blatant category relations (C-class roads in town Y according to city planning document from year N)
also, I am NOT proposing deletion of all network relations at all
I think the top-level relation Roads of South Korea is indeed going far, because it combines 4 networks, instead of mapping 1 network.
In the Netherlands we do have network relations for the national road network, the several provincial road networks, city route networks and recreation route networks. These cannot be mapped solely by the network-tag, because that’s reserved for the prefix A/N/S/R, which doesn’t fully match up with the networks. But we don’t have a superrelation to group all networks, like in Korea.
Still, the E-road network is mapping 1 network, not multiple.
because these are blatant category relations (C-class roads in town Y according to city planning document from year N)
By using that kind of reasoning, you’re stretching the original meaning of category-relations to any type of relation:
- Route-relation: all roads that are marked with this specific marker/number
- Turn-restriction-relation: all roads and point that are relevant for this specific traffic sign
- Boundary-relation: all boundaries that are surround this specific country.
1 Like
I think these are two different questions. You seem to want to steer this discussion into a general question of whether the mapping of all networks should be stopped, which would obviously be a larger discussion. But I am disputing that the relation in question here even is a network in the sense of the OSM network relation. If I am right (and this relation is not a network relation but a collection), then it could be deleted without even touching the question of whether true networks should be mapped or not.
Regarding the “Radverkehrsnetz Gem. Kalbach” relation that you dug up, I lack knowledge about these types of relations. I think there’s a concept that is gaining popularity in cycling circles that relies on specially marked nodes (probably see Numbered-node cycle network - Wikipedia for a description). I don’t know how these systems are created and by whom they are maintained and whether they meet OSM’s requirement for a network relation; should they be nothing more than a collection of “bicycle related stuff in $SMALLTOWN”, then I would of course (fervently) advocate their deletion.
However, “if you delete this then you must also delete all these other things” is just whataboutism. Perhaps all those other things should be deleted, but let’s just start with this one - because if we don’t, then when we want do delete the next thing you will say “but what about that European routes relation, surely you want to delete that first” 
1 Like
This is why I find the discussion about categories to be of limited utility. It’s a flexible term that most of us nowadays associate with how Wikipedia uses categories (and not even how our own wiki uses categories). Yes, we can all see that “Roads in South Korea” is a bridge too far. But another network relation could be problematic for the same reasons given in the essay, even if Wikipedia would devote a whole article to it. A relation has a geospatial purpose, even though the data model technically allows it to lack an inherent geometry.
A better litmus test for relations would be whether the relation itself is primarily a geospatial feature or primarily a list of members. In other words, would an end user who doesn’t care about any of OSM’s internal implementation details care a lot more about the relation being highlighted on the slippy map than the names of its members being listed in the sidebar? If we intend for the list of route numbers to matter so much, and the map to serve as little more than a curiosity, then this is a sign that we may be overarchitecting the data for non-geospatial purposes.
According to this test, I would look askance at any network superrelation that consists of route relations, but a network relation that consists of roadways or cycling “nodes” is probably fine. route and restriction relations are acceptable because the relation’s tags and overview geometry matter more than the identities of the members. A route superrelation is also fine; it exists because one can reasonably conceive of the whole thing as a single route with a single geometry. boundary relations are no problem. After all, what we call a “boundary” is actually a territory, hence the multipolygon-like roles; we don’t normally identify boundary claim lines as such unless there’s some conflict or special history behind them.
What else would I take issue with? The speckled geometry of an associatedStreet relation, any boundary filled with subarea members, the signs that point the way to Helsinki but otherwise have nothing to do with each other, a treaty document masquerading as a boundary, a family tree relation that binds someone’s gravesite to their parent’s gravesite and to the house they died in. All these things can be informative and someone probably uses each of them for something, yet they’re all awkward fits for OSM, at best. Fortunately, vibrant open data projects exist to complement our geospatial data with non-geospatial data, designed to be orchestrated by a growing ecosystem of tools, if only we would link to these projects in already common ways.
But let’s start with a shared understanding about what makes some network relations essential and others inessential by comparison. To the extent that the E road network’s coverage area is of interest to laypeople, data consumers and ad hoc queries probably already serve this need based on route relations more effectively than any network relation. If I’m wrong about this, maybe we should be having a discussion about why the slippy map doesn’t visualize the network’s overview geometry, and how we’ve lived without it for so long.
2 Likes
I don’t mean to derail the conversation about E roads here, but thought it might be worth mentioning that similar network relations in the United States used to exist. They attempted to collect all national level highway routes by network type. They were removed since the network tag on the route relations was a more reliable source of this information.
1 Like
The network is maintained by the United Nations Economic Commission for Europe (UNECE), in collaboration with national authorities. The precise distribution of responsibilities between UNECE and national authorities is set out in an international treaty.
2 Likes
Not only that, but the community has consistently applied the same rubric to other types of networks, deleting network relations of bus routes and subway routes, for example. Apparently this is at odds with current practice in the Netherlands (and, unsurprisingly, South Korea).
The E-road network is a bona fide network – that’s why we already tag it as a network=* and network:wikidata=* of the individual route relations. network relations can exist for more specialized situations in which tagging individual elements would be impractical for some reason.
There’s relatively little need for a top-down authoritative element in the database that controls whether a route is or isn’t a member of a given network. Multiple communities have experienced that a network relation claiming to be authoritative usually isn’t, because a top-down model isn’t effective for an open-ended collection.
On the other hand, nonspatial relations have a higher barrier to entry, discouraging less experienced mappers from contributing their own local knowledge about changes on the ground. To add a new route to the network, they need to somehow find the relation ID without the benefit of our spatial tools, often in an obscure, unmaintained table on a wiki page or, ironically, in a Wikidata item. So much for simplicity.
It may be that the E-road network happens to be more stable and manageable because it can’t change without an amendment to international law (or Canada and the U.S. finally deciding to take full advantage of their UNECE membership), but that would be an odd justification for an exception. After all, changing an embassy’s status or location requires a certain amount of international diplomacy too, so most are quite stable, but hopefully that wouldn’t give anyone the idea to manage worldwide relations of each country’s network of diplomatic missions to other countries on that basis alone.
A country’s embassies are obviously not a network. They aren’t designed to – and people don’t interact with many of them in order to – gain a greater value from the combination of many than each of them would have on their own.
The E-highway network is purposefully designed to do just that. They are spaced out and numbered according to geographic coverage, direction of travel and importance (with some exceptions, as always). Someone (the UNECE) does this purposeful maintance.
I really see no argument that the E-road network is not a bona fide network… if it isn’t, what on Earth IS?
Edit: @JeroenvanderGun was replying to a comment that a network needs to be maintained by an authority, and not just a rag-tag collection of objects. The E-road network is maintained by someone. I really don’t see how embassies fit in this at all. I guess if you were objecting to the argument that a network must be maintained by someone, you should direct the complaint to @woodpeck… 
Yes, you read my mind precisely. 
My rhetorical flourish about embassies is only to point out that networks can include lots of things. We also map tag charging networks, bike rental networks, ATM networks, and so on, but unlike these networks, a relative handful of route networks have turned into network relations for some reason.
I fully agree that the E-road network is a bona fide network in a topological and operational sense. To me, that is a necessary but insufficient condition for a network relation, which comes with some inherent downsides. There are other networks for which we may have to accept those downsides because there’s no realistic alternative. Perhaps a good analogy is buildings: there is a building relation type, but most mappers would agree that it’s poor form to create a relation for every building, or every significant building, or even every 3D-mapped building.
For the E-road network, which is a route network, there is an alternative in tagging the member routes. The downside is that the canonical URL for this network begins with wiki.openstreetmap.org instead of www.openstreetmap.org, and the URL for counting the members begins with taginfo.openstreetmap.org or taginfo.geofabrik.de, and the URL for navigating among the members begins with ra.osmsurround.org.
As a thought experiment, what if openstreetmap.org could make it easier to search for elements by tag and visualize the matching elements as a locator map or heatmap? Would the network relation enjoy better or worse maintenance over time?
When I want to use an ATM, I don’t care that there is another ATM nearby that somehow relates to the ATM I am using. I want to use one ATM and that is all I need.
If I were to drive to Hamburg, I will use at least four different E-routes, and I want them to be physically and logically connected, coherent and seamless. I depend on them being a network.
For the embassies and the ATMs I don’t care if one could form a network. For bike rental I can see how multiple locations form a network that is valuable to me because I can pick up and drop off at different locations. Otherwise, their “networkness” isn’t a feature I care about.
Out of all the examples listed so far, the E-routes are the most networky network. The rest are just a bunch of things that don’t form a higher order of usefulness than their individual parts (except rental), so if anything deserved a higher-order network representation, it would be them
A router could implement this heuristic as a transition penalty based on a change in the network=* tag of the route that contains the current way that overlaps with the current routing edge (whew!). I’m not sure that knowing the Esperanto name of the network helps at all. A U.S. Numbered Highway System relation has been deleted on at least one occasion, but I don’t see how it has disadvantaged routing use cases.
It isn’t clear to me that connectivity is an inherent property of any route network or exclusive to route networks. That may be true of the E-road network because of how well-designed it is, but other route networks are very sparse. Some are only designed to connect other networks; such as the Amtrak Thruway bus lines that connect Amtrak rail lines and connect to each other very inefficiently. When I travel to San Francisco, I want to use the same payment method all the way, but a router would have to settle for matching up payment:clipper=yes on disparate route relations, parking lots, and bike lockers, rather than somehow juggle a payment method relation that includes dozens of network relations and scores of operator relations.
Usefulness is subjective and depends on the audience, and there are lots of useful concepts we don’t model as relations. To be clear, I also want people to be able to understand and interact with route networks, but I don’t view a network relation as the best tool for that. I’d only advocate for a network relation if a simpler, less abstract representation isn’t possible, whereas it seems some prefer to maintain a network relation because it’s possible, rather than consider the alternatives.
Why don’t we make OSM.org better at searching and visualizing elements by tag, to the point where it would actually be performant to find all E-road relation objects in Europe, then have a discussion about whether the network relation should be deleted?
Because right now we’re talking about deleting something that people made and like having, and saying it’s because it’s theoretically not required. How many people map for “theoretically”?
My point is that I suspect the talk of usefulness and categories somewhat obscures the actual motivations, principally that it’s convenient to not have to switch to another OSM-related website just to do something as basic as list out the routes in a route network. If this is indeed the case, then I think we have plenty of wiggle room to say that route relations are in the database as a crutch, for now, and use the existence of that crutch to build the case for better software functionality. At least mappers would be clear about where we’re heading with this idea: a future in which route network relations are unnecessary, a historical artifact, rather than a future in which mappers feel pressure to maintain them for every route network.
1 Like