Usually there are no pedestrian signs where you can't walk, so assuming those are present here, then all good.

hi I updated the name and ref for way/45728168 based on sinage

hi what's your source for the speed limit and name? this road was already mapped with a different name. Since this added a duplicate road segment on top I'll revert in the meantime.

hi what's your source for the speed limit and classification? This road was already mapped, the one you added was a duplicate on top so I'll revert this for now until you can confirm.

hi, generally if you're adding many buildings if you could do a few before uploading instead of saving each building as a changeset.
---

Published using OSMCha: https://osmcha.org/changesets/91396007

Hi welcome to OpenStreetMap. It looks like you've traced out a few driveways as areas and tagged them as buildings. Things should only be tagged building where they are a structure with walls and a roof, which is not a driveway, you can map driveways as a linear way (line) and tag it as a driveway instead.
Also for buildings it should be the footprint of the building not the whole land parcel, so the backyard shouldn't be included.

Great work. I saw this one recently but wasn't on my bike so didn't manage to grab a trace. There looked like cycleway on the eastern side too.

Probably the hosted routing engines didn't update. When I tested now with the GraphHopper hosted router on osm.org it avoids routing through Walumetta Drive, but will route through it if the end point is along it (which is how it should work for destination).
OSRM hosted by FOSSGIS might not have updated, or it might not handle destination correctly.

Generally creating no-existent paths for the router is controversial. I've been tollerant of the ones going along beaches, even though I don't agree with them (there's no marked path along the beach so it shouldn't be mapped as a bath), but this is just an open area from the imagery I can't see much evidence of a path, is there anything on the ground?

Though true these should have been with the :lanes suffix like you added, but the destination part comes from you being allowed to drive in a bus lane if you're accessing a driveway (ie. destination along the road). Not saying this is how it should work, but it's explains why.

the tags you removed here were lane tags, so the access restrictions only applied to the left lane not the whole road. This is tagging per osm.wiki/Australian_Tagging_Guidelines#Bus_Lanes_and_Bus_Only_Lanes happy to discuss if this is correct or not but probably needs a wider discussion on the list.

Oops, good catch.

Okay thanks for the explanation. However in that case motor_vehicle=no is not correct because it blocks even residents from access. For no through routes the documented way to may this is with the destination access value, see access=*#List_of_possible_values ie. motor_vehicle=destination. I've updated the tag based on this.

I've also added the turn restrictions as I could see from Mapillary and as you've indicated here at the Gas Works Road end.

PS. it's fine to use @username for the twitter details, contact:twitter=* specified that either the page URL or @username is fine.

Do you need a relation here? You can add a way which covers the grounds and then add any buildings inside the grounds, and then the spatial relationship shows which buildings are part of the fire station. eg way/42441888

Okay I've made the changes in changeset/90860679 happy to discuss.

direction=*
board:title=*

justification here is that board:title=* is documented and in-use and probably better than "name" when applied to information boards.

Similar to traffic_sign=*#As_part_of_a_way adding signpost node to the way to make it clear it applies to the way and add a direction tag.

I believe the name was the label on the sign, if we are changing the wording to be a description and not exactly as appears on the sign, that should be the description tag.

I'd prefer we don't split the way to make a small section visible.

Similar to traffic_sign=* you could place the node on the way and add a direction tag to make it clear which way the sign applies to. Then map renderers can choose to render it better. This is my preferred option.

This signpost isn't blocking routing in the north direction along way/229050520, while true that visually seeing this name here might be misleading, that's not a data issue. I think given it's so close it's reasonable to snap this node to the path so that it's linked to the closed track, or potentially use a relation to link it to the closed track.
You could argue that the signpost text content shouldn't be in the name tag (I'm on the fence about this), but deleting the name isn't a solution here.

I think there is enough uncertainty in Nearmap's terms of use https://www.nearmap.com/au/en/legal/terms-of-use compatibility with OpenStreetMap to say that Nearmap customers can't derive data from their imagery and upload that into OpenStreetMap. We need to be clear that any derived geospatial data from tracing or observations from the imagery have no restrictions on use that would be in conflict with OpenStreetMap's license. Until there is enough evidence that tracing Nearmap is okay in OSM then Nearmap shouldn't be used.