Proposing to deprecate railway=razed and railway=dismantled

Funny that you use a word with many letters here. I myself did a bit of research yesterday about something that bothered me (inconsistent statements in the wiki tag definitions) and I ended up reading about paraconsistent logics, that are explicitly aimed at accommodating inconsistencies in real world situations. Large data bases and large software systems are explicitly mentioned as applications of these logics.

I’m mentioning this because it sheds light on something we are implicitly negotiating here: consistency makes things easier for everybody including beginners, but it is sometimes costly to reach (ie ontological works) and some of us would rather live with inconsistencies as long as it does not harm them too much in their own activities.

2 Likes

I haven’t read all the posts here, but if the proposition is to start deleting all razed railways on the OSM, I strongly oppose it. I made a tour guide with a map on the net for a cycle route which for the most parts follow an old railroad bed. From JOSM I was able to retreive the parts which are no longer visible, and added this as a layer which could be made visible on the route map. In a guide like this, it is of course interesting to be able to see where the entire railway once went. Where should I have found these data if people just deleted it? To me that would be vandalism…

And I just don’t see the problem - in most OSM based maps, these razed railways are not visible anyway!

Edit: Just to show how data that may seem unnecessary can be useful for some applications, the guide can be found with the following link. It is in Norwegian, but if you select “Opprinnelig spor” in the map selector, you can bring the old railway up on the map.

https://ggranvik.no/tur/gml-drammensbanen.php

1 Like

First of all, this is a cool site – I like how you presented the photos on the map. At the risk of sounding like a broken record, have you considered getting this information from OpenHistoricalMap? It looks like the Drammen Line was mapped there a couple years ago:

Here’s an Overpass query for the line that you can export in GeoJSON or GPX format.

3 Likes

Minh, we may need a hammer emoji for you.

7 Likes

As I often map longer-distance bicycle routes, I encounter such objects somewhat frequently in OSM (and/or, I am familiar with the overlap of the concepts of rail-trail). I do enjoy the experience (“brevity of wit in data,” perhaps) of conflating (in two tags, highway=cycleway and railway=abandoned) onto a single, directional, way object in our database. Nicely succinct.

If we might dress that up with start_year=* and such (tagging, onto a single way which shares much, including temporal inheritances), I’m OK with that. But if we proliferate the temporal sense of time into multiple ways, as that seems unnecessary to me in many or most, nearly all cases, that is needless and redundant. Databases appreciate succinct tagging. We can continue with our present sloppiness (which could be said to proliferate poor tagging due to misunderstanding) or we could “get more ontological.”

Our wiki do extend this “understanding” out to a certain distance, yet things remain persistently muddy (regarding this topic). Perhaps indeed, “tags should reflect the former (OSM) more accurately.” Yet today, they are muddy, all over rail’s complex lifecycles.

Regarding paraconsistent logics, yes, similar to “wiki chase data chase wiki chase data.” Regarding OHM, yes, the concept of “process of change” is built right in there with that “time slider.” All of this seems evolutionary, not necessarily revolutionary.

Since this is the Year of Vector Tiles on the Main Website, I was excited to try out the demo of Shortbread vector tiles that @pnorman just posted, which is updated minutely based on OSM. Unfortunately, the Shortbread schema omits railway=abandoned/razed/dismantled, so a style based on this schema can’t display abandoned railways even if it wanted to.

By coincidence, OpenHistoricalMap also has minutely-updating vector tiles, so we can composite both tilesets together on the client side so that users won’t know the difference. I filtered the OHM features to just the railways tagged with an end_date=*, so as to avoid duplicating OSM’s comprehensive coverage of the present day. I gave the defunct tracks a heavy blur so that you can distinguish them from extant tracks.

This rail yard in Cincinnati has since been redeveloped into an NFL stadium and extensive parking lots. The former sorting yard is well known to locals who remember the 1990s, but it was thoroughly obliterated and has never been mapped in OSM (compare):

On this day in 1945, a spur of the Chitose and Jozankei Railway closed in Sapporo. It has since been built over (compare):

Actually, I fibbed. The track was built on dry land, but it was inundated when a newly built reservoir flooded ahead of schedule. One mile (1.6 km) of trackage was left under the reservoir until the following year. There’s still a railway=abandoned in OSM, under the assumption that some portion of the embankment must surely still be present after all these years – right? But I didn’t wait around for a wealthy eccentric to fund an expedition to the lake bottom. I added the tracks to OHM with an end_date=* and refreshed the page 15 minutes later (compare):

With a bit more copy-pasting, I could have also restored defunct highways, buildings, or riverbanks onto the map, or varied the opacity based on the elapsed time since dismantling. We’re living in the future!

The source code for tweaking the demo style is available on GitHub, in case anyone is interested in learning how to composite two vector tile sources like this.

12 Likes

We’re travelling on holidays at the moment, & yesterday passed through an area that suffered very bad bush fires last year :cry:

Amongst other damage, these fires destroyed a number of old trestle bridges for the Heritage Railway that now uses what used to be a main-line track: https://downsexplorer.org.au/wp-content/uploads/2023/11/Wallangarra-fire-info-flier.pdf

Unfortunately, our dash-cam footage has now overwritten itself, but you can get a partial view of the remains at the right of https://stanthorpetoday.com.au/wp-content/uploads/2023/11/railway_371792_02.jpg

This photo is from earthquake & flood damage in NZ, https://res.cloudinary.com/cognitives-s3/image/upload/c_fill,dpr_auto,f_auto,fl_lossy,g_faces,h_497,q_auto/v1/cog-aap/n/605/2023/May/31/iIebXtsJ6XlyX2dNMxyJ.jpg but it was a similar effect, except that the ties have all been destroyed as well, leaving two rails hanging in mid-air by themselves! :cry:

What do we call that? Damaged / abandoned / razed … ?

1 Like

Nice historical rail map you’ve got there. :nerd_face:
Any chance you’re looking for somewhere to store all that data somewhere like OSM, but for, you know… historical… purposes?
I have some ideas. Just sayin’. :sunglasses:

5 Likes

if you are expecting that the damage is going to be repaired / service reinstalled, it would be tagged as „construction“

The style is Versatiles’ Colorful style. I didn’t properly credit them in my post and need to go back and edit it.

2 Likes

Thanks. To be honest, I have never heard about OpenHistoricalMap… :slightly_smiling_face: But will definately check that out! One questiuon though: If something like a razed railway track is added to OSM - will it also appear on the OHM, or does it have to be added directly in the latter?

Also thanks for the query tip, I’ll have a look at that as well! :+1:

1 Like

It’s a separate database that isn’t synchronized automatically, so you’d have to add it directly. The tagging conventions are mostly the same, but generally you’re expected to try to add dates and cite sources where possible.

Ok, thanks! :+1::slightly_smiling_face:

Hi Frederik - in theory, it should be pretty easy to move data from OSM to OHM. In practice, we strongly discourage moving others’ data from OSM to OHM in order to respect the ODbL license and to avoid triggering any viral obligations.

That said, we have many users asking interesting questions about this process, so we’re exploring possible solutions. We would love it if there were more streamlined mechanisms for getting expired / deleted / removed data from OSM to OHM. @Minh_Nguyen, @nfgusedautoparts, & I are currently working on a doc to share with the LWG to go through these issues.

In the meantime, we’re busy encourage historical rail mapping, adding a rail-specific layer, improving our rail style, and figuring out how to remove barriers for potential data consumers (there shouldn’t be any, but who knows!?).

Hope that makes sense and grateful to have OHM involved in this discussion.

15 Likes

Thank you for the heart-warming and positive plea in favour of OHM. That reads much more motivating than the constantly repeated: this has no place in OSM, why don’t you move it to OHM? That must sound to some ears like: Get lost! You are not welcome here in OSM.

I keep coming across major misunderstandings and misinterpretations in the discussions:
razed is not the same as razed. Some people think that a railway line is already razed when the iron rails have been removed. Both railway mappers and railway erasers make this mistake. The former then map incorrectly and the latter feel encouraged to erase consistently. I have seen many railway lines with railway=razed where railway=abandoned would be correct.
The current discussion in the German forum had two examples just like this:

  • a mapper deleted a railway line a month ago that was mostly mapped incorrectly with razed. Perhaps it really was razed in the section in question, but instead of deleting just the section, the entire route was deleted. Two days ago, current images were posted in this post. Unmoved images are always more difficult to interpret and not everyone is able to recognise a railway line in them. But those who know that there was a railway line here will immediately recognise its course. This line is abandoned, not razed

The second example was the neighbouring line, still present in the first post (red line). This railway line cut through 2 buildings and ran south past the former station building. I already recognised from the aerial photo that the location must be completely wrong. The railway line ran north past the station and was not covered by buildings (orange line). A quick search with old photos of the station confirmed this.

After I mentioned this in the forum, the railway line was deleted one day (!) later. :frowning: Deleting a visible former railway line while it is still being discussed is frustrating even for non-railway mappers.

Some claim that railway=razed is an invitation to railway enthusiasts to add historical railway lines to OSM. That may sometimes be true. Conversely: the constant request “Why don’t you move to OHM” is also understood by railway erasers as an invitation to erase regardless of losses.
Of course, where an open-cast mine has created a huge hole today, the railway line is completely razed. I agree, I come from an open-cast mining area myself. Where it has been completely overbuilt, in completely different structures, new residential areas on former freight yards with countless shunting tracks can go away for all I care. But get in touch with the mappers beforehand so that it can move to OHM first. If there is a single building on a former railway line, it no longer bothers me like a boundary. In some older industrial areas, on the other hand, building structures have formed that have adapted to the former railway sidings. The tracks are gone, but the crooked houses are still standing.

4 Likes

I am writing a summary for the first 150 posts in this thread. I hope my summary will allow newcomers to the thread to obtain a reasonable overview of the majority of points raised thus far, without being intolerably long. I might finish it tomorrow or Sunday.

Edit: This might be a doomed effort, I know.

12 Likes

Do include the first 300 or so posts from the parallel German thread while you’re at it. :see_no_evil:

11 Likes

I am writing a summary for the first 150 posts in this thread. I hope my summary will allow newcomers to the thread to obtain a reasonable overview of the majority of points raised thus far, without being intolerably long

I wish I had started reading at the bottom of this thread instead of at the top. :stuck_out_tongue:

5 Likes

THREAD SUMMARY FOR 1 - 150

I. PROPOSAL TO DEPRECATE RAILWAY = RAZED, RAILWAY = DISMANTLED AND REPLACE WITH RAILWAY = ABANDONED, RAILWAY = DISUSED

Reasons for Adopting Proposal:

  1. We need to emphasize mapping only tangible and comfirmable features to maintain OSM integrity. We need to maintain consistency with “on the ground” rule. Razed railway is not “on the ground”.

  2. razed railway is NOT categorically equivalent to proposed highways or similar objects, and therefore comparing them is not a legitimate justification for mapping.

  3. Absence of railway=dismantled wiki page highlights current railway tag ambiguity.

  4. Current methodology is faulty, and adopting the proposal under consideration would further consistency in tagging practices.

  5. OHM is the proper home for mostly vanished railway objects, especially railway=razed.

  6. We need to avoid further misuse of current tagging schema, community benefits from its overhaul. Users provide examples of current misuse of tags proposed for deprecation, and underscores need to change existing methodology to prevent further misuse.

  7. Past Herculean mapping efforts don’t justify retention. The characteristics of the data justify keeping something in the database.

  8. Less experienced community members may be reluctant to interact with repurposed railways, due to their size and complexity. This can lead to weird mapping decisions.

  9. Mapping converted features as their current incarnation recieves priority over documenting their former existence as a railway.

  10. The notion that mapping historical objects can be legitimate is ridiculous, cites failed attempts to map long-gone buildings. Adding razed railway is adding an historical object.

  11. We risk adding erroneous data if we are mapping objects with limited discernibility. Razed railways fall into this category.

Community Well-being Reasons FOR:

  1. Mapping excessive historical data prevents effective editing and disappoints invested contributors.

  2. Inadequately defined mapping practices lead to conflicts over accuracy. Current tagging system is insufficient.

  3. When discernment of an object is difficult, it creates controversy when mapped.

Reasons to Reject Proposal:

  1. No added value from proposal. Let’s maintain the status quo.

  2. Deprecation is unnecessary. Both “railway=dismantled” and “railway=razed” convey their intended meaning adequately.

  3. It is easy to map remnants of a former railway using current tags.

  4. Deletion would constitute vandalism.

  5. Mapping razed track between extant railway=abandoned segments is not unreasonable and preserves route information.

  6. razed:railway= is equivalent to mapping proposed highways, bike routes, postal codes, turn restrictions, or even timezone bounaries and therefore acceptable.

  7. Similarly to CAD construction lines, razed:railway provides a useful spatial reference for mapping other objects.

  8. Retention of Railway = razed is justified because it constitutes a typical stage of the tagging lifecycle.

  9. Intricate and varied railway tagging enriches the map.

  10. Railroad grades have a distinct appearance, remain significant terrain features over long distances, and old railway bridges show minimum elevation changes.

  11. Former railways are often used as landmarks by communities and also attract recreationalists.

  12. Razed railway could be supported with evidence collected in future ground surveys.

  13. It is reasonable to justify the addition of razed railway to the map using M&L methods (machine learning technique).

  14. Deprecating these tags deprive us of a tool due to the inability of the community to adapt and implement an alternative tagging scheme in a timely manner.

  15. Data consumers can use historical data to ehance navigation.

  16. Railway enthusiasts should not have to feel constrained in OSM.

  17. It is a misconception that retaining some historical data in OSM renders data editing impossible. A user contrasts between long-gone buildings and those with hidden remains like basements.

  18. Community can accept incorporating historical data given a balance between deduction and external validation.

  19. Renaming tags for aesthetics is not effective, causing only confusion and inconvenience.

Community Well-being Reasons AGAINST:

  1. We can’t possible wipe out 15 years of dedicated work.

  2. Topic has been revisted numerous times, reaching concensus is unlikely.

  3. We harms community cohesion by discussing this further.

  4. We need to refrain from deleting this information, as morale would be negatively impacted.

  5. Risk potential loss of valuable contributors and their local knowledge.

II. ALTERNATE PROPOSAL TO DOWNGRADE RAILWAY = RAZED, RAILWAY = DISMANTLED TAGS FROM “PRIMARY” TO “ATTRIBUTE” STATUS

Reasons for Adopting Alternate Proposal:

  1. Tags would only supplement existing features clearly observable on the ground.

  2. Allows deletion of lone ways traversing inappropriate areas.

  3. Retains tags on features like cycleways, tunnels, or cuttings.

  4. Suggestion similar to was:railway=yes but simpler to implement.

  5. Requires only a wiki change without extensive retagging or causing disruptions for data consumers.

Reasons for Refusing Proposal:

  1. Notes problematic potential inclusion of railway=razed/dismantled tags on roads.

  2. Highlights difficulty in accurately mapping features like cuttings.

  3. Argues that considering them road attributes would be problematic.

  4. Including such attributes on roads could introduce ambiguity and inaccuracies into mapping data.

  5. This proposal lacks alternative tags for certain railway remnants.

  6. Inadequate for describing track bed with removed rails and other nuanced railway remnants.

  7. Proposal represents a policy change by altering fundamental mapping principles.

  8. Creates a burden of considering non-existent historical features when adjusting extant features.

  9. Possibility for aligning highways to former path of defunct railway exists, creating alignment issues.

III. OTHER POSSIBLE SOLUTIONS MENTIONED:

  1. Deprecate railway = razed and railway = dismantled, but adopt historic=railbed tag to convey the presence of recognizable terrain features of an old railbed.

  2. Representing former railways with relations is a possibility, using relations to incorporate existing features and rough geometries.

  3. Treat railways the same as other objects with razed or demolished lifecycles, using proper lifecycle prefixes and updating them accordingly.

  4. Adopt a specific embankment tag instead of using railway=razed.

  5. Represent former railways using historic tags instead. It is important to preserve historical railway data.

  6. Using was:railway=yes to mark cycleways or embankments along converted railways

  7. Transition all railway=* tags except railway = disused to OHM.

  8. Clarify wiki documentation for railway = razed so that proper application of tag is clear. railway=razed and railway=dismantled are frequently confused.

IV. OBSERVATIONS ON VERIFICATION AND DIFFICULTY OF MAPPING RAILWAY OBJECTS:

  1. Difficult to distinguish between railway=abandoned, railway=razed, and railway=dismantled.

  2. Challenging to verify features from historical or external data alone.

  3. Can compensate deduction level with external data, especially for historical railways.

  4. Importance of mapping visible features is emphasized. Contributors have erroneously mapped dense networks, railway buildings, yards, or logging railway networks without on-the-ground survey data.

  5. Railways are among the objects most frequently added post-destruction.

  6. There are limitations to solely relying on technological solutions to address mapping issues.

  7. Remote deletion without proper communication is an ongoing problem, community needs to collaborate further and better adhere to mapping standards.

  8. Community needs a systematic method for indicating visibility of railway remnants.

V. PRACTICE OF APPLYING HIGHWAY TAGS TO CONVERTED RAILWAYS:

  1. Abandoned railways with cycleway tags is common practice along French-German border, Germany, and England.

  2. Hook Norton Viaduct is mentioned multiple times as an example.

  3. Cycle.travel recognizes highway=cycleway and railway=abandoned combination. Combination influences smoothing factor, providing accurate terrain representation for cyclists.

  4. Trail_trail=yes tag proposed as a theoretical tag that would more directly encode terrain information currently inferred by a combination of two tags.

  5. Do other benefits exist to distinguish between cycleway from railway vs. railway transformed?

VI. BRIDGES AND RUINS ASSOCIATED WITH BRIDGES

  1. Community members discuss need for clarity in representing bridge ruins components in OSM.

  2. Community members highlight need for specific tags like “ruins=bridge_pylons” due to presence of such structures.

  3. Theoretical tag “ruins=railway_support_pillar” tag for dismantled railway support pillars is proposed

  4. Counterpoint: Adding more “ruins=” tags might contribute to disorganization

  5. It is argued historic=ruins is insufficient for differentiating superstructure from understructure.

  6. Community members discuss if specific tag combinations like “bridge:support=” with “ruins=yes” represent a solution.

  7. Possible expansion of “historic=” framework is discussed as a separate solution.

  8. Suggestion is made to use theoretical “type=bridge” tag to explicitly relate structures.

  9. Potential community friction exists over theoretical “type=bridge” tag, especially for ruins and tunnels

  10. Theoretical “train=yes” proposed for bridges with multiple purposes like road-rail bridges.

VII. ON COLLABORATION AND COMMUNICATION:

  1. Continue to engage in collective discussion for resolution of this dispute and similar issues

  2. Underscore importance of communal essence, collective efforts shaping OSM.

  3. Primary discussions should occur on official OSM channels, with outcomes shared on Discord for consistency.

VIII. ON MAPPING CRITERIA AND STANDARDS

“Pro-freedom, Pro-specialist” Group:

  1. Avoid overly strict adherence to pure observation and prefer richness of OSM data.

  2. Tolerate specific-purpose data and diverse contributions accomodating varied interests.

  3. Emphasize practical utility as a mapping criteria over strict verifiability.

  4. We can preserve historical information and accurately convey current state at same time.

  5. Community should defer to subject specialists for discerning railway remnants overlooked by remote mappers.

  6. Individual mapping activities do not significantly hinder others’ editing experiences in OSM.

  7. Specialized data enriches map, encourages exploration during surveys.

  8. All data in OSM has potential to become specialist.

“Anti-chaos, Anti-specialist” Group:

  1. Individual mapping freedoms should not be prioritized over collective data quality and coherence in OSM.

  2. Stress the importance of consistency and logic in mapping decisions.

  3. Carefully evaluate existing practices before proposing new tags.

  4. Community should not blindly accept all mapping activities. Unchecked mapping freedom leads to damaging practices.

  5. Simplicity and Comprehensibility are priorities of the OSM project.

  6. We need to prioritize creation of features accessible and understandable to generalists.

  7. We need to be skeptical of “proof by authority”, community magnanimity is more important.

  8. Designating areas for specialists will erect barriers to project evolution.

“Balance” Group:

  1. We need a balanced approach respecting individual mapping interests while recognizing need for community standards.

  2. We should have a pragmatic approach evaluating inclusion of data based on relevance and usability.

  3. We should embrace nuanced perspective between subject specialist data inclusion and OSM’s democratic nature.

  4. We should advocate for balanced approach encompassing both specialist expertise and generalist understanding in OSM.

  5. We should strive for progress and refinement in OSM while accepting its imperfections as part of its evolving nature.

IX. OpenHistoricalMap: A Possible Future Repository for Razed and Dismantled OSM Railway Data?

Yeah, OHM could be used as a replacement repository for the following reasons:

  1. The existence of the new OHM rail layer is useful for displaying this data.

  2. Current efforts to enhance rail-specific layers and styles are underway.

  3. OHM is public domain under CC0, compatible with OSM data.

  4. Safe integration of OHM and OSM datasets is possible using Mapnik-Leaflet or MapLibre GL.

  5. The ethos of OHM is extensive tagging freedom.

  6. All railway=* tags except disused belong in OHM. Transition would be complex but OHM represents an appropriate home

No, OHM does not represent a viable repository because:

  1. We are skeptical of transferring OSM data to OHM due to potential license compatibility issues.

  2. Questionable to move historical data sourced from Bing imagery to OHM.

  3. We risk potential loss of contributions from OHM database restoration to older versions.

  4. Better to map from scratch in OHM for accuracy sake

  5. Importation directly the from source is possibly more beneficial than from OSM, considering existing legal issues

  6. Permission needs to be obtained before transferring razed/dismantled railways to OHM.

Other OHM Notes:

  1. Simultaneous display of OSM and OHM datasets is a distinct issue from migration considerations.

  2. There are ongoing efforts to streamline transfer process, especially in iD.

  3. Sources and methodologies in OHM need further documentation for transparency

  4. Opponents of certain tags in OSM could resurvey and add features to OHM.

  5. It is possible to intermingle datasets from OHM and OSM during post-processing or editing, similarly to Overture Maps.

  6. Potential discrepancies in data up-to-dateness represent a barrier to intermingling datasets.

  7. OSM should focus on resulting objects, OHM on documenting change process.

  8. For OHM, data licensed under CC BY-SA, but CC0 is preferred. Object-level licensing helps OHM include data from a variety of sources, but places the burden of inspection on the consumer.

25 Likes

Above is the summary. I gave it a shot and hope I at least achieved a fair overview of the discussion. I hope we as a community don’t give up on continuously working towards resolving issues like this. I hope this freshens up the discussion.

4 Likes