@TheSwavu: Ah shit, I didn't realise the two licences were not cross-compatible. I have been editing under the presumption that they were. That's really unfortunate.

@travaudat: Thanks for starting the guide! I do have some IRL stuff going on this month so I won't be able to contribute for the time being, but will have a look in the near future.

Hi @travaudat. Thank you for your contributions as well.

1) The names have been something that I thought about for a while. The wiki page for the 'name' key (name=*) states that its value should be the *primary name* of the feature. There are several reasons why I don't consider the part after the forward slash a part of its primary name:

a) Bus (and tram) stops signs in Melbourne, where named, generally only include the name of either a nearby landmark or intersecting road. The name of the road the bus stop is located on is normally not printed, but whenever it is included, it is almost always (from experience) printed lower on the sign, in a smaller font size to the name of the landmark or intersecting road. This heavily suggests that the name of road the stop is located on is secondary to the name of the landmark/intersecting road. OSM also prefers the name as used 'on the ground' (see earlier wiki page and osm.wiki/Disputes#On_the_Ground_Rule) where multiple sources disagree as to what the name is.

b) The names of stops announced on SmartBuses (703, 900-908) don't include the name of the road the stop is located on. (This is also the case on trams.)

c) I originally started tagging it this way when I was working on redoing the tram network to use the version 2 tagging scheme years ago, and I reapplied that naming convention onto the bus network so that there's eventual consistency across the PTV network.

d) This is also how bus stop names are tagged in other jurisdictions that names its stops based on the landmark/intersecting road, such as London.

2) I originally used the 'ref' key years ago to add bus stop IDs (there wasn't a consistent and established tagging practice at the time from what I could tell), but I later realised that tram stops, which have both a tram stop number AND a tram stop ID for PTV purposes, already use the 'ref' key for the former. For example, the Melbourne Uni tram stop (https://ptv.vic.gov.au/stop/2214) has a tram stop number of 1 and a stop ID of 19489. Given that the former is more prominent and in greater public usage than the latter, I used the stop numbers as the 'ref' value, and stop IDs would have to take a separate key (hence why I made the 'ref:ptv" key as per the practice internationally - see ref=*). The same reasoning can be applied for the train network (Flinders Street has the station code FSS, which takes the 'ref' key, and a stop ID of 19854, which would have to take the 'ref:ptv' key; see https://ptv.vic.gov.au/stop/1071).

However, this introduced an issue with tagging the bus stop IDs, as the bus network don't have separate "bus stop numbers" and hence bus stop IDs can take the 'ref' keys. Ideally, the same 'ref:ptv' key should be used for these stop IDs across the entire PTV network, as the train, tram and bus stop IDs are the same set of unique IDs (I know this because it was used in the URL of the stop/station's page on the PTV website pre-2018, e.g. http://ptv.vic.gov.au/stop/view/19489 was the Melbourne Uni tram stop page pre-2018, http://ptv.vic.gov.au/stop/view/19854 was Flinders Street's, and http://ptv.vic.gov.au/stop/view/19554 was for the Swanston Street/Lonsdale Street eastbound bus stop; you can verify this using the Wayback Machine). I thought that using solely the 'ref' key (and not the 'ref:ptv') for stop IDs on bus stops would be contradictory and inconsistent with the tagging practice for train stations and tram stops, and not using the 'ref:ptv' key on bus stops when other public transport stops use (or will use) them would reduce the key's usefulness to developers and other users who use the OpenStreetMap API (there would need to be separate object search criteria for bus stops). This is the reason why I began moving existing bus stop IDs using the 'ref' key to the 'ref:ptv' key. For a short time, I tagged bus stop IDs on both the 'ref' and 'ref:ptv' keys simultaneously, but I stopped doing that as it just seemed like I'm adding redundant information, and if the ID changes in the future both keys would have to be updated - many contributors would probably only update the 'ref' key, which may end up causing confusion as to which value is correct.

I recognise that the "ID." part appears on bus stop signage, but I did not consider it as part of the stop ID because (a) it does not appear in the stop ID listed on the PTV website (both the pre-2018 and the current versions of the website) and (b) "ID." appears consistently on all signage of the bus stop IDs and never changes. Both of these together suggest that the stop ID is just the number part and that the "ID." part is just an indication to readers as to what the number represents. "ID." also does not provide any additional information to the database since "ref" already indicates that it is an ID number.

3) There isn't a guide specific to Melbourne/Victoria - nobody really took the lead on coordinating and making one, probably because there's very few contributors actively working on public transport tagging in Melbourne/Victoria. I primarily follow the general guidance on the OSM wiki and tagging precedents in other jurisdictions to ensure that things are fairly consistent across international borders.

4) The stop ID (20836) is correct and applies to all V/Line bays - this can be verified on the current PTV website (https://ptv.vic.gov.au/stop/4529) and the pre-2018 website (https://web.archive.org/web/20160724080000/http://www.ptv.vic.gov.au/stop/view/20836). As for the route_ref (684), I haven't been able to tell if there is a consistent stopping location for that particular route. It likely doesn't and just uses any available bay, but for the time being I tagged it on all bays to indicate that the route could stop at any bay. Ideally it should only be tagged on one bay though so that it only appears once in the 684 route relation.

I hope this adequately explains the reasoning behind my changes.

Yup that should have been split. Fixed now.

Oops, got a little too trigger-happy with the upload button. Meant to say in edit summary: "Minor fixes to existing data"

And for the JPD roads, thanks! Basically, when mapping link roads (or other roads for that matter), if there's a physical barrier splitting the road (like grass for example) or a legal barrier (parts of the road you're not supposed to drive on; I ignore other road marks like single and double lines), then I'll split the road into two one-ways, otherwise I'll keep them together and mark them as two ways. In short, "map what you see" is what I follow.

Hi. Well this is a problem with the OSM. Very frequently I need to select the entire road, and splitting the roads makes it a huge pain to select everything again (especially if you talk about long roads like the East Coast Expressway in Malaysia, which is not fully completed so I have to update data a lot). What I usually do (and I see some people do) is to assume the turning lane as it's own road (i.e. when mapping the turning road it would include the lane for turning). But personally, I'm not sure exactly how OSM wants us to map these types of roads - probably it's best to ask at the wiki (osm.wiki in case you don't know, since you're new here). By the way, welcome!