The railway corridors defined by the European Commission are not routes in any normal sense.
These are broad areas where the EU has decided that strategic investment needs to create an integrated transport (multi-modal) network. They are therefore neither verifiable on the ground, nor a transport route.
The account on the the EU site states that there is a break of gauge (Spain/France or in Madrid for the AVE), as well as providing a long list of projects. It also includes several proposed basis tunnels (e.g., either side of Chambery, which will take at least a decade to be realised). If you look at the Eastern Europe corridors many are nothing much more than pipe dreams at present.
It seems to me that this is well outside the accepted meaning of verifiability for OSM, and any advantage of, say, being able to create more detailed maps of the corridor, is massively outweighed by the degree of inconvenience a massive relation creates for other mappers.
Seems like this might be an attempt to make a superroute
It does not appear this way to me. A corridor and a (super)route are
different things. It appears to me that OSM is not suitable for mapping
a “corridor”.
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.
Just because something is a lot of work to create, doesn’t mean that
that thing has a place in OSM.
While it is in there, it causes a lot of additional friction for other
mappers.
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?
I don’t think that they are the same, but if they are - i.e. describing
a generic “corridor” rather than one particular set of tracks - then
maybe their recording in OSM needs to be looked into.
“There’s other stuff that is also bad” is generally NOT a good argument
in a “I think XY is bad” discussion. There’s a lot of really bad mapping
in OSM, but we all strive to improve, rather than let the ballast drag
us down.
Considering that a relation of this magnitude and complexity is hard to maintain, and considering it is not really a route, but a corridor within which a large number of routes are possible, one might consider replacing the relation with a simple tag on the ways (e.g. something like int_ref:TEN-T=3).
Yes, something like tagging ways with int_ref:TEN-T=3might be better than this monstrosity. However, think, muse, ask yourself, ask others in OSM: “Why are components of a planned network of roads, railways, airports and water infrastructure in the European Union being mapped in OSM?” Isn’t a better question: Should OSM be mapping these?
I see OSM mapping rail infrastructure: we do this (I do a fair bit of it). I see OSM aggregating these together into route=tracks (in some countries), route=railway and route=train relations. That’s fine; we’ve been doing that almost as long as we’ve been a map database. I am MUCH more interested in whether the >18k elements in this beast are properly included in those (existing, established, well-understood by our community) relations, FIRST. But what IS this “thing?” It is one component of a planned network (in this case for rail). It is a bureaucratic planning dream. It has only bits and pieces of it that exist in reality. I see absolutely no reason to include this in OSM. When it is completed, maybe the concept of it could achieve consensus to become a super-super-relation, but that is a very big maybe. Come back and ask the community when it’s done.
@La_Voie_de_la_Raison, can you offer us such a reason? An explanation of what you believe is this “thing” to be, and a reason for why it should be in OSM? Can you answer whether its component elements are “properly” (now) in OSM’s existing rail structure relations? That should come first, truly.
I map a large national bicycle network in the USA (like EuroVelo) called USBRS. I wouldn’t dream of putting the “planning routes” into OSM. (The architects of this call them “route corridors,” as that is all they are; they are not real routes at all). Same here.
Frankly I don’t see the utility of tagging anything like the sampled int_ref:TEN-T=3 on binary 1 or 2 or 3 which I’m sure someone can pull together in some overpass query to get the picture but that is equally bound the get broken by rail editors. I’ve fixed a few rail routes, shortish in the 60-100km range that showed gaps, some looong gaps and the arbitrary rail 1 or 2 along the way and platform N in railway stations. For sure I’ve been snarked to my face by a bus route maintainer for my region “would we ever entrust…?”. Public transport co’s have phone apps, 3rd party sites like Moovit can be used to plan your route and always up to date including messaging of momentary deviation. Every new roundabout, near without exception results in broken route flags popping up. Why crowbar this 18K and doubtlessly growing buz item in and then, who’s to maintain, today, next week, year and the year after?
that applies only in case where this construct is mappable
As I understand, it is idea/project about funding/support priorities
Are specific railway tracks even assigned to it? For example what at OpenStreetMap is assigned to Baltic-Adriatic corridor? Is road bridge over railway tracks also part that corridor? What about rail bridges? What about passenger railway line bypass constructed to increase capacity of cargo line? What about intermodal terminals?
This relation in the current form is outright wrong in addition to other problems. And idea of having relations/tags that collect all important transcontinental transport infrastructure, for all such projects/plans is not viable. And current relation is outright mistaken. Ironically
is additionally problematic as linked article is not even matching.
I think it is time to ask the OP to delete the relation. Or do so ourselves.
Again, if its elements already exist as / are to be crafted as “usual” route=railway relations (with NO MORE extent than a single country), I’m OK with that and I think our community would be as well. But this beast-of-a-relation, no. It really isn’t any “thing” OSM maps.
In changeset/135032098, I comment (with two comments):
“OSM doesn’t enter overweight, difficult relations representing continent-wide planning corridors, which are actually multiple-corridor and contain spurs. OSM does make route=railway relations, sometimes at a (rail-)company-wide level, sometimes at a country-wide level. Accordingly, I’m about to break apart this almost 19000 member beast into at least five pieces, per country. The proposed and construction elements will be deleted. Still, some child relations will still contain thousands of elements and must be broken up further. I may not have the local / rail company knowledge required to further subdivide accurately, I attempt to simply make the data manageable given current tools and platforms.”
and
“I have broken apart the superroute so instead of >18k ways, it now contains six relations (one for each country).
Membership #s are:
Spain 6771 members
France 6103 members
Italy 3444 members
Slovenia 832 members
Serbia 539 members
Hungary 1244 members.
So, While Slovenia an Serbia are OK and Hungary might be “maxed out/borderline,” all of Italy and especially Spain and France will need to be still further broken apart. Let’s say to <2000 members each, as a next step.
I may have made some errors, but this is a nudge in the right direction (smaller relations that are more properly constructed to OSM standards). The job is not finished and should be continued by European mappers.”
A “going, going, gone…” last chance offering to @La_Voie_de_la_Raison (or anyone) to defend these data.
Each country’s rail subnet of real infrastructure that are what OSM truly considers a sensible route=railway, maybe. Such things seem best contiguous, not sprawling over entire countries with multiple parallel pathways. Networked or collected together as a thing?
I might see these devolving into MedNorth and MedSouth (or some such thing, I’m making stuff up) if each were contiguous and devoid of spurs. Also, I might just as easily see these deleted. They are not what OSM (usually) enters. For OSM to consider them worthy requires some defense. No defense (please speak up, @La_Voie_de_la_Raison) moves towards deletion. “These” appear to be a collection of “things that exist and things that are planned” together, and even when the components of only what are real are considered, these are both “too much” and “what?” I feel I am jumping through hoops that they might even stand a chance of surviving in some form with a more-contiguous (spurless), less-parallel bent, maybe.
We haven’t deleted them yet, they might be a learning experience, let’s see. Maybe these become some being-developed rail network, but that still feels very much like a we don’t do that (useless) “collection.” That’s not how OSM builds (especially giant-sized, hard-to-maintain…) route=railway relations.
OK, I think that is the 3rd time in a row I’ve talked to myself here; enough. I’m listening hard, everybody.
OK,
I see your point, that’s why I totally agree your decision ( the one you chose).
I also understand that’s I was too much fast.
I would ask more often for the opinion of others on this kind of initiatives (but on the French forum, of course ).
Thanks for the discuss and the sharing of opinion !
I meant Croatia where I said Serbia before, I regret my error. Anyway, this beast / monstrosity of a relation was “shown the exit.”
~4 days talking among a number of us, we “sent this blimp into the ocean,” scuttling its pieces into the history of our deletions.
Flowery talk like that, I would take my hat off if I were wearing one. Anyway, some lesson, maybe, might be “if you fly big dirigibles, make sure you know what you are doing” (first). Our data do have community standards and they and their proper structure and conventions are largely there for the seeing (wiki). Or, it is relatively “low bar” to ask somebody if you are doing something big you’ve never done before. As noted, we saw big trial blimps by this mapper before, so Frederik catching this one on his radar and bringing it here got it the attention (and gentle shoot-down) it deserved.
My French is only “schoolboy flowery” so I won’t attempt to go deep into the francophone community there. May the OP find the sort of local guidance being sought.
And may our QA tools and good filtering of such beasts which Frederik saw continue to work well at seeing these sorts of data.
We have a community of mappers (and watchers, call it quality assurance) who took care of it. Keep up the good work everyone. Maybe we learn lessons, here, but I’m nodding my head.
I have just removed two “route=railway”, “type=superroute” corridors from OSM, the 20k member 15669882 (“Corridor Mer-du-Nord - Méditerrannée”) and the 12k member 15669563 (". Both were among the five largest relations world-wide. The first had already accrued 38 versions with 800 KB XML each in its 2 months of existence, the second was at version 65 with an average of 500 kB XML each.
Adding to my thumbs-up, Frederik, I’ll explicitly state with words (as you did), “thank you, and nice job.” It is good we have Quality Assurance such as your eagle-eye for such things as these, it is good we have community discussion (and consensus) that data beasts such as these simply do not belong in our map (for reasons already discussed).
This has been an issue for rail mappers in OSM (both inside and outside of Germany) for many years. It is not easy to describe and originated in the distinct ways that Germans (especially) “group” rail elements. A route=tracks relation is an apparently “low-level” method to group rail elements (ways tagged railway=rail) into a relation (I and many others in OSM are still not quite sure how) and a route=railway relation is what I’ve called a “medium-level” method to group rail elements (ways tagged railway=rail). “High-level” is ascribed to route=train passenger-train relations.
In 2014-5, while attempting to better characterize and tag a massive 2007-8 USA rail import (>400000 km) of rail=railway, I discovered and posited (to talk- digests) that relations tagged railway=tracks were effectively superfluous for how and why we might tag rail “groupings” in USA and proposed that we simply eliminate these sorts of relations, “skipping directly to” placing the rail into medium-level route=railway relations (omitting altogether route=tracks relations). This significantly increased participation in OSM of contributors (in the USA) to the sensible entry and cleanup of our rail import, as the elimination of route=tracks relations distinctly simplified the process into just gathering into one relation (not two) railway=rail elements: put these into a route=railway relation (called a “named subdivision” in USA rail parlance) and “be done with it.”
After about a decade of doing this (distinctly avoiding using route=tracks relations), USA rail in OSM is doing just fine: no adverse affects (to overlay renderings like OpenRailwayMap, to routing, to usage of PTv1 or PTv2 passenger rail routes…) and a much “cleaner understanding” of how to map rail, as we (sensibly) use two relations to “group” (medium-level route=railway for subdivisions, high-level route=train for passenger routes). No low-level route=tracks relations, and everything is fine.
In short, it is probably OK to ignore the entry of new route=tracks relations, though please don’t actively eliminate existing ones. “Skip directly to” entering route=railway relations and things should be fine, though if you are in a country / region which does adhere to preferring route=tracks relations, you might consult with “local OSM rail mappers” who choose to do this and ask them why this extra “wrapper” of relations is needed (or thought to be needed). Maybe they can sustain a reasonable argument, maybe they cannot. If you are in such a region, and people around you cannot well-sustain reasonings to use for new relations or sustain for existing relations of route=tracks, choose to ignore entering these and just “group” rail into route=railway relations. Your mapping in OSM will be fine, the only thing that might be lost is some very exacting rail mapping enthusiast in a particular region who believes that two relations to “group” rail are required, when it has been shown over the years that only one relation is a prevalent tagging practice in OSM. (Especially in USA where I’m familiar, where route=tracks relations simply do not exist, and we have the worlds largest rail network without them and it is “just fine”).
My preference is for our route=tracks wiki to more properly state that this is a “minority tagging practice only found in certain parts of the world, particularly Germany.” That’s more truthful / accurate than continuing to confuse people that route=tracks relations are “needed,” as it has been proven they are not. See Tag:route=tracks - OpenStreetMap Wiki where at least the distinction between Germany and the United States is clearly stated.
It is well-established (in this thread and elsewhere) that relations of this sort do not belong in OSM.
There are DWG practices of removing both Vandalism and data such as these relations. However, especially when polite, taking-reasonable-time practices (like the changeset comments noted above requesting deletion), other OSM Contributors are able to properly perform these deletions as well. I do stress that you really must have “the force of what is good and right” (found in this thread for examples of “railway beasts” such as these), you really must use polite and patient practices like engaging in good dialog with the author of such data, and you can use either an OSM editor (JOSM, etc.) to remove the offending data, or you might use more powerful redaction tools (like reverter utilities).
These are “more intermediate, perhaps advanced” activities for any OSM Contributor (to be acting as a sort of “data police” like the DWG do), but when “the force of what is good and right” is on your side, you engage in polite and patient dialog, and use editors and tools to eventually remove the offending data (if the original author does not or will not), OSM becomes a stronger, more accurate database. It’s good to get more-public feedback (as here, as now) before you do this, but in this case, it is clear that the data entered by @La_Voie_de_laRaison can be correctly removed, as he has been instructed (here) that these kinds of data relations are inappropriate and unwanted data in OSM.
).