You have gaps and unordered ways in this relation

https://tools.geofabrik.de/osmi/?view=pubtrans_routes&lon=145.01030&lat=-37.82519&zoom=13&baselayer=Geofabrik%20Standard&opacity=0.50&overlays=ptv2_routes_invalid%2Cptv2_error_ways%2Cptv2_error_nodes

Also, you have this route stopping at two different platforms at flinders which seems wrong for a single route

Hi, did you intend to delete the train stations on this line?

I've checked all 15 route relations and all of these have the same issues as I've previously discussed with you... You do understand that you are breaking things, right?

If you don't believe me, check this tomorrow (the issues shown today are already fixed by me): https://tools.geofabrik.de/osmi/?view=pubtrans_routes&lon=145.08489&lat=-37.82686&zoom=12&baselayer=Geofabrik%20Standard&opacity=0.50&overlays=ptv2_routes_invalid%2Cptv2_error_ways%2Cptv2_error_nodes (it'll show most of these as having errors as you added the ptv2 tag to the routes...)

I've fixed all your mistakes (again) here: changeset/169269117

Please see the relations and how the members are **ordered** and have appropriate **roles** and learn from it.

FYI you've created a gap in the Sunbury line (relation/17544633) and the stops in several routes were not ordered properly and were missing the "stop" role. I've fixed the stop order in changeset #169228611, but not the gaps (you can fix that). Please practice care around these relations as it can be difficult to figure out what you've intended to happen and that in turn makes it harder to correct the errors accordingly.

Also, I just noticed that you've made a lot of route relations that are complete unordered messes. These were harder to find as they were missing the public_transport:version=2 tag. I've not the time to attempt to fix them, so I'd advise that you compile a list of the routes so that you can fix them once you learn how to.

Hi,

I've partially reverted this changeset in changeset/169174921 and restored the crossing (node/5158305356). I've confirmed in a recent survey that there is indeed an unmarked crossing there with the kerb lowered on both sides. There's no indication that it isn't a crossing. It connects the two paths and is naturally used as a crossing, so I've restored it as such. Please don't remove it!

I've fixed the issues in here: changeset/169048251

I would appreciate it if you could at least be receptive in the comments rather than just expecting others to clean things up!

Unfortunately this hasn't fixed it, there still is a gap in the route, but also the platform/stop members are without roles. Like I said in one of my previous comments, the platforms and stops need to have the platform and stop roles to be treated as such in the route (Please see here: route=train#Members). They also have to be in order (which they are currently not).

I may be able to fix this some time later, but you should ideally be able to do this by yourself as you've been adding lots of broken route relations lately and it would be good if they were not needing of fixing in the first place.

If there is something that is confusing about this please let me know and I'd gladly try and help explain it better!

Hi, are you going to fix the errors in these route relations?

https://tools.geofabrik.de/osmi/?view=pubtrans_routes&lon=145.08072&lat=-37.99143&zoom=16&baselayer=Geofabrik%20Standard&opacity=0.50&overlays=ptv2_routes_invalid%2Cptv2_error_ways%2Cptv2_error_nodes

Hi,

Thanks for your contribution and welcome to OSM.

In this changeset you accidentally dragged this fence node 670m to a footway

node/8200436876/history/2
node/8200436876

I've moved it back in this changeset: changeset/168901038

Please take care in checking your changes for accidentally dragged nodes before uploading.

Happy mapping!

Hi,

Just a few things that might be of use:

1. You may want to add `public_transport:version=2` to the route relations so that editors and error checking tools can better understand which pt version is being used. (public_transport:version=*)

2. The platform and stop members in the relation should have the platform and stop roles respectively, and are usually ordered as the first members of the relation in this sequence; stop, platform, stop, platform... from where the route starts to where it ends. This helps keep the stops grouped together and also signifies that they are stops and platforms rather than ways the train would traverse on (i.e. ways with no roles).

E.g.: in relation/19343119 at the top of the relation: West Footscray stop as the role *stop* followed by the respective platform as the role *platform*, then the Middle Footscray stop and platform, and so on until the last station Westall.

3. To understand which relations are route variations of a "master" route they are added as members to a super relation called a route_master osm.wiki/Relation:route_master . This helps a lot when editing and can save a lot of time figuring out which relations exist for a particular route.

4. I'd probably use different names to what you've used for the routes, but I'm not sure what the general consensus is for what the name should be for a train route (at least here in melb). Generally having what the route is actually called is a good start. (For instance, the Sunbury Line is generally called the Sunbury Line rather than *Start* => *Destination* like what you changed its name to. So I changed it to Sunbury Line: *Start* => *Destination* here changeset/168814202))

Feel free to reach out if you have any questions about routes. I can send some more documentation if that would be helpful :)

Hi,

I'm not aware of any Sunbury line trains originating from Sunshine. Do you have a source for this? If this line variant does exist it should be added to the route_master for the Sunbury line. Also, the route relations have members in the wrong order. Please read here osm.wiki/Relation:route#Order_matters

I didn't touch the Hurstbridge replacement bus as I'm not sure if that should even be mapped, but it currently has `route=train` which should be changed to `route=bus`

I've also noticed that the rail replacement bus is tagged as a train route, its stops were not in order at the top of the relation, and it was not continuous (had gaps).

relation/19308543

I've since those issues in changeset/168470267

It also appears that this arrangement will only last a few weeks? If it's temporary and short lived it doesn't need to be mapped as it can be hard to update it whenever it changes. The information will quickly become out of date. It does seem that this route is used quite a bit without it changing so it's probably fine to map, but it should have some description or conditional tag to show that it is in use temporarily and only under certain circumstances.

Hi Lachlan,
Thanks for contributing to OSM.

In this changeset you've duplicated (19312176) the route_master relation for the Hurstbridge Line (1830850). Was this intentional? There doesn't need to be a new route_master for this line, the route variations can just be added to the old one. Also, route_master relations should not have nodes or ways in them, these should be removed.

relation/19312176 (duplicated)
relation/1830850 (original)

Feel free to check the wiki for guidance osm.wiki/Relation:route_master :)

Hi Tadhg,

Thanks for contributing to OpenStreetMap. Just letting you know that in this changeset you broke the order (osm.wiki/Relation:route#Order_matters) of ways in the 411 and 412 bus route relations (i.e. the ways in the relation were not continuous and had gaps).

I've fixed the issue in changeset/164920068.

As I understand it, iD editor doesn't do a good enough job warning you if you've broken routes, so you might want to take care and manually double check the order of ways in the bus routes after editing them.

Hi alisaluk, just letting you know that platform node/4427569779 was also mistakenly moved in this changeset. I've restored the node's location in #164795619

Happy mapping!

Hi rtaylor4,

The correct tagging for a private driveway is as follows:

access=private
highway=service
service=driveway

oneway=no is not needed as it is assumed to not be a one way unless otherwise specified (i.e. oneway=yes)

I've fixed the tagging in changeset/164534137

Everything else you've done seems completely fine, thanks for helping map this area! Please let me know if I've made any mistakes as I'm the active contributor here and not many people review what I do here.

Hi rtaylor4,

Thanks for contributing to OpenStreetMap.

I've noticed in this changeset you have added a waterway relation to where a building is (relation/18944157). I assume this was a mistake, so I removed it in this changeset (changeset/164534069).

Happy mapping :)

Hi giarcnomis,

Thanks for contributing to OpenStreetMap.

I reverted this changeset as well as the following ones you made in this area (163142614, 163139129, 163139008, 162990332, 162990275) as I believe that the intersection wasn't mapped properly. It had a missing piece of highway, had each unseparated turn lane mapped, and broke the following bus route relations:

902, 901, 477, 953, 532, 959

My changeset which I reverted your changes: changeset/163187869

A note I opened about the issue a few days ago (sorry I didn't comment here then, I was busy and must have forgotten to): note/464481

I do think that the intersection can be improved by adding the two one ways that the buses use, but the individual turn lanes needn't be mapped.

I made sure to only revert the changesets to do with this intersection, if someone else got removed I'm sorry, it can be readded. I wanted to make sure I didn't break things more.