Railway "superroutes"

Someone has created an object in OSM for a “mediterranean railway corridor”. This relation meanwhile comprises 18k members. It all started a couple weeks ago here: Changeset: 135032098 | OpenStreetMap

I think that this is a classic case of “wouldn’t it be great to have an OSM object to match this Wikipedia article” and I think it should be deleted. In case you cannot retrieve the object through the web site due to timeout, here are its current tags:

  <tag k="name:fr" v="Corridor Méditerranéen"/>
  <tag k="network" v="RNE"/>
  <tag k="ref" v="RCF 6"/>
  <tag k="route" v="railway"/>
  <tag k="type" v="route_master"/>
  <tag k="wikidata" v="Q2895444"/>
  <tag k="wikipedia" v="fr:Corridor méditerranéen"/>

Firstly, the wiki page describes a general “corridor”, while the OSM object describes a very concrete collection of railway tracks. There’s a conceptual mismatch here. I don’t see how this is verifable at all. Imagine standing with another mapper at a small railway station and arguing which of three tracks should be the one that is part of the mediterranean railway corridor?

Secondly, as is the case with all such huge relations, any time someone makes a small edit to a piece of track along the way that splits or unions two ways, the relation will receive a new version and that user will have to upload another 18,000 member object to OSM which will be integrity-checked by the API - this makes editing slower and will, in a short time, create hundreds of new relation versions.


Thoroughly times out on my computer… unviewable. This is in browser with the standard Carto map. Tried in JOSM asking for all members as it initially shows as loaded ‘incomplete’. Same, times out. Yes you can add members piece by piece and now it’s a major pain to anyone who ever is going to try to change an element anywhere along the rail route.

Corridor: A railway corridor is AFAIK the area reserved by the railway companies upon which the rail, stations, emplacements etc are positioned. I’ve mapped a view miles but only as filler in urban areas some stretches with sound barriers, the local vary from 4 to even 6 meters high.

Is there even a way to view this relation somehow and what is in it?

Based on description here, and on assumption that it is complete and accurate: I support deletion.

It seems to be case of Relations are not categories - OpenStreetMap Wiki (category:rail tracks related to Mediterranean Corridor EU project)


Is there even a way to view this relation somehow and what is in it?

Based on description here, and on assumption that it is complete and
accurate: I support deletion.

I agree with that assessment.


Isn’t that supposed to be mapped with landuse=railway?

1 Like

Yes and Yes (to meet the 10 char minimum post length)

Edit: An example Way: 60133623 | OpenStreetMap
with the noted sound barriers:… wall=noice_barrier
Way: 877933599 | OpenStreetMap

Seems like this might be an attempt to make a superroute. Give the 300-member suggested limit for relations; a type of super-relation seems necessary. I would not recommend deleting this before an extensive discussion with the user since they did in fact put in the hard work to make it and it only takes a minute to delete.

There are plenty of other large railway superroutes that also fit this description: TransSiberian comes to find, TransCanada also? You wouldn’t just delete those would you? How about the Appalachian Trail or PCT?

1 Like

Seems its not be their only huge relation. I very briefly looked through some of their changesets and also found some other big relations.
https://www.openstreetmap.org/relation/15748490 2500 members
https://www.openstreetmap.org/relation/15748559 2371 members

There is also this one, which will not load for me on Chrome, so I can only assume its big. https://www.openstreetmap.org/relation/15669882
Found it in this changeset Changeset: 135030883 | OpenStreetMap

Question is: is there anything on the ground that makes this a geo-mappable object? Any sign saying: this railway is part of the … Corridor? Or Welcome to the “… Corridor”?

First I just want to say that I m the creator of this object, and I not english.

There are a lot of questions, a lot of problems, and I will answer them all before a decision is made.

First, the fact that this relation have 18k members is not at all an exeption. For nationals boundaries, for exemple.
And I never see that the size of the relations are a problem !

Next, for know wich track is part of this corridor, normally I put a source on the object. A source who come from creator of these corridors : the european union. But I see that @woodpeck didn’t mention it, so it’s possible I forget it. In this case it’s easy for me to find it again. So, for railways who have more than one trak, it’s all of these who are a part of the corridor. But I agree with you that for railways nodes, that’s not very precise. For this particular case, normally each trak of these railways nodes (stations, yard, …) are a part of the relation. But that’s a very long and hard work, so that’s why I did the most I can.

For the historical of the relation, it’s inavitable, but that’s not the first case in OSM : I take here again the example of national boundaries.

The corridor definition :

You say this, but the mapping for these objects are :

The corridors I talk are a route.

Yes. I don’t know if you know, but they are 9 european fret corridors. So I mapped totally three of them, and one partially.

So, sorry to say that, but if we begin to think like that, we delate too a lot of things, like the mountains range because they are not precise boundaries, or flixbus route (they are underds of this type of route in France), and I can give a lot of others examples.

mapper was asked at Changeset: 135032098 | OpenStreetMap

Yes, and I replied


I’ve been mapping railways in OSM for at least a decade, including collaboration and consultation with other mappers both in my state (California), country (USA), an author of OpenRailwayMap (several excellent internationally-viable overlay layers for OSM rail data), dozens of state-level rail wikis, our US national rail wiki, a “North American” rail wiki and an SOTM-US “Lightning Talk” I gave on rail.

In the USA / North America, we have similar rail “agglomerations” in a large / long sense, but our “structure” of rail as entered into OSM differs slightly from that in Europe, especially Germany. Briefly, Germany and parts of Europe (last I checked) use three types of relations to aggregate rail, route=tracks, route=railway and route=train. In the USA and North America (and other parts of the world?) we use three also, but different ones: two mostly and one rarely. (The rare one is a super-relation of routes). We conflate route=tracks into route=railway (never using tracks), so route=railway become what in the USA are known widely as “Subdivisions” (of rail routes), and we of course also use route=train to denote passenger rail routes. Additionally, we (rarely) aggregate a collection of subdivisions (route=railway) into a super-relation of route=railways, calling this a “Major Mainline Rail.” Examples include the Northern Transcon(tinental) and Southern Transcon, in addition to “regional corridors” like Crescent Corridor and Mid-America Corridor (“large freight corridors” as I believe you mean). See United States/Railroads - OpenStreetMap Wiki. After many years of most of a continent “doing” rail like this in OSM, we don’t see any problems (displaying, routing…rail elements or relations) with eliminating route=tracks relations. Really, this is about harmonizing “how a country” (or so) crafts rail into “routes” and aggregating these into data structures that are agreeable to OSM, its systems and its data authors (volunteer contributors). This has evolved over time, and like I say, differs a bit from country to continent, but you certainly have conventions in doing this where you are mapping.

Accordingly, because of this hierarchy of relations, USA’s rail relations contain sensible numbers of elements (railway=rail). They aren’t all <300 elements, (some rarely go to >2000 or more, we try to minimize these), but 18K is simply too big.

I think something like a sensible super-relation is what the OP is trying to get at. Rather than 18K members (an anomaly for any rail data in OSM), @La_Voie_de_la_Raison likely wants to follow his country’s/region’s “rail relation aggregation conventions” and make a sensible super-relation (or nested set of them). OSM has the super-relation data structure for precisely this reason (among others): so that “base level” relations do not get completely unwieldy (18k is unwieldy). We might have relations of relations (a single-level super-relation) and there are double- and even triple-level relations (of nested relations). But in my opinion, such nesting of relations shouldn’t go any further than three or four levels at most.

@La_Voie_de_la_Raison, saying that a national boundary has a large number of elements in the relation is a poor analogy for this: boundaries are quite static data structures in OSM and have other oddities about them (like they are often invisible and directly-by-eyes unverifiable). Nonetheless, we must put them into our map, as a global map without national boundaries wouldn’t fly. But for rail data, countries, rail companies and those responsible for classifying and aggregating the rail find “manageable methods” to craft the pieces of rail together so they don’t need to include 18K members at a single level.

@La_Voie_de_la_Raison, please explore how your country / continent aggregates rail into various levels of relations and super-relations and abide by those conventions. You might continue to do that here in this topic / thread, or you might consult with your (more-local, regional/country-wide) wiki on how rail relations are properly built around you in OSM.

Edit: One more thing (which both is commonplace and might make things easy): for all kinds of routes… road, bicycle, etc., breaking apart the route at a state or country boundary makes a lot of sense. You might find that simply placing the 18K of elements into “single country relations” and then collecting those relations into a super-relation suffices to simplify what you are attempting to do. But again, do try to abide by “local/regional” (country, continental) conventions for how rail is structured in OSM.


The railway wiki says…

" Use landuse=railway to map areas of land used for railway transport (commonly known as the railway corridor ): the area dedicated to train operation or support, around tracks, yards, sidings, station complexes, and ancillary man-made objects along the tracks.

The language as used by your source is not compatible with OSM and has to be translated into OSM functionality.


1 Like

I’ll take that as a no.

What use is made of the collection relation? Is there any software actually using it, or is there an app to explore it, a map showing it, a router using it for routing?
If not, what use could imaginably be made of this kind of relation?


This question is not always as easy to answer as it appears. For many years, mappers (I speak of the USA, where I am familiar with rail mapping) have aggregated rail elements (railway=rail) into relations (type=route, route=railway) using sensible methodologies, such as “that’s how the railroad company groups these elements into what they call a named Subdivision” (of rail).

There are “overlays” (software which are not quite renderers, but which display rail routes and other attributes) like OpenRailwayMap. These show such Subdivision names (and other tags on rail elements) in a way that someone curious to look at a rail network would find dataful and informative. But to ask “what use is made of the relation” doesn’t always have a clear answer, as the use cases can vary. Some might choose to do imaginary or realistic routing. Some might build different (route=train) relations upon these (physical infrastructure) route=railway relations. But such route=railway relations are a real-enough data construction in OSM to be correctly entered. Unless and until, like here, they become unwieldy with their number of elements. Then, regional conventions properly aggregate these into more-sensible data structures with reasonable numbers of elements, like super-relations of route=railways. OSM knows how to do this, what isn’t clear is whether the OP does and is following (Mediterranean-area) conventions on how OSM categorizes rail relations.

It isn’t common at all for “Welcome to the Mid-America Corridor” signs to exist at the beginning of such a rail aggregation. These sorts of data structures (route=railway relations, super-relations containing them…) are useful to rail professionals, “rail fans” and the like, they are worthy of being mapped in OSM, but using conventions that make them palatable to the wider OSM community. 18K elements in a relation does not qualify as palatable, so the relation will need to be modified so it does.


Additionally, the author @La_Voie_de_la_Raison has tagged this nearly 19k-member route (!) with type=route_master, which isn’t correct for a relation containing railway=rail elements. Such a relation (type) should only contain other relations.

First, all 640 railway=construction members should be removed (and put into another relation). These do not belong in an “active rail” relation. Likewise for the 166 railway=proposed ways, some of which even contain “rejected proposal” in their name=* tags. Still, even doing both of these means the relation would contain >18k members.

As the data span the countries of Spain, France, Italy, Slovenia and Hungary, at least five relations should be constructed, one for each country. These relations can remain in the existing “vessel,” the existing super-relation (relation/15737801). BTW, I can only edit this with my JOSM editor, and I use a command-line directive to offer it a generous 4 GB of heap space: not everybody has the Random Access Memory do that. And nobody should have to, as a >18K-member relation is ridiculously too large.

Even within these five “countrywide” relations, it is very likely that one or more countries has 4k, 5k or more members. Each of these should be broken down into further smaller relations (ideally only a few hundred members each, although 1900 members is gaining ground as a community consensus as a maximum number of relation members, which, while it will offer sluggish performance for many users, will not simply cause things to “shut down,” as one with 18k does). Such further intra-country splitting of relations into smaller versions might best happen at either sub-national boundaries (approximately admin_level=4), or at logical places in the railway network where these boundaries “more naturally” occur. These are often found at large rail yards, passenger stations, wyes or termini.

So, @La_Voie_de_la_Raison, you have your work cut out for you. You can elect a better, more locally/regionally harmonious method by which this relation is properly broken up and meets OSM’s conventions for well-formed route relations, or the community will do this for you. I urge you to consult with other OSM rail (human) editors in greater Europe, as if you had done that first (or you had consulted wiki on well-formed rail relations), it/they would have steered you to well-formed data structures in our project. As it stands now, this “railway super route” is a malformed version of such a thing, and this must be remedied. It isn’t even a single “corridor,” as it has parallel segments in Spain, Slovenia and Hungary, and spur routes in Italy.

According to your source (https://transport.ec.europa.eu/system/files/2017-06/mediterranean_map_0.pdf), this appears to be “something,” but whatever it is, the OSM community has not (yet) developed a data structure for it. Or if we have, the relation you built is (quite) incorrect. Please, discuss with your local/regional community how to best create such structures in OSM, as what you have entered is not acceptable to the (wider, worldwide rail-editing-in-OSM) community.


For the size of the relation, I recognize that I found too that become a problem. That’ss why, for the corridor Rhin-Alps (that I didnt finish yet), I cut the relation in several ittle relation, like this one.
I understand your point, and I’ll find the european cutting and apply it.

If this relations are important, that’s because each trak on this corridor can have more thant 50% of subsidy from the european union for every construction. So that’s why I get the psoposed and contruction railway in these relation.

Is it even route=railway?

It seems to not be line taken by specific passenger (or even cargo) trains, it just appears to be classification of important railway corridors.

See Tag:route=railway - OpenStreetMap Wiki - as I understand it that is for specific railway routes.

1 Like

Yes, @Mateusz_Konieczy is correct: the best outcome here would be for all the 18000+ individual rail=railway elements to be in proper route=railway relations (smallish, no more than a few hundred elements each), whatever those are defined to be in the context of the five countries where this “thing” is. Then, these can be “more properly aggregated” as individual route=railway relations into the super-relation you (and the EU) appear to want to “glom” together into a “something.” It might even take “two levels” of super-relations to do this: perhaps one for a set of route=railway relations in each country, then an aggregation of each of the five country’s relations in the “super super-relation.” I honestly don’t think what ever you and the EU are trying to make is a real thing that OSM wants to denote, as it seems like a political data construction, not a “rail” data construction. I might be wrong about that, as I’m not completely familiar with how the EU and countries in it “aggregate” rail. But I have helped the Swedes do some of this, given my USA perspective, (and experience with using usage=* tags and route=railway aggregation as we do things in the USA, which they appeared to initially find helpful, and I have since stepped away from that with them and they are now crafting their own rail networks and sub-networks). Sometimes, all that is needed to “best” construct rail networks in OSM is an initial nudge in the right direction. What it appeared @La_Voie_de_la_Raison did was start too much at the EU-defined “top-level down” method of building this, rather than a “bottom-level up” method: starting with smaller, country-specific, railway-specific route=railway relations, and building UP from there. That approach still seems like the best way forward here, in my opinion.