Changeset: 66783730
California rail ("re-upgrading" railway=rail to railway=light_rail for SPRINTER tracks, keeping usage=branch and usage=industrial where warranted)
Closed by stevea
Tags
created_by | JOSM/1.5 (14620 en) |
---|---|
source | OSM/ORM conventions |
Discussion
-
Comment from clay_c
Hey there stevea,
This is mostly just a technicality, but what was your reasoning behind changing this back to railway=light_rail? The remainder of the route and infrastructure for the SPRINTER is still mapped with train=yes rather than light_rail=yes, so if you meant to change this to a light rail line, your work is incomplete. From my point of view, changing the underlying railway for a DMU line to railway=light_rail makes it a bit harder to maintain and it doesn't match up with how similar DMU routes are mapped elsewhere.
In good faith, I'm going to go ahead and change this back to railway=rail. If this is something you're confident about, feel free change it to a light rail line—just make sure your changes are reflected in the public_transport elements and route relations as well.
-Clay
-
Comment from stevea
I agree with your analysis and changes here. This has always been mildly confusing in my mind as to how DMU lines are best mapped, especially when the tracks are used for both a light_rail service (whether DMU or electric) AND there is also some freight on the line (as on San Diego Trolley's Orange line out to Santee and El Cajon, where there are "industrial rail customers" that use the same line the passenger trollies are on, but between 2:00 AM and 3:30 AM for their freight runs).
So, as I don't know if the SPRINTER tracks even ARE used for freight, (I don't think so, my nephew rides this line as a CSUSM student) that was my motivation: "light_rail only" made me change it. But you continue to do excellent work on rail, and if you have noticed that what I did is "incomplete" and that your newer tagging is how similar routes are mapped, then I defer to your more consistent tagging.
While realizing that the following questions mildly stray in the direction of tagging for the renderer, doesn't it seem that your style of tagging railway=rail instead of railway=light_rail would make an ORM rendering "disappear" that the tracks (as black, not green) are not readily apparent as passenger (light_rail) service? That's another motivation for me having changed it, not so much tagging for the renderer, but merely as an accurate way of seeing (say, California-wide) rail as a network and identifying where the light_rail passenger service is?
I'm still not sure which is "more correct," as I see both of our perspectives here, though I will defer to you setting it to railway=rail as we discuss this. Let's say there is no freight service here (maybe true, maybe not). Wouldn't the ORM tagging convention of "the highest or heaviest service on the line" (i.e. passenger service being "more important" than freight) suggest that light_rail "win out" over rail? We really could go either way here.
Thanks for noticing and your very polite note here! I encourage further discussion, or you might simply leave your changes as is without further discussion, though I would appreciate an answer as to the above questions.
-
Comment from stevea
relation/6161003 (Escondido Subdivision) seems fine — it is even additionally stitched into local transit as a bus_route.
relation/1371791 (SPRINTER) was updated with the text of the change in the wiki. In short, this route=light_rail is now a route=train and is documented in the wiki as so. Keeping eyes open here, as this is a curious edge of California/Rail: the distinction between a light_rail and a train route.
-
Comment from stevea
I have changed relation/1371791 back to route=light_rail (from route=train). Everything I know and can find about this calls it a "light rail" and calling it a train (as in heavy rail) seems incorrect to me.
Wiki changes made yesterday were backed out (to re-reflect it is light_rail, not train). The "service=commuter" tag on the relation was deleted, as this key:value pair isn't wiki-documented and doesn't make sense in the better-established context of the "passenger=urban" tag (which does make sense and is wiki documented).
While the route is still PTv1, some platform elements (as in the richly-tagged Escondido Transit Center) do begin an ability for upgrading to a fully PTv2 route, but other intermediate platforms will need to be added to the map and this relation.
-
Comment from stevea
Now, finally, the question confronts us: do we change the elements of the Escondido Subdivision from railway=rail to railway=light_rail where applicable? Following the example of the San Diego Trolley's three infrastructure lines (Blue, Orange, Green, though there is also a Silver passenger route on these), I would say "yes, we should" make these changes.
It would be good to definitively know if/when there actually is any freight service on the Escondido Subdivision, the "Freight Bypass Tracks" and minor amount of freight-appearing rail just past the Escondido Transit Center notwithstanding.
-
Comment from stevea
The rail elements in the route=light_rail are changed from railway=rail to railway=light_rail.
Despite the service being DMU instead of electric, everything about this says "light" rail instead of "heavy," (which would lead to a route=train for the passenger service, but it isn't, it is route=light_rail). The concomitant train=yes tags (on stations, transit centers, platforms) are now light_rail=yes
- Escondido Subdivision MT1 (5951836), v21
- Escondido Subdivision MT1 (6000517), v18
- Escondido Subdivision MT1 (26600295), v15
- Escondido Subdivision MT1 (33803597), v16
- Escondido Subdivision MT1 (33803688), v14
- Escondido Subdivision MT1 (33803689), v13
- Escondido Subdivision MT1 (33803757), v12
- Escondido Subdivision MT1 (33803769), v13
- Escondido Subdivision MT1 (33804558), v22
- Escondido Subdivision MT1 (35974779), v11
- Escondido Subdivision MT1 (35974780), v13
- Escondido Subdivision MT1 (85703383), v13
- Escondido Subdivision MT1 (85703392), v12
- Escondido Subdivision MT1 (85703393), v16
- Escondido Subdivision MT1 (85703409), v12
- Escondido Subdivision MT1 (94670097), v9
- Escondido Subdivision MT1 (94693016), v12
- Escondido Subdivision MT2 (97783858), v10
- Escondido Subdivision MT1 (97783861), v10
- Escondido Subdivision MT1 (97783862), v10
Relations (1)
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |