Once I can get a list of all network=e-road relations in Europe within OSM.org, I personally agree the network relation won’t be crucially necessary and if people want, it can be deleted once the route relations also receive a network=wikidata tag
Another issue is that these other websites are not easy to discover and I expect a lot of people plainly haven’t learned about them yet, because how would they? E.g. I’ve been doing OSM for better part of a decade and I only recently checked out what “Who Did It” is, where I can find it, and that it’s the History tool I’ve been wishing OSM.org would have.
Speaking of E-routes, is there a reason the E-routes in Norway are not tagged with network=* and are not part of any route relation? In light of this discussion, this seems contrary to “the rest”.
I think one of the main benefits of a relation is that it makes membership explicit and holds it in the history. If someone would delete a relation that is member of a network relation, you could see it from the history of this network relation, i.e. some kind of monitoring is made very easy with this approach and you see also right away who was it and when (on the downside, you have to find the relation and add your route explicitly, so there’s always the risk that the network relation is incomplete), but not all of them (if the member route is vandalized by removing most of its members, for example, or adding wrong ones, you would not get a hint from the network relation).
Sorry, typo. I meant network:wikidata key, meaning network:wikidata=Q106123 tag.
Yes, this would be in addition to existing network=e-road tags on the route relations. The purpose of the extra wikidata tag would be disambiguation in case there are any other e-roads out there, and explicitly linking the network to its machine-readable wikidata.
All this chat and you’d think that someone would have removed the way that a relatively new mapper has added to the superrelation
I’m not convinced that this is more worth of a network relation in OSM than (say) trunk roads in Mongolia, but if it exists, and someone wants to maintain it (see comment above…) fine.
Whether the individual routes exist on the ground everywhere is a different question. In some places (e.g. Sweden) the signage is the main one used, in others it coexists with national signage and in some places (at least the UK) it generally does not exist at all.
I think there’s a misunderstanding that may have affected the discussion. network=e-road is not intended to be a plain-language name of the network. For road routes, network=* is set to a unique identifier that the OSM community came up with. Other examples of identifiers include FR:national, jp:prefectural, CA:QC:A, US:US:Truck, and US:OH:SAN:Fremont. Apart from international networks like the E-roads and Asian Highways, these identifiers are namespaced to ensure uniqueness.[1] Data consumers use custom lookup tables, data items on the OSM Wiki, or Wikidata to associate these identifiers with the metadata they require – metadata that network relations do not and cannot provide.
network:wikidata=* is well-established, but it’s only used on non-road routes, such as public transport routes, where network=* has historically lacked namespaces and thus can be very ambiguous. This approach requires a system like the Name Suggestion Index to keep the network=* and network:wikidata=* in sync. NSI has discussed aligning road route networks to other kinds of route networks, mainly for its internal architectural needs, but there hasn’t been as much demand for the Wikidata QIDs outside of this project.
In other words, there’s currently little or no need for extra disambiguation, but you’re advocating for both network:wikidata=* and network relations so that we’d have three redundant systems of disambiguation. While I share your enthusiasm for Wikidata, I think this triple-triplicate approach would serve as a distraction.
Another prominent exception is BAB for German Bundesautobahnen. ↩︎
Changeset: 164168488 | OpenStreetMap fixes that problem, though the name=* remains inaccurate, at least with respect to the source that was given earlier. I’d fix it myself but hesitate to change a French name and remove a German name from a network relation that possibly touches French- and German-speaking countries. (I think? Can’t tell from the relation page.)
I can see the appeal of this. On the other hand, membership history is invisible when looking at the members themselves. If Route 100 used to be a member of the Network A relation but is now a member of the Network B relation, this would not be visible in the Route 100 object history. A tagging change from network=A to network=B would be.
Yes that is not a problem. The problem is finding relations that the object used to be a member of but is no longer (due to vandalism or whatever else).
AFAIK you have to look in the history then (i.e. crawl the relation history looking for the way or relation as a member). Clearly not comfortable (until someone sets up a specific service)
An extreme case is when someone deletes a route network relation for some reason. The deletion essentially leaves no trace. The changeset lacks a bounding box, because a superrelation has no geometry as far as the API is concerned. This makes it invisible to any history feed that filters by geography.
If you want to find the relation later on without having spotted the changeset, the API won’t help you. You’d think this would be a job for an Overpass attic query that starts at a former member and recurses up to the network relation, but I couldn’t get it to work within reasonable time or memory constraints.
For this discussion, my only options were to search OSMUS Slack for off-hand references to the relation (which was time-consuming and a matter of luck) or find a stale reference to the relation in the network’s Wikidata item (since nothing currently synchronizes Wikidata’s OSM links with OSM).
My advice to those who care a lot about these route network relations is to make sure Wikidata links to them for safekeeping. Good thing no one here has qualms about being so dependent on an external project.
This is a more general issue with superrelations, of course, but probably a bigger issue with more obscure relation types that are less likely to be discussed and linked from elsewhere, especially because of the lack of geometry.
(OpenHistoricalMap is familiar with this problem, as the chronology relations I helped popularize can also lack geometry if the members are relations. But there we view it as a tradeoff because there’s no other way to affirm that multiple features are the same feature across time, short of creating a Wikidata item for the most minute of features. We understand that this relation type isn’t spatial data – it’s spatiotemporal data.)
Out of curiosity, I had a look at the state of relation listings on the OSM Wiki. From what I can tell, the wiki isn’t a reliable tool for tracking network relations by either live or dead links, but it may be more useful for some other relation types.
route_master relations were by far the best represented on the wiki; restriction relations were the worst represented.
The 36 valid network relations mentioned on the wiki represented 0.8% of all network relations in the database. All but one consist of route or route_master relations. They range in size from Fietsnetwerk Land van Peel en Maas, a node network connecting 352 routes, to Quiberon – Navette et Quib’Bus, which consists of a single parking shuttle bus. (I’m not suggesting that node network relations be dismantled.) The E-road network relation in question does not appear anywhere on the wiki.
Among linked relations of any type, 354 (about 3%) remained on the wiki despite having been deleted at various times ranging from June 18, 2009, to March 12 of this year.
Indeed, parts of 14 E-roads in Norway are absent from any E-road route relation. To date, Norway has largely avoided modeling any highway routes as route=road relations, other than some touristic routes and named streets. That said, there are 16 E-road route relations in Norway. Twelve of them are tagged network=e-road directly, of which only four are members of the E-road network relation. Four other relations belonging to E 134 carry no network information.
Last I heard, the Norwegian community considers route relations wholly unnecessary. Proponents of the E-road network relation will be mortified to learn that the local community wants to delete the E-road route relations too and has done so previously, so that data consumers would need to go back to maintaining country-specific logic for parsing ref=* tags on ways.
This is a Wikidata entry for the category pages on other Wikimedia projects. It’s used to create interwiki links between e.g. English and French Wikipedia. Similarly, Wikidata also has entries for OSM keys and tags.
It’s not a “category” in the Wiki_pedia_ sense in that it doesn’t actually link to or define or contain the countries themselves.
Agreed. The question is merely about what is a category
Yes, but I didn’t say “in some way”, I said specifically:
And while you could use Wikidata claims (properties) to construct a list of “footways in East Anglia” which would be like a category, there’s no Wikidata entry (with a Q code) for “footways in East Anglia”.
