I’m happy to steer things towards an already-established global consensus (so, +1). If ref_trips=* is the better key, let’s use it. Clay, I’ll be the first to say “it’s OK” to have reversed the syntax components (and not using plural, as it appears is done with ref_trips=*). And Toni, I’ll be the first to say “thank you” for calling this to our attention here and suggesting good harmonization. Nice!
Right. Follow something like a database convention so that ref can refers to as many things as you want. I think it should be ref:trip = abc, just as source tag is being divided to source:names, source:geometry, source:ref etc etc.
I don’t claim that this is actually the better key. I’ll be ok with any other, globally harmonized one.
ref_trip= is not ideal, but ref:trip= won’t work at all because suffix by convention means it is a variation on ref= . not that it is a ref= of something else. Eg Trip.com exists, so ref:trip= might be some id on that website. (that’s the dominant use of ref:*=; cf name:*=) Or if as I said, when the train number contains both run and trip number, *:ref:trip= might be used to show the trip part of the train number. (this may be compared to addr:*= for different parts of an address)
source:*= has a different logic. It is a namespace used to group such info. In this sense, it is similar to lifecycle prefixes. (I personally don’t like it. It can technically be interpreted as how the tags are recorded in the source=, as in import prefixes eg tiger:*= and naptan:*= .)
2 Likes
Almost all of the additions are jumps, seems to be imports or mass editing. That’s not a strong case to keep them. ref_trips | Keys | OpenStreetMap Taginfo
For completeness, there’s also railway:ref, which sometimes has to be suffixed too.
This station served by Caltrain, ACE, and Amtrak has a different station code according to each. I’m not familiar with any examples of airline-style codeshare agreements among public transit operators in the U.S. that would apply to these route relations, but I think it could happen in Europe.
No imports but rather massive use of the key during a short period of improving bus relations in southern Germany by a small group of mappers (including me) having access to a new and valid source of information. Total number is still quite small compared to total number of route relations in that area.
1 Like
Do you think of something like ‘Bus 603/50/27’ with ref=603/50/27 and ref:MVV=603 and ref:VLK=50 and ref:LAVV=27, where MVV and VLK and LAVV are networks?
If those are route numbers, that would probably be modeled as separate concurrent route relations. Rather, I’m referring to something like how, in aviation, a single flight (trip) might have a different flight number according to Delta than according to KLM. There are a number of air–rail alliances, resulting in the IATA assigning codes to railway stations, but I don’t know if this extends to trip numbers.
Those are route numbers and networt=MVV;VLK;LAVV
Not sure I fully understand the point you’re making, but yes, there’s definitely examples of trains being assigned flight numbers.
One example is the air+rail alliance between Lufthansa and DB in Germany. Lufthansa “flight” LH3424 is really a train. I’m sure there’s more cases like that.
1 Like
It’s particularly helpful for North American train routes. Some routes have a variety of stopping patterns for each individual train, and it’s hard to map them on OSM without keeping track of schedule numbers.
I’m inclined to stick with trip_ref=* here because it matches other types of ref, like loc_ref=* and route_ref=*.
2 Likes
I appreciate adding it. But it won’t always work nicely. Let’s take one issue, USA often have more limited frequency, while other countries could have many more numbers. ref=405;409;417;451;463;465;467;473;475;479;497;4403;4405;4407;4415;6401;6403;6411;6455 already amounts to 84 chars, nearing 1/3 of the limit. In this case, you would able to further split by Amtrak and CTrail (should it be?) to make it as short as possible. For other cases in general, using ranges and rules may be inevitable for length constraint, and desirable for editing concerns. Listing them all out is less convenient for humans, inelegant to read, and prone to errors when enumerating. The SQL format available from GTFS is not always the simplest solution, necessary for every number format, or easily understood by most.
The way I see it, this isn’t really about adding information (the trip numbers are already present on e.g. the Amtrak routes).
Doesn’t the issue you’re describing (the value of the tag eventually overflowing the max character limit) exist regardless of whether the proposed change is implemented (move the trip numbers to trip_ref=*) or not (keep them in ref=*)?
In my opinion, the proposed change does neither improve nor disimprove this; strictly speaking it’s a different issue, only coincidentally affecting the same tag(s).
In my opinion this is primarily about clearing the ref=* tag of the trip numbers so ref=* can be used for matching values in both the route master and all member routes.
Whether the trip numbers should be kept at all is a discussion worth having in general, but it could be had independently of the changes proposed here. (Personally, I’m with clay_c here - having the trip numbers feels like it can be valuable - at least in the US. I can see this being different in other parts of the world, but other local communities could just chose not to tag trips in their areas…).
2 Likes
I went ahead and made the changes:
I’ll follow up by updating the wiki where applicable.
2 Likes
Metrolink/SCRRA has codeshare ticketing from the Ventura County Line onto Amtrak Pacific Surfliner trains, but the VCL timetable lists the codeshare trains as their Amtrak train numbers/IDs instead of giving them a Metrolink train number as well.
Yeah – the train numbers that are mentioned in the route master are prefixed with an operator code to form an internal train ID that’s used in railroad backend systems (schedule management, authority control/train dispatching and signalling, train tracking and recording) to identify that train run on a given day of departure uniquely and unambiguously, similar to a headcode in the UK network. (FYI: I work on such a system at a US railroad, which is how I know these sorts of things.) That said, the analogy to a flight number falls down somewhat because train numbers in US & Canadian practice are not used as radio callsigns (the lead locomotive’s number is what’s used instead).
2 Likes
We’re talking about the same physical train being assigned two different refs by two different rail operators here – trains being exposed to GDS as a “flight” is a somewhat different case from the rail operations perspective, since the rail systems don’t ever have to deal with the GDS “flight” number for the train, but it’s very possible that the train runs on tracks of multiple operators, and even with crews from multiple operators, all of which can sell tickets for it.
Connecticut’s Shoreline East line (New London to New Haven) will sell you a ticket from New London all the way to New York City, with the Metro North commuter rail taking you from New Haven on. Though, tagging train numbers of the commuter rail seems wildly excessive. I only know this because I’m riding it to SoTM US 
How embarrassing – I forgot that part of the train number is posted on a flipboard on the side of the locomotive. This is Train No. 268, pulled by the No. 911 San Carlos:
I long ago learned to ignore this sign and the conductor’s barely audible welcome/safety announcement when departing from San Francisco, which also mentions the train number. They also assign a two-character code to each service pattern – the actual thing we’re mapping as a route relation – but this is what only appears on the timetables and never on signs.
Let me know where I can surrender my railfan credentials. 