Three-relation vs. two-relation schema
To better harmonize towards OpenRailwayMap's documented method, the USA might consider re-tagging existing route=railways to route=tracks, then adding route=railway relations and sharpening memberships to better express what we mean. Should we do this? (This would be a vast amount of work, with no readily discernible improvement for purposes of, for example, "higher level" route=train relations). Distinctions about why "both tracks + railway" elude the way we appear to structure rail in the USA, so we listen. Using route=tracks may also be a method to express a certain aggregation style without super-relations. Is this useful? Again, we listen. Yes, ORM documents that route=tracks denote "physical railroad" (infrastructure) while route=railway denote "the route of operation of trains over a (route=tracks relation)." This seems a subtle distinction and may not be needed (here), as we (in the USA) seem to be able to express a route=railway relation as meaning "the route of operation of trains over the physical railroad expressed by the members of THIS relation." Yes, route=tracks is used to specify routes in the VzG system in Germany and that may be its useful extent -- or not. Editors in the USA appear to be moving forward with our convention of conflating infrastructure (route=tracks) into a single relation of route=railway, even as we might discuss a change to route=tracks + route=railway. Improvement towards high quality usable data should guide us here.
I (Stevea) have asked Michael Reichert (an author of OpenRailwayMap), to discuss the USA's convention of conflating route=tracks and route=railway. It would be a large amount of work for the USA to restructure existing route=railway relations into both route=tracks and route=railway relations. While it is recognized that using both route=tracks and route=railway is useful for the way that Germany structures rail in OSM, it also appears that the distinction between these two is (largely? completely?) unnecessary for the way that the USA structures rail in OSM. This Discussion page intends to provide a forum for wider and further discussion of this topic. Stevea (talk) 10:26, 2 July 2015 (UTC)
- It has been over two years since I (Stevea) wrote that, and since then USA mappers have boldly forged ahead with rail mapping withOUT using route=tracks relations. I'm not completely ruling out this possibility in the future, however since the response to the above paragraph has been absolutely zero, and 100% mapping with the USA's "two relation" (not three relation, including route=tracks) scheme, we can consider this issue largely closed and addressed. Stevea (talk) 17:34, 24 July 2017 (UTC)
Is this the right page to discuss small problems?
- Hello Ethylisocyanat: No, not really. I'll do this once here and now to explain a better process. It looks like you have identified two identically-named rail route=railway relations in North Carolina. You have also found a Wikipedia page which strongly indicates that this one seems to be the incorrect one: 1) because it doesn't align with what Wikipedia says, and 2), specific to this example, this relation seems to end with a rail bridge crossing the Smith River, then suddenly does not continue westward. By clicking on this relation link, you can see that user hofoen is the author of this changeset, so click on the changeset link. This allows you to enter some Discussion text. Initiate user hofoen with a kind, polite tone of curious inquisitiveness about why you believe this relation s/he has entered might be incorrect. Ask him/her to explain and then wait up to a week (or even two) for a reply. Importantly, listen carefully. The resolution can go any number of ways (such as deletion, modification, or, further disagreement) but eventually this OSM process should allow the conflict to be solved. Stevea (talk) 17:25, 24 July 2017 (UTC)
- Hi Steve,
- thanks for the in-depth explanation, I've already discussed a few changesets. I haven't done this here yet, because I wasn't sure, that hofoen is the original author of that relation. The changeset comment indicates that just has done the "railway crossings" Maproulette challenge.--Ethylisocyanat (talk) 14:34, 27 July 2017 (UTC)
- An update: I have been using this to disambiguate where subdivision boundaries are and who the owner=* and operator=* "should" be, as I was contacted by a professional in the rail industry who said that these map data are what the rail companies use as "authoritative" when such questions of boundary and name/owner/operator come up. Follow the "Step 1" and "Step 2" directions and click the "Done" button, then wait. (And wait, and wait). The data are from the federal government so they are in public domain and can be used freely in OSM. Beware, the site can be very slow to load initially, and then you should be zoomed in pretty close before clicking on a rail element to receive the pop-up about it. RROWNER lists the railroad owner and SUBDIV lists what we are putting into the name=* tag. Have fun! Stevea (talk) 03:20, 13 October 2018 (UTC)
Shafter Subdivision (UP)
- My apologies, I didn't see this until now (I have now checked the "Watch this page" box). Unfortunately, it looks like I deleted the former and kept the latter as I was working on Utah/Railroads. I believe the newer one (extant) is correct, though I welcome corrections if I got it wrong. And, I additionally apologize for deleting what you believe to be "the correct one." Please let me know if this is correct "as is." Thank you. Stevea (talk) 02:02, 13 October 2018 (UTC)
Quantifying TIGER Review completion
Hiausirg, I thank you for your edits / updates. I ask, from where do you estimate 90% TIGER Review completions? Since the fall of some useful visualizing tools, these data (completion percentages) have been little more than a very rough estimate. Plus, the dataset of NA / USA rail is so vast (hundreds of thousands of miles) that the perfectly valid question of "WHICH 10% remain?" is deeply challenging to answer. (Many, many use cases for these data, such that ANY definition of "fully reviewed" needs some specificity). So, I'll ask it anyway. How are you quantifying these data? Which ways are we talking about? (Even a "rough OT query" would be a start at an answer, but that's already "huge enough to cripple servers." The dataset easily includes 10,000 or more ways. Those are pretty big data to be accellerating away as Fully Reviewed). So we find ourselves (still) asking "how do we quantify the vast data that include 'not TIGER Reviewed' by your definition?" My definition (and it is crunchy/smunchy hand-wavy hard-to-define) might be much larger. We come to "how high are the quality of our USA rail data?" (and how high do we want to make them?) Stevea (talk) 22:16, 12 February 2022 (UTC)