USBR 25 in Southwest Ohio
OK, the new relation for the proto-USBR 25 is now . This is the relation which should be used to "build and extend" USBR 25 in Ohio. Whether this does or does not get incorporated into UGRR as an ncn ("quasi-national route") via super-relation is a rather plastic concept. Let such a conversation begin. --Stevea
OK to tag both railway=light_rail AND usage=branch?
In Sonoma and Marin counties in California, a rail line (North Coast Railroad Authority) with freight usage is now tagged railway=rail and usage=branch. Imminently, a portion of this will additionally include passenger service (SMART) as railway=light_rail. On affected rail segments, do I simply change railway=rail to railway=light_rail, leaving the usage=branch tag to indicate the sort of traffic which remains for freight? (These are separated temporally; freight runs at night, passenger/commuter SMART will run in the daytime). Please see the relevant section of California/Railroads for all the gory complexities, but this is the essence of the question I'll have once passenger service starts on SMART very soon. --stevea (talk) 23:52, 9 October 2016 (UTC)
I saw you added several relations with route=railway on the VTA light rail system. The ones you added don't match any of the official VTA light rail routes (which are Alum Rock-Santa Teresa, Mountain View-Winchester, and the short Ohlone-Chynoweth line), and I'm not aware of any trains running besides the light rail cars. Is it fine if I remove these relations?
- No, it is not fine if you remove these relations. I'm not sure I added them, they are part of "underlying infrastructure" useful/convenient and important (but not strictly required) to enter a route=train relation. Please read our WikiProject_United_States_railways on how we use TWO relations (not three as OpenRailwayMap/Tagging suggests, that is a more German/European way of doing it) to describe both train routes (like VTA) and railway routes as the underlying infrastructure (light rail tracks, in VTA's case). The "high level" route=train relations that you see are the VTA routes, oriented towards passengers wanting to board a train in a particular direction on a set of tracks. The "middle/lower level" route=railway relations that you see are the underlying infrastructure, the "set of tracks." They are important relations, distinct from light rail routes, and must not be deleted. In fact, since 2014, I have been improving the TIGER-imported rail infrastructure in the USA by creating the WikiProject noted above, as well as several of the statewide projects noted in that wiki (especially California/Railroads, where I live). I spoke on this topic last summer (2016) in Seattle at SOTM-US (click on the User page link above and find the link to watch the 5-minute Lightning Talk). Please read up on OSM's comprehensive and relatively current documentation in the form of our wikis and understand our data structures before you start deleting well constructed relations, deliberately built, improved with consensus and documented in our wikis. In fact, if you have five or six minutes, watch the Lightning Talk I gave (pause through the rapid-fire slides during the last 30 seconds), as it is a good overview of this topic, if I say so myself. I appreciate that you asked me, but I must refer you (as I do here and now) to our documentation to explain these relations. I am happy to answer any additional questions you may have. Stevea (talk) 19:33, 1 July 2017 (UTC)
Hi, I'm an inexperienced user, and I noticed you're active in work concerning railroad lines in California. I created a relation consisting an abandoned railway spur line (7717108) that once existed. Do we provide proof on the existence of the spur line if it's barely visible in the aerial view, and can I add the spur to the California/Railroads page? Thank you. --960mrunner (talk) 23:29, 8 November 2017 (UTC)
Thank you for Utah/Railroads!
Please group changes
Looking at the version history of Montana/Railroads, it looks cluttered to me. Could you please review your changes by using the preview function before submitting an edit? That would be very beneficial when searching for a specific change or old version. Thanks. --Tigerfell (Let's talk) 17:54, 11 October 2018 (UTC)
- Hi Tigerfell,
- That's because it is "cluttered" (to use your word, though I disagree, I'd call it "detailed with many minor changes"). It reflects my particular editing style and there isn't anything wrong with it. I have little incentive to change my editing style except for your polite request. I do a lot of table edits, which are not always easy to compare between raw wiki markup and the final result (despite Preview), and while I've gotten better at aligning entries, the thousands (tens of thousands?) of edits/table edits I've done simply go faster when I use a rapid edit-and-compare style (sometimes called "raw vs. cooked"). It's a bit like batching up code changes to "dozens" and THEN doing a compile, vs. a rapid style of "change one or two things, compile, and see if the small code change is effective." Except this is with a lightweight markup language to edit wiki text. As I sometimes code in the previous style (there is usually little cost in my IDEs to a rapid edit-compile-link or "make" process, as my minor changes are often in a single .c, .cpp or .h file), I am uncomfortable being asked to change my wiki editing style for the benefit of a new user who finds my edit history "cluttered."
- What are you looking for in the history edits that you find "cluttered?" I often make change comments in the Summary field, keep the great majority of my edits "minor" by checking the "This is a minor edit" box, leaving it unchecked for major restructurings and/or "announcements" of large additions of wikitext and have received feedback from other OSM volunteers/wiki readers/editors that this keeps their change notices (because they have "Watch this page" checked) infrequent and unobtrusive — all of these are worthy goals to continue.
- I find Preview to be an obstacle to my rapid wiki text editing style, and while I respect your request, I most likely will not be adopting it. One main reason I am OK answering you like this is that it puts the burden on you to search for the changes you might be looking for (simply choose the proper radio buttons to select between versions, often it helps to skip through a large number of "stevea" edits to "chunk" them together) and you should be able to "search for a specific change or old version." I also find that since the timer for my login credentials token expiry has gotten much shorter (during the last year?) I find that lengthy (in time) edit buffers often "lose changes" (unless I grab a copy before uploading my submission). This is annoying, and while I've learned to get around it by copying the text quickly, I prefer the better security of not "staying logged in" or a semi-permanent OAuth token. Yet another reason to continue to do things as I have and will.
- In short, I edit wiki text for the benefit of myself and other users who read it/them, allowing good collaboration between them and us, the efficiency with which I do that, and the interactivity the wiki provides me as I and others develop its structure and content. Similar to editing the map data of OSM itself, if/as/when other volunteers/editors find they are working on the same area (I have done this for nearly a decade and have experienced this many times), rather than resolve edit conflicts (which JOSM allows, but it can be difficult to "untangle" the details of complex data collisions), the same is true of wiki, though usually on a less-complex scale. I edit a flurry of edits, then I leave it alone for a while (days, weeks, months). This allows others to collaborate, though I might agree with you (even though you didn't assert this, merely implied it) that during my restructuring / flurry of edits, this does make it difficult for others to work on the same wiki. As lyx has left Montana/Railroads largely untouched for several years, and I have been "on a tear" better fortifying statewide /Railroads pages in the USA for the past several months, I will continue to edit both wiki and OSM like this. Many users do, especially as they/we remain in good, close, collaborative communication (OSM's "missive" system makes easy work of this). In short, what I do (and do with others) as I edit OSM and simultaneously document those changes/improvements with wiki, works.
- You'll notice I received a complement from another OSM user right above this comment about Utah/Railroads (which I completed in mere days, simultaneously with a large number of edits in OSM which IMO substantially improved the railroad data in Utah in OSM). One (OSM data improvements) happens simultaneously with the other (wiki documentation of the changes) in a highly complementary and nearly real-time way, especially with my editing style. While I am humbled by this volunteer's appreciation (and I did thank and friend him, and he friended me in return), I've barely touched Utah/Railroads since, allowing him to continue to "knock off the rough edges" of the initial wiki version as it invites any wiki editor to do. You might say I created "hundreds" of initial versions, but I wouldn't have were I hobbled by changing my edit style to constantly look at Preview, simply for the benefit of you (or others) "searching for something." You can still find it, I invite you to develop and implement a better way to do that (as the onus is on you, not me). Those radio button selections and the results that wiki returns go a long way towards showing you whatever you might be looking for. Me changing my editing style? Not so much. I have no idea what you might be searching for, so to change my editing style to better "guess" at what you (or others) might be after as you do seems nonsensical to me.