If it was removed in 2008 and there is no evidence of its existence on the ground now it probably shouldn't be mapped. Generally speaking, razed features are mapped in order to prevent other mappers from adding it back using outdated aerial imagery.

osm.wiki/Nonexistent_features

Also, I'm curious as to what your source is for the geometry here? Bing and Esri both show no evidence of this existing.

Could you fix the wikipedia tags for those relations? It should be *language*:*page title* rather than a URL.

E.g. wikipedia=en:Williamstown line rather than wikipedia=https://en.wikipedia.org/wiki/Williamstown_line

I've also restored way/397260833 and way/403604215 as I've just noticed those were also deleted.

Hi,

You seem to have accidentally deleted the Hawksburn railway station way (way/714353207). I've restored it in changeset/170414467. Sometimes the stations are mapped as ways rather than nodes, so make sure to pay attention to what ways you are deleting when deleting landuses.

en:Belgrave railway line

would be the correct value for the wikipedia tag. please see here for some examples:

wikipedia=*

I've fixed it in changeset/170318784 :)

Thank you. I've noticed and am glad you've fixed those relations.

Your contributions here are invaluable and you've already added more route relations than I have in such a short time. Really appreciate your work here :)

I've been fixing minor issues with the routes whenever they come up, but it's so much easier now to add a missing way or to change a stop role when it's already in order and done properly.

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.