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
Yes absolutely. I don’t mean to suggest actually inventing a new tag. I was just wishing that a different tag had been chosen years ago. One that might not have been so prone to misuse. “Razed” means the thing in question has been completely demolished. We can certainly try to document that the meaning of railway=razed in OSM is slightly different and means “mostly demolished, but with some terrain features still remaining”. If railway=dismantled means the same thing, I find that a clearer word choice. “Dismantled” doesn’t carry the same connotation of complete obliteration that “razed” does.
Yes, it has been widely interpreted as meaning the same thing, and was widely used (at least in the UK) before razed became prevalent. Obviously that still leaves the question of “what deserves that tag” [waves vaguely at the preceding 120 posts].
There are a great many layers, reasons, histories and tagging associated with the present and the past of these (rail) taggings. It’s like a snarly tangle that must be unraveled.
I think it is fair to start by not wholesale deleting of tags. There are reasons for why those tags evolved and at the same time there are those who find them offensive, confusing or “in their way” (of interpreting other, likely rail, though not necessarily rail, data). There continues to be a harmonious middle ground to migrating them to consensus.
I have found (in my career, life, experience, with some wisdom and growth along the way, hopefully…) that taking a snapshot of “what we have” can be helpful, provided many agree that in doing so, we see and plan how we might best accommodate downstream users of our data, parsers, ORM, Carto and many others. A snapshot will allow us to say (some of) “these (taggings) are clearly old / broken / misapplied / poorly used today…” enough to throw some taggings into the “delete” bin, provided we accommodate these with other tagging. Or, we might choose to preserve these tags, but discourage further future tagging of them with a (proposed or actual) schema of rail tagging. This sort of evolution would eventually emerge on its own, I’m pretty sure, but I’m simply sharpening up the focus on how we might take a deliberate look at it and streamline it into a syntax / semantic scheme that we all agree upon. That really is the goal here, even if nobody has stated it.
Now that it is stated, let’s do it. We should start by saying whether we are OK with simultaneously having messy (rail) tagging in OSM and somewhat-cleaner (rail) tagging in OHM. Personally, I’m OK with that. We might migrate to something “tighter” in the future, sure. It’s nailing up some taginfo data and “what we mean by that” turning into consensus, then a path forward to “how we’d like to continue doing this, only better.”
See, that’s easy to say, and kind of hard to do. Yet, I think we can.
Alternatively couldn’t we move to lifecycle tagging for these objects (currently they are classical troll tags). And maybe a light weight way of mapping “historic” railway routes with relations that allow recreating rough geometries of the missing pieces and will use geometries of what is actually still visible (say an embankment and similar).
PS: this thread came very handy yesterday in an interview with a research group of an example of OSM processes -not- working :-).
I grew up in a town that’s mainly notable for the rail trail that passes through it.[1] When I first started mapping in OSM, Google Maps was still showing the trail as an active railway, more than 40 years after it closed and converted into a bike trail (technically a shared use path for pedestrians, cyclists, and horseback riders alike). I was proud to make OSM the first online map to ever acknowledge the bike trail.[2]
The town made some effort to remind trail users of its history, preserving an obsolete railroad crossing sign and a small iron bridge over a creek. But this amounted to only 125 feet out of a 78-mile-long trail (38 m out of 125 km). Otherwise, you’d only know it’s a rail trail from its level grade and gentle curves. In America, we don’t normally build such usable cycling infrastructure on purpose. But one could alternatively chalk it up to the quiet, meandering river it follows.
When I first turned the TIGER-imported railroad track into a bike trail in 2008, editors and aerial imagery layers didn’t support the degree of micromapping that we take for granted today. I simply retagged the track as railway=abandoned[3] and highway=cycleway and called it a day. But apart from this one bridge, the bike trail is technically offset to the west of the original railroad track by a few feet. Prior to construction, Penn Central had salvaged every rail, tie, and spike in bankruptcy proceedings.
By our exacting standards today, the old alignment truly no longer exists, except coincidentally as a dirt sidepath for horseback riders. Maybe I should’ve mapped the bike trail separately and kept the railroad track where TIGER had it originally.
Sometimes the trail veers from the original path. For example, when crossing active railroad tracks, it needs to come in at a right angle so that cyclists’ wheels don’t get caught in the tracks. Perhaps I should’ve added a straighter railway=razed way so that no one would get the impression that the old railway junction was shaped similarly.
These tweaks would have somewhat undermined the argument in favor of abandoned railway tagging, that someone could inspect the trail itself to determine if it would be a leisurely ride. In the absence of this micromapping, maybe they can instead notice the frequent benches (sitting on what had been the tracks), or that it runs along the banks of a National Scenic River dotted with canoe rental shops. They’re doing this manually, right? If, on the other hand, they expect a cycling routing profile to pick out railway=razed automatically, then I may have to rewrite my tired joke about the self-driving car company that adopted OHM.
Sometime in the last few months, the state demolished the iron bridge in order to replace it with a gleaming concrete one. The history was getting a little too old, too familiar. Since I was the one who added this rail trail originally, I took care of updating it, including retagging the formerly preserved rails that have presumably been sold for scrap:
I did a naughty thing and left both the bridge and the rail as demolished features, but only because there’s still plenty of aerial and street-level imagery suggesting otherwise, and I didn’t want anyone to restore the features incorrectly in the meantime. But I deleted other minor features outright, like the wooden guardrails and the doggy bag receptacle. Should I have kept them, for consistency? Should I have micromapped them in OHM instead?
If we decide to keep the rails but not the , that’s an editorial decision. Rules, in other words.
There’s some precedent for this in how some mappers have detailed the vestiges of old highway routes. Long ago, before OHM got off the ground, @NE2 would create elaborate route relations in OSM for the old auto trails that predated modern highway systems in the U.S. Each relation would represent a snapshot in time, such as “Dixie Overland Highway from Metter to Savannah (1923)”. They conducted quite careful research, citing out-of-copyright maps and logbooks on Google Books. (At some point, another mapper deleted the citations, because copying Google is bad, but kept the route relation itself. )
The nice thing about the auto trails is that they travel on a lot of infrastructure that still exists in some form, though usually upgraded quite a bit. Still, looking a bit closer at these route relations, I’m sometimes struck by the particular roadways that they follow. Did the Dixie Overland Highway in 1923 really follow a roundabout in a parking lot at Georgia Southern University, even though the roundabout is surely a more recent installation? The logbook makes no mention of it, even though it details the location of every turn and fork to a tenth of a mile. Apparently, the roundabout enthusiasts (or more likely the TIGER cleanup enthusiasts) paid no attention to historic railways when updating the configuration of a university parking lot.
To some extent, this is merely an example of the inherent fragility of a route relation, nothing specific to historic railways. These relations have real utility: the roadgeek community loves to organize tours of old highway routes from end to end. I’m sure railfans have a similar use case. It’s like the historical walking tours that some cities signpost, but without the signposts. Folks here can certainly think of discussions where someone wanted to add their own tour routes to the map and ran into similar questions of verifiability.
One roadgeek site, the AARoads Wiki, plots the old routes against an OSM basemap to illustrate the turn-by-turn narrative. They used to use OSM route relations to track the former alignments but frequently ran into conflicts with mappers focused on the present, so now they’ve learned to compile a list of way IDs, export their geometries from Overpass, and save GeoJSON to Wikimedia Commons. They’re slowly remapping these highways in OHM so that they won’t have to put together long lists of way IDs in the future.
This debate didn’t come out of nowhere. Abandoned railway mapping has a troubled reputation in the OSM community largely because some proponents have conducted themselves less than diplomatically. To a layperson, it can seem like a siege mentality. Both sides of the debate accuse each other of bullying and extremism and the rest is history.
To some historic railway mappers, OSM has plenty of room to accommodate residual rail features, even if it’s as unrecognizable as a deconstructed burrito bowl. How someone chooses to spend their time and effort is their own business, not mine, but I want historically-minded mappers to be aware of the opportunity that OHM provides for more expressive mapping without the friction. With or without them, OHM is going to cover historic railways; all the better if the experts are there to guide the project. Hopefully this discussion has helped the OSM community recognize the value in supporting likeminded projects like OHM.
Google Map Maker contributors then tried to one-up us, turning the trail into a U.S. Bicycle Route, more than a decade before it would actually be designated and signposted as one. ↩︎
For lengthy periods of time (centuries), rail rights-of-way shape our landscape, engineering, landuse patterns, transportation corridors, following usually only minor grades for efficiency. Rail are a “thing” unto their own. I like lifecycle tagging and “migrating” data to OHM where correct and appropriate, especially in targeted areas (Johnny Appleseed-style, good examples and seeds planted for good growth ahead). These things (rail, rail services, the effects of rail engineering upon the shapes of the landscape…) have particular and peculiar lifecycles and ways to be associated with something (active freight or passenger rail, a cycleway/pedestrian path, an abandoned right of way with partial structures remaining…) that literally span centuries. Our messy tagging reflects this, these things are peculiar and difficult to talk about (widely and with consensus). We get better at it, I am sure. It might seem like it doesn’t work, but it is actually working as OSM works. Being ontological right now helps.
Minh, thank you for your poetry of a post there; that was magnificent. “Residual” is a helpful word. “Not working” is in the eye of the beholder. I see progress here, the steps to get much better at this are laid ahead like stones to walk upon. It may seem like we squabble here; sometimes a decent sketch sneaks in. We are inspiration to ourselves (if not others) at the very least.
Maybe lifecycle identifications, taginfo inventories, an interested group start talking among themselves, sharing passion and breakthroughs as they evolve. Paths ahead and skeletal structures of understanding (better, clear tagging for OSM, OHM). More forward momentum required, it’s true, though I think we can likely find that around here. This seems like a pilot project for how we’ll more fully marry the fourth dimension of time into OSM with OHM. Run with it somebody, it’s all right here to do.
cycle.travel does actually look out for the combination of highway=cycleway and railway=abandoned, and adjust its behaviour accordingly. It’s a really good indicator that the trail has a gentle grade, even in a narrow valley where the coarse SRTM grid might suggest the path is jumping up and down a little. So it doesn’t affect the weighting, but it does affect the smoothing factor applied on the elevation.
Note that if there something, anything actually left from rail itself (not just “road in the city is named Railway Street”) and mapper surveyed location then I am fine with mapping it.
Few years ago I was quite confused why grading alone would be sufficient but got convinced that it makes sense to map former railway in such cases.
What I have problem is mapping based on 150 year old map without considering or caring is it still having any actual traces.
BTW, maybe a good idea would be to have some systematic way of indicating how railway remains visible in terrain?
This sounds pretty reasonable as a heuristic, but the thing about heuristics is that there’s often a more direct way to encode them in the database, if desired. A rail_trail=yes tag would still allow you to smooth the elevation profile on a trail like the one I mapped, even if I had mapped it as a separate way and left the railway=abandoned running alongside it. You wouldn’t have to weigh cases where some fragments of the trail are tagged railway=abandoned but others are not, due to micromapping.
Alternatively, you too could join OSM and OHM data to consider whether the trail overlaps a railway=* in OHM. (I have a sledgehammer, and all I see are rail spikes! )
But I’m not sure that your use case is really what’s motivating the impassioned defense of abandoned railway mapping in OSM. It probably has more to do with inertia and historical precedent. After all, we’ve let it slide for a decade and a half now, longer than the lifetime of a great many rail lines. Deprecating or obsoleting any tag is difficult in OSM, but it’s all the more difficult for a tag that some mappers have practically made a part of their identity. This is as much a cultural issue as a technical one.
bag receptacle. Should I have kept them, for consistency? Should I have micromapped them in OHM instead?
)
)