No, this is not a ‘category relation’ (like the Footways in East Anglia example) but a valid network relation which represents the E-road network.
It represents an existing real-world network, not a category of routes which a common property. You didn’t give any reason why it wouldn’t be a correct use of relation:network.
It represents an existing real-world network, not a category of routes which a common property. You didn’t give any reason why it wouldn’t be a correct use of relation:network.
can you explain why these relation:network are not category relations which could be avoided altogether by tagging the same “network” value?
A network is a coherent group of routes, nodes or other entities, that forms an actual geographic entity, in this case the E-road network. Note that relation:network is a valid, in use relation type.
That contrast to the category relations from the Relations are not categories page. Those to be avoided category relations are groupings of items with a common property, like categories at Wikipedia. Examples from the page are ‘Footways in East Anglia’ and ‘HSBC ATM machines’.
The properties of the network itself can be added to the network relation. This is only possible with the network tag, when you’d use network:* subtags on all routes within the network. I don’t think it’s desirable to move the circa 30 values from the E-road network relation to all route relations.
I don’t see any use for a relation like this. Just add network=International European route network and network:wikidata=Q106123 to each of those e-road relations, and nothing of value would be lost. If you want to add other properties to that network of roads, add them in Wikidata or Wikipedia.
It’s certainly in use, but I don’t know that it’s a good idea in this case. A network relation is a good idea when a network is discernible on the ground but individual routes are not. Calling the E road network a geographic entity is a little bit of a stretch. Taking the logic further would result in a continent-wide situation like we have in South Korea:
Taking it even further, someone has created a brand relation as an alternative to tagging brand=* and brand:wikidata=* on each shop in the chain. I’d have a hard time seeing how it’s a category whereas the E road relation is a geographic entity.
Most of the tags indicate the “name” of the network in various languages.[1] Most route networks have no single, formally set name, just a description, which is why we normally set network=* to mnemonics and abbreviations. Some maps like OSM Americana do have a use for the “names” of networks, but they can get this and other geography-adjacent information from Wikidata:
Some of the names, including in English, are incorrect. Someone expanded “E” to “European” out of a conviction that abbreviations don’t belong in the name, but as far as I can tell, UNECE always calls them E roads. ↩︎
But why not network=Międzynarodowa sieć tras europejskich or network=Avrupa E-yolları? Being able to put in names in different languages without having to prioritize any language is one of advantages of the relation. Unless you’re OK with only network:wikidata=Q106123 with no network tag?
Fortunately, road networks are normally tagged with machine-readable keyword identifiers like e-road, which unsurprisingly use British English to a limited extent, instead of human-readable freeform names that would need to be localized directly in the database on each occurrence. A data consumer can find the network’s name, route name format, route number format, shield color, line color, designating authority, Esperanto Wikipedia article, German National Library bibliographic control code, etc. by finding the network=* identifier in an external lookup table or by looking up the network:wikidata=* QID in Wikidata.
A network is a coherent group of routes, nodes or other entities, that forms an actual geographic entity, in this case the E-road network. Note that relation:network is a valid, in use relation type.
note that “in use” and “valid” are not necessarily the same, the KISS principle obliges us to choose the simplest representation, and to refrain from using relations where they are not required.
Speaking about the 30 properties that supposedly are tagged on the current E-routes network relation, I suspect most of them are not adding something indispensable, but I am open to listen and be convinced from the contrary, if there are arguments
I don’t think it’s simple and according to the KISS principle to move information to an external third-party database like Wikidata. And the OSM Americana example of @Minh_Nguyen shows this leads to a very inconsistent legend, with sometimes the name of the road type, sometimes of the network and sometimes the name in another language. This is also inconsistent between the English and Dutch legend.
All kinds of networks have been mapped as relations in OSM: hiking networks, cycling networks, public transport networks and road networks. This allows for:
a place to store information about the network
easy navigation between routes within a network
clear overview of missing routes and the possibility to retrieve history for routes
These advantages of network relations are gone by deleting them. I don’t understand why these kind of relations are bothering people and I don’t see any advantage for deleting them. If you don’t use them, don’t use them, just like any other feature in OSM.
And no, networks are not categories. The page Relations are not categories is about Wikipedia-like categories, where every page needs to be in at least one category. Nothing on that page stretching the definition towards actual geographic entities, like network relations.
I can see that this is a corner case, but it will invariably be used as a reason to map all kinds of pseudo “networks” like “the network of hiking trails of county X” or so. It appears to me that the tags of each individual member already sufficiently specify the membership so I don’t see the necessity to add this relation (just to add 25 translations of the name? are we a translation database?). I’m in favour of deleting.
The international E-road network is obviously not a “psuedo network”.
As a general note, I’d like to remind everyone to resist the urge to (advocate to) delete objects added by other people just because you don’t see the value of mapping these objects as such. Deleting unpopular objects without solid rationale (or arguing in favour of doing so) is really bad for the long-term health of OpenStreetMap as a community project, because this ensures that any contributions can disappear at any time in the future whenever they are no longer deemed worthy.
The question whether this is a category instead of an object is understandable, but I think this has been clearly answered now. Arguing that an object has few tagged properties (yet) or that its properties can also be found on other databases like Wikidata is a rather poor justification for deleting said object.
A category couldn’t have a Wikidata entry. A network could.
The canonical examples of “Footways in East Anglia”, “Scottish Lochs”, and “HSBC ATM machines” (per the Relations are not categories wiki page) don’t have Wikidata entries. To my understanding they couldn’t have: Wikidata’s first-class members are identifiable objects or concepts – not collections of objects. There is a Category:Countries in Europe - Wikipedia but there is no Q-item for “countries in Europe”.
Międzynarodowa sieć tras europejskich does have a Wikidata entry: Q106123.
If we’re concerned about storing data that is not indispensable, I personally would start with the gigabytes of stuff added by NSI (brand, brand:wikidata, brand:wikipedia, name, operator all with more or less the same data), not thirty name tags on one relation
Yes, the labels in the legend can get very inconsistent, mainly because there are no standard names for many of these networks in the real world and Wikidata doesn’t enforce naming conventions as rigorously as Wikipedia. Inconsistency can even arise within a single country in a single language, but it’s an accurate reflection of the real world.
If OSM were to come up with its own standard nomenclature for route networks, an application developer like me might appreciate not having to polish up the names myself. But that would be tagging for the renderer.
Luckily for aficionados of network=e-road, it does have a formal name: the international E-road network, réseau international « E », or дорог категории Е. Is OSM instead calling it “Europastraßen / International European route network / Routes européennes” out of deference to common usage, or are the majority of tags on this relation merely descriptions? And why doesn’t name=* include all three of the AGR Agreement’s official languages or all the languages of the signatory countries?
While this is true, only a tiny minority of hiking/cycling/public transport/road networks have been mapped as superrelations, and deliberately so. There should be a distinction between a network of well-defined routes versus a web of unstructured paths branded as a network without any distinct routes inside it.
You might consider this to be the case because, in OSM’s data model, a relation declares its members rather than the other way around, making the network relation a central hub for information about the network. Unfortunately, by the same token, this relation is bound to become incomplete as eligible routes are added and changed in the usual manner by mappers oblivious to the implicitly relevant network relation.
associatedStreet relations suffer from the same problem. By your reasoning, there should be a single master element responsible for encoding the street’s names in all the addresses along the street, especially in a multilingual region. But community after community has come to the same conclusion that the downsides outweigh the upsides.
It’s a fundamental problem of any relation type intended to collect an open-ended collection of features. I don’t consider the E road relation and North West Street to be Wikimedia categories, but they are lists, and lists are not one of this database’s core competencies. A relation needs a stronger justification than the fact that the members share some attribute in common.
The good news is that the data model provides for an element to refer upwards to a broader concept, via a humble tag. A network=* tag may not be very good at managing ancillary details about the network, and getting every instance of a tag will require a relation search or other query. Still, it does its simple job well in establishing an unambiguous relationship between the route and the network.
brand=* is there as a concession to those who want something more self-explanatory than brand:wikidata=* when viewing raw tags. And of course, as soon as there’s a brand=*, there’s also a brand:en=*, brand:fr=*, etc. to accommodate multilingual regions. Go ahead and delete them, I double-dare you.
NSI never should’ve added brand:wikipedia=* and finally stopped adding it three years ago. The U.S. community decided to eliminate this key last year, and ideally other local communities would follow suit.
When NSI adds name=*, it’s either a placeholder for a more specific name if known or a coincidence that the brand’s locations are also known by the brand’s own name. There isn’t a blanket rule.
In general, NSI as it’s currently architected should not be enforcing the addition of brand=* and operator=* simultaneously. Contributors to the project are advised to choose one or the other.
The irony here is that if you click on the link to the German wikipedia article it will tell you in the first sentence " Europastraßen sind eine Straßenkategorie von Fernstraßen." (European routes are a category of long-distance streets.)
Looks like even Wikipedia isn’t quite sure if they are a category or not.
Personally I’d be in favour of deleting most of the network relations, be that for roads, hiking, cycling… They mostly seem to be there to add information that is only marginally related to geographical information. At some point we simply need to draw the line or we end up duplicating all of Wikidata using OSM relations.
The UNECE, the UN commission in charge of the network, calls it E-road network. I don’t think it’s relevant how Wikipedia editors call it.
Network relations have been used for over 10 years and are useful for people. I’ve only seen a slippery slope argument in favour of deleting them: if we map networks then relations for all kind of categories will appear. All those years of years of network relations existing have shown otherwise.
