I've added some basic documentation about the tag at railway:cbtc=* since none existed and the tag is in use, but it would be good if any further information about what the tag means or how it could be applied could be added to the wiki.

regarding way/962492246 I don't think there's any signage present indicating it's a shared path.

On my 2018 imagery https://www.mapillary.com/app/?pKey=927023981175171 there's nothing visible, but it could have changed recently, I'll make a note to double check, but the council has a few paths around there that I think were intended to be shared path but they never installed any signage or painted any bicycle symbols... in which case they are only shared paths on paper not in on the ground. I'll make a note to check again.

I've removed all the superfluous psv=yes tags added to the public roads where it's already implied and we generally don't specify =yes for each mode. I discussed this briefly on the OSM World Discord #oceania channel and there was consensus there.

The psv=yes on highway=busway, per imagery indicating it's Taxi/Bus Only, I updated to psv=designated to reflect the road access.

hi you've added psv=yes to the train line here which isn't quite right so I've removed it.

hi you've added `psv:lanes`=* to the route relation, that tag is only applicable to the actual road ways with highway=* where you want to specify bus lanes. I've removed it from the relation but you may want to correctly add it to the road segment again.

most highway=* values are already assumed to be public transport accessible by default, therefore it's not necessary to tag this.

See osm.wiki/OSM_tags_for_routing/Access_restrictions#Worldwide

In my view we don't want to be tagging every single road as hgv=yes, psv=yes, bicycle=yes, etc. that's just noise.

Where there are bus lanes we should be indicating that with the relevant tagging, or where it could be ambiguous like highway=pedestrian we should specify or where there's signage like no access, busses excepted we should tag that but otherwise for regular roads we shouldn't usually tag psv=yes.

FYI I've changed way/176608577/history to Mona Vale Road. My reasoning is the street signage here indicates it's Mona Vale Road, with "To Kanangra Road" implying that Kanangra Road is further along. This is likely done my the council due to the houses along here being addresses to Mona Vale Road, however DCS NSW data still shows it as "Kanangra Avenue" for the whole section, it's just this doesn't match any council signage installed.

Thanks. This is visible on the Esri World Imagery (you can change the background imagery in the editor). I've made some minor tweaks, including adding the no-u-turn restrictions, adding the turn around roads on the side roads, and using the turn:lanes tagging over running the _link road for the length of the turn lane per best practice.

*track

I've added that part back in as a driveway

I've added that part back in but as a driveway

Thanks! It looks like the construction=trunk was the issue.

It's likely the same business as node/11053177237 so I migrated some tags across and deleted this one.

I moved node/7973343649 to the centre of the reservoir where it appears to be on the imagery

> Just to check - does adding in a couple of start_date's manually make the import harder?

Nope. What I was thinking was match based on being within X meters and the ref matches, then add start_date if not existing already (if already exists then ignore it).

After I saw your changesets, I made a few state wide changesets which included adding the ref to these site relations based on the name.

it looks like some unrelated features were accidentally moved, it's quite common for this to happen unfortunately. trying to pan the map ends up dragging and moving features.

I've reverted those changes, but left the events venue feature you added.

Per building:flats=*

`building:flats` is the count of flats/units in the building so in this case it should be 4 not 4321.

`addr:flats` is for the range of flat/unit numbers at the address so it should be 1-4.

I've fixed this here and merged the lone address node for the building into the building way which already had the same address tagged.

only via the correspondence at changeset/169271037

If a track in a national park has been "closed", and that's indicated I think access=no should apply. access=private makes more sense for something like a driveway that the land owner uses but no one else is permitted to use it. So access=no is stronger, it says no one is allowed to use it. This lines up with how they are documented at access=*

Sorry I have no idea about what Alltrails does, but it's up to them how they choose to interpret the tags.

In any case, the lack of a highway=* tag would mean most downstream maps won't display it at all. I suggested to apply abandoned:highway=* instead of having no highway tag at all, so some data consumers who want to specifically check for closed and non-active tracks can still find it.

Mapping these kinds of features is still contentious in OSM and even the current guidance we put together at osm.wiki/Australian_Tagging_Guidelines/Cycling_and_Foot_Paths#Legal_Access isn't universally supported so it's something that can evolve further, but I feel this is a good balance.

Rather than deleting the highway=* tag I suggest we use the lifecycle prefix osm.wiki/Lifecycle_prefix#Stages_of_decay per the guidance at osm.wiki/Australian_Tagging_Guidelines/Cycling_and_Foot_Paths#Closed/Illegal_Paths

For example disused:highway=path or abandoned:highway=path or demolished:highway=path or destroyed:highway=path depending on the state of the unsanctioned and illegally constructed mountain bike tracks.

This is incredibly overgrown, at least trail_visibility=bad/horrible, potentially even abandoned:highway=path based on the lack of it being a clear path.

The western end is a bit clearer, but just south of Yanco Close Reserve I lost the track completely.