Talk:Tag:route=tracks
Jump to navigation
Jump to search
Tag:route=railway vs. Tag:route=tracks
Can somebody please explain the difference between these two?--Shlomo (talk) 08:11, 30 May 2018 (UTC)
- There is discussion about this same question at https://wiki.openstreetmap.org/wiki/Talk:Tag:route%3Drailway Aceman444 (talk) 06:32, 22 March 2019 (UTC)
User:Lyx thank you for adding this description: "train tracks between two endpoints that are maintained as a operational unit (e.g. subdivision". However, I believe this is also how route=railway is used. You suggest that a route=railway should be longer than a route=tracks, but how can this be defined? Is there some way that another mapper can confirm if the route is mapped correctly or not, or is this information only known to the railroad operator or track maintenance company? --Jeisenbe (talk) 13:15, 11 January 2020 (UTC)
- The information which sequence of tracks forms a subdivision is usually published either by the operating railway company or the government agency regulating rail traffic, and is widely known in the community of railway enthusiasts. For the distinction between route=railway and route=tracks maybe an example might shed some more light: If we would use route=tracks for rail mapping in the USA (which we don't), then e.g. the Hi-Line subdivision in Montana between Havre and Whitefish would be tagged as route=tracks, while a route=railway would cover the whole BNSF Northern Transcon from Seattle to Chicago (with the Hi-Line subdivision covering part of it). --Lyx (talk) 16:58, 11 January 2020 (UTC)
- For "short lines" that have only one subdivision there is indeed ambiguity if to use route=railway or route=tracks. That's perhaps the reason why US mappers use route=railway only. --Lyx (talk) 17:02, 11 January 2020 (UTC)
- Data that is only published by the operating company is probably not public domain and would not be appropriate to include in Openstreetmap. If it is published by the government it might be licensed appropriately (depending on the country) but it is still a problem to map information that is only available from an external database and cannot be confirmed by surveying the location in person. In that case the Openstreetmap data will always be worse than the official source, and database users would be better served by downloading the data directly from the government database and using that in addition to Openstreetmap data. That's why rule 1 is "don't copy from other maps". I'm not saying you have to remove these relations from Openstreetmap, but I do think we should reconsider whether it is worth our limited time to make and maintain these relations - especially huge ones that cross a whole continent. --Jeisenbe (talk) 23:17, 11 January 2020 (UTC)
- Let me try again: We are not talking about some arcane secrets, but about stuff that can be considered common public knowledge among the crowd that is interested in mapping railway infrastructure. At least where I live, about every route=tracks or route=railway relation has an associated wikipedia page, often multiple books and magazine articles published about that piece of infrastructure, etc. If you think it is not worth your time to make and maintain these relations, the solution is easy: Don't do it then. But it is not ok for anyone to tell other people on what they can or should spend their mapping time. --Lyx (talk) 00:09, 12 January 2020 (UTC)
- Published books and magazines are copyrighted. Wikipedia's license is not compatible with the Openstreetmap license (ODbL). See Copyright and FAQ#Why_OpenStreetMap.3F and Legal_FAQ#2._Contributing. That's why we have to base mapping off of local, public information like signs or markings "on-the-ground". This standard is much stricter than that used by Wikidata and Wikipedia - both of those organizations are based in the USA which has much looser copyright protection for data than some other countries. Openstreetmap was started in England (the UK) which has strick copyright protections even for public data, and many other European countries also have higher standards. But the main reason not to rely on printed reference sources is that this information can be outdated or wrong: the "gold standard" for Openstreetmap is checking a feature by surveying it in person. If you can confirm the name of a particular track or subdivision in this way, then you can map it with precision and with confidence that the data is accurate. --Jeisenbe (talk) 00:42, 12 January 2020 (UTC)
- Let me try again: We are not talking about some arcane secrets, but about stuff that can be considered common public knowledge among the crowd that is interested in mapping railway infrastructure. At least where I live, about every route=tracks or route=railway relation has an associated wikipedia page, often multiple books and magazine articles published about that piece of infrastructure, etc. If you think it is not worth your time to make and maintain these relations, the solution is easy: Don't do it then. But it is not ok for anyone to tell other people on what they can or should spend their mapping time. --Lyx (talk) 00:09, 12 January 2020 (UTC)
- Data that is only published by the operating company is probably not public domain and would not be appropriate to include in Openstreetmap. If it is published by the government it might be licensed appropriately (depending on the country) but it is still a problem to map information that is only available from an external database and cannot be confirmed by surveying the location in person. In that case the Openstreetmap data will always be worse than the official source, and database users would be better served by downloading the data directly from the government database and using that in addition to Openstreetmap data. That's why rule 1 is "don't copy from other maps". I'm not saying you have to remove these relations from Openstreetmap, but I do think we should reconsider whether it is worth our limited time to make and maintain these relations - especially huge ones that cross a whole continent. --Jeisenbe (talk) 23:17, 11 January 2020 (UTC)