It seems fairly uncontroversial (I could be wrong) that the ruins of things are customarily and appropriately mapped in OSM. You or I or the vendor at my local popcorn stand could easily be at the site of the photo below and say “yes, these are certainly the remains of a rail line.”
(photo from railway=abandoned wiki page)
The area of controversy is in the margins of discernibility when it descends into various degrees of “an expert is needed” down to “there’s nothing here anymore but I’m connecting the dots across redeveloped land”.
Nothing sinful at all. But if you’re rating things as to how observable or inferrable they are, as was discussed upthread, much of the USBRS is unquestionably less observable than the railway remains being discussed here.
An example I plucked at random: Way: West James Lee Boulevard (86128531) | OpenStreetMap has a lot less “current bike route” about it than Hook Norton Viaduct has “dismantled railway”. No signage; no particular cycling facilities. It’s not really a bike route on the ground, it’s a bike route on someone’s (official) maps.
I don’t have a problem with that! By and large I don’t tell other people what to map. Indeed, I’ve occasionally mapped proposed bike routes in the UK where the opening (with real signage) is foreseeable but hasn’t happened yet.
But if we’re saying that OSM’s criteria for inclusion are that (as Minh put it) something should be observable or inferrable (“up to a point”), things like most of the USBRS - and the other examples I quoted - are less observable and inferrable than a lot of the railway=dismantleds out there.
I don’t have any particular insight into OS’s cartographic decisions! But I think it’s a mix of “traces on the ground” and “older OS edition”.
A quick scan through a few former railways I know well suggests that the depiction largely disappears in urban areas where the trackbed has been built on, but is significantly retained in rural areas, probably more than OSM’s railway=abandoned is. It’s not a direct comparison, though, as the “classic” 1:50k and 1:25k are essentially just drawn cartography rather than the output of a database. (They’re available as a layer on Bing Maps if you’re interested.)
How about simply downgrading the railway=razed/dismantled from “primary” to “attribute” tag status instead of deprecating it completely. What it would mean is that you can still use these tags but only as an additional tag on a existing feature that is clearly observable on the ground for everybody.
In practical terms it would mean that it is very much okay to delete lone ways with just a railway=razed tag going straight through a supermarket. However, the same tag on a cycleway or tunnel or cutting needs to be left alone. Would that be a definition that captures the concerns of both sides?
The suggestion goes somewhat in the same direction as was:railway=yes but it has the advantage that it only needs a wiki change. No retagging, no changes for data consumer.
Been following with interest & must admit to pretty well agreeing with Zeke’s options ^
One question though.
OK, so a railway used to run through here, but it was closed down & the rails ripped up many years ago - in the case I’m thinking of, about 60 years ago! The easement stayed there though, as a clear path through the surrounding --bush-- (that’s supposed to be a strike through! Can we please get full editing options shown!) woods, & (it would have been!) shown as a railway=razed in OSM.
However, a road was then (40 years ago) built along part of the railway easement, so it became highway=secondary + railway=razed.
Over the years since then though, that road has been upgraded to a primary, then a trunk & now a motorway! So should it still also be tagged as railway=razed, because yes, once upon a time, it was the alignment of the main railway servicing this area?
When do we decide that old railways are now too old for OSM?
The problem is here that it would become valid to add this to roads that by accident or not align with railway that is now gone without trace.
And dealing with it when road is rearranged.
Cutting that used at exist at this location is not mappable - even as road attribute. Because it is utterly and completely gone, with only traces being maps in archives and maybe some influence on road layout (but decisions of kings that lived 500 years ago also had influence on that, it does not make them mappable either).
I think this is interesting, but we may not have tags to describe some of the features if not as remains of railways, e.g. how would you describe a track bed where the rails have been removed and only the ballast remains?
Does it really matter in the grand scheme of things? It’s just another tag on a highway way. As long as a railway enthusiast doesn’t start moving the road to a wrong location to align with the former railway instead of the current road, I’m all for “live and let live”.
if it is not by accident then why should it be disputable? Those handful of cases where a road “by accident” aligns with a former railway, however this should be determined (maybe if the railway was razed, there was something else in the meantime, and the road was rebuilt and by accident aligns with the former railway?), are likely not worth the discussion.
Yes, as it changes our policy on mapping completely gone historical features.
And it will likely result in further slippery slope. And weakens our position on “on the ground” policy for other things, such as country borders.
Also, if we give up here - then we will sooner or later have two railfans arguing which and how long gone railway should be mapped. With it being impossible to decide by survey.
Or people mapping long gone rivers (which also may follow path of current roads, some were build by filling old river branches).
And I do not want to be obligated to care about nonexisting long gone railway when I adjust path of actually existing features such as roads, paths or streams.
(OT but) It works for me in the UK, because I replace Humanitarian map tiles with ones from map.atownsend.org.uk. That does show different sorts of “previously” and “not yet” rail (see here, which is here in OSM). If you wanted to run a server with those tiles for Australia, it’d probably fit on one costing around €6 a month.
Unfortunately there are other ways for ill-informed historical railways enthusiasts to break things, e.g. joining segments that previously carried different highway tags. Overall, this is not the main cause of breakage in hiking and cycling routes that I observe in my country, but still a significant one.
Keeping railway= as a feature is best. There are already enough exceptions in others, eg emergency= and indoor= . And ideally, its attributes would still need to be prefixed razed:*= to avoid mixing with the existing one.
I monitor hiking route and cycling route segment numbers in the UK and Ireland (I get an email every time one breaks). “Historical railway mappers” here aren’t a noticeable cause of route breakage here at all (we get a different problem). What is by far the main cause of breakage is people mapping separate footpaths and cycle paths. That doesn’t mean that people shouldn’t map those (of course they should), and nor does it mean that the people doing that mapping are somehow at fault; the problem is unfortunately that (a) iD doesn’t make it easy to tell one route from another and (b) routes in OSM (relations composed of other relations, sometimes nested) are inherently complicated.
This. I think deprecating things, renaming tags and other notions should be carried only after there has been shown that the advantages of doing so clearly outweigh disadvantages of doing so.
For example, deprecating amenity=kiosk in favor of shop=kiosk was likely a good move, and much more popular way of tagging the same thing existed, and those taggings were just a mistake and causing the confusion, for no benefit to anyone involved.
But I have another question: what problem exactly do you think is that deprecating that tag would solve? Make a database smaller? Tagspace neater? Enforcing the bureaucracy?
I do not see any real benefit (afterall, data consumers which don’t care about razed:railway or whatever just won’t render it or use it otherwise), but I foresee significant harm to community (while I’m not a railway fanboy, I know people who are, and I can guess how they’d feel).
Intentionally causing that harm just to prove that I’m right and they’re wrong would not be very admirable human trait, at least in my view.
Absolutely. I too would like to remind people that OSM is primarily about community. Data correctness comes second. Then there is looooong list of other stuff, and only then come concerns like “useless data” / “data which doesn’t belong”.
I can see no way how the latter could outweigh the former, but I’m willing to learn about the details of the allegedly terrible harm that those few thousand entries in database are causing.
(Not to mention that there is no 100% agreement on what constitutes “unwelcome data” – but see more about that below).
I’ll have to disagree here. Live and let others live, eh? If it is not actively harming anyone else, I wouldn’t want to intentionally alienate whole communities of contributors just because they broke some bureaucratic rule without causing harm to anyone else.
For example, valuable OSM contributors dropped out at OSM licence schism back in CC-BY-SA vs. ODbL days (which was very bad and regretful period and I’m still not convinced it was worth it), and many more almost did (myself included).
But at least that schism had some reasonable rationale behind it why it was a good idea to do switch.
On the other hand, just deleting significant work people had put in because one finds it useless and conforming to ground truth best practice without any comparable benefit of doing so is very bad idea, IMHO.
For example, I might find roof:colour completely worthless data, and not wanting to add it, and could even point out that that it shouldn’t be in the database as it fails verifiability “rule” - i.e. most satellite images are not completely true color (so if people use them to map, it’s wrong), and even if they were perfectly true, most people do not go out of their way to get and use correct ICC profile for their display devices (much less recalibrate them periodically), and even if they did, human color perception is inherently subjective, thus mapping color fails the verifiability “rule” in any case.
So, should we go willy-nilly deleting all those roof:color tags? It’s “against the rules” afterall!
Absolutely not. At least not without having extended discussion with all those people, finding out what they get out of mapping those, weighting those benefits that they perceive against the benefits that the removing of such tags would bring (which are basically only insignificantly smaller current database at the expense of equally bigger history database, as far as I can see?)
Well, it is not a “rule”, it is good practice, if wiki is to be believed (not that one should unconditionally believe the wiki, either). While we are that, deprecated tags are not “forbidden” either, to the best of my knowledge. One may still use them, and if history teaches us anything it is that deprecating and especially removing railway=razed would just create bad blood, without solving anything.
Even if those were forbidden by technical means, those would likely be re-mapped as railway=abandoned and then one would have incorrect data instead of useless data, and would likely keep being remapped by other railway enthusiasts again and again, and delete again and again by “rules enforcers”, only wasting everyone’s time.
How about we just let it be and move on instead of wasting virtually infinite amount of effort on something which will only make people angry and not improve the situation? Who would get harmed by that?
Also, some popular things break “on the ground rule”, like unsigned opening_hours (many a kiosk over here for example), or housenumbers in many countries, or country borders for that matter, or even name tag. We still (perhaps grudgingly) leave them in the DB. Because there would be less, not more, happiness in the community if we removed those.
TL;DR: as they would say around here “ne čačkaj mečku” (which would be equivalent of “don’t mess with a hornet nest (without a very good reason)”. Because,there are a lot of problems that this would cause, for no tangible benefit at all.
I like to map abandoned railways based on remnants that are still extant in the build up world, e.g., embankments, disused rail sections, abutments, paths and vegetation, etc.
I think the map could do without the imaginary razed railroad lines that traverse buildings and campuses that have been fully remodeled irrespective of the railroads past presence and influence.
Well, wouldn’t then be much simpler to just that document on wiki for railway=razed that, instead of inventing new tag historic=railbed which has that same meaning? That would seem to me to cause much less friction.
As for “l’art pour l’art” in OSM Tagspace, I’m not a big fan the idea of renaming wildly used tags just so their raw value seems a better fit (i.e. “make tagspace neater”), because:
most of the popular editors (iD, StreetComplete, JOSM, Vespucci, …) most often (or only) use presets, so actual raw tag value is irrelevant and is not going to confuse users (one should better submit PR to improve Tag descriptions in various languages for those presets instead)
it causes unnecessary pains for data consumers (i.e. if “shop” is place when you walk out with some products after you paid for them, then shop=hairdresser is highly misleading name. As is highway=street_lamp and tons of others. Should we thus go mass rename all of them?)
it causes unnecessary pains for data editors and upgrade path (i.e. everyone must upgrade to newest version of editor, even in their hardware does not support that)
even in best cases, the “obsolete” tags will still be trickling in for a long time and require effort to upgrade them
and it does not really solve the problem in the first place.
And has someone been proposing “any number of really damaging mapping activities in OSM”? Because I seem to have missed it. To me, it instead seems to be about very specific case, which I personally don’t really see as damaging. OSM is (as far as I know) not bound by US-alike case law, when another situation arises we can analyze that, and weigh its benefits vs. its disadvantages, and make decision about that.
Trying to overgeneralize things is usually not productive, to the contrary.
Do we? If “of course we all want to be friends” stands, shouldn’t we at least (if we can’t be bothered to waste our time to be actively welcoming) then at least settle on not investing copious amounts of time to being actively hostile towards people contributions that we see no use of (and which do not really harm anyone else)?
“well if you find that this is a problem for your mapping, just set your JOSM filters correctly”
Well, that works just fine. In fact, I could not get any work done if all those forest boundaries, proposed highways, administrative boundaries like place=neighbourhood and other imagined lines were littering the edit space. Reducing that litter by 1% be removing railway=razed won’t really be helping average editor user much (if at all).
and certainly “having to install JOSM and fiddle with its filters”
So, would you be happy with iD solution (that is about the only popular newbie app that might possibly have issue with this that I see? StreetComplete doesn’t) which hides proposed, abandoned, razed tags / lifecycle prefixes? Would that remove this last remaining issue (or ar there more actual problems that are being caused by existence of railway=razed)?
Both historic=roman_road and this has the problem that other historic= features are non-divisible singular entities, not really good as linear features that can be split up as other *way= do. The exception is =citywalls , for which there is still another possibility of using barrier=city_walls + historic=yes . (will it be more suitable to show the series of walls?) historic=castle_wall is not as dominate as =wall + wall=castle_wall (+ historic=yes implied?). historic=aqueduct is akin to a historic=bridge , and can be used as a man_made=bridge area.
Furthermore, this again has the same flaw as railway=abandoned requiring abandoned= to fix. Basically an additional eg abandoned:railway= is still needed.
Also have to decide between this and =ruins
