Not sure what you mean. This changeset reverted changeset/142702991 which wasn't yours. I'll go ahead and revert this one as I can't see any justification.

Hi, could you please try to document your justification and reasoning behind a revert changeset in your changeset comments, it would really help the rest of the mapping community to understand your changesets.

In the first instance it's usually best to raise a changeset comment before jumping to a revert.

For this reversion I can't see it being justified, it removes the changes and transition tags which appeared correct.

Have you seen osm.wiki/Proposal:Traffic_signals_set_2 ? You might be interested. Ideally the signal nodes and the relation would have use ref=* set to the 4 digit code.

The name key is for the name only, description=* is a better option for descriptions to show to end map users. I've made the updates accordingly.

For slightly overgrown you might want to consider applying a trail_visibility value.

I've changed this to description per osm.wiki/Tagging_for_the_renderer

I'm keen to understand in more detail the rational behind this, and any references you can point to. I think from there it's worth raising a discussion about more suitable tags you could use.

The ref=* tag ref=* is usually a better number for reference numbers/codes than the name=* tag.

The ref:sap_equip_id tag would probably be better as something like ref:npws to indicate it's NPWS own internal reference (there's an argument for not including this at all but I'm not too fussed).

Some good discussion ongoing about this on talk-au https://lists.openstreetmap.org/pipermail/talk-au/2023-September/thread.html I'd encourage NPWS staff to chime in to the thread.

Not wanting something to show on the map is not a sufficient reason to not include it. I wouldn't rely on aerial imagery, many tracks which do exist won't show up as the imagery is not clear or there is simply too much vegetation cover. The lifecycle prefix is in my view the ideal solution, the tracks won't show up on most maps/routers, but the data still exists in the OSM database. Yes some people may still find this and explore them, but we've done out part by tagging them in a way that best reflects what's actually on the ground.

Based on your survey mrpulley, at least in the latter 3 cases it sounds like there would be something on the ground, so in my view we should restore these under the lifecycle prefix with access=no to indicate the closure.

To avoid an edit war, @Firefishy can you comment on if that would be problematic from your side?

Agree with @mrpulley here. If just not officially marked, then informal=yes, and if closed then use the lifecycle prefix if there's still some evidence on the ground.

osm.wiki/Australian_Tagging_Guidelines/Cycling_and_Foot_Paths#Closed/Illegal_Paths

Thanks.

In this case it's still better to leave the way in OSM and tag it as disused:highway=* and access=no. This would still remove the track from most user facing maps, while leaving it in the database to show there is a closed track present in the area.

It probably is officially West, but all the street signage I can see doesn't mention West, so if following on the ground signage we would omit it. So I'm not sure...

I noticed you've removed the cliff at https://osmlab.github.io/osm-deep-history/#/way/179935736 but this cliff still exists, could you restore it?

Hi Chris,

Please also see the current community guidance on closed/unsanctioned trails at osm.wiki/Australian_Tagging_Guidelines/Cycling_and_Foot_Paths#Closed/Illegal_Paths it's usually better to make it as disused and no access then delete it, especially where there is still some evidence of a trail on on the ground.

The point I keep coming back to is someone undertaking research of unsanctioned trails, ideally if they trail exist it should be in the OSM database for those research projects and tagging as disused and access=no would support that.

proposed is before construction, given the tracks are already constructed and the stations are under construction, I think we need something further along than just planned. So I support the change by kurisubrooks to turn the route back to construction.

hi, could you document your process in doing this in more detail? On the surface it looks like an automated edit osm.wiki/Automated_edits which would be covered by the Automated edits code of conduct osm.wiki/Automated_Edits_code_of_conduct which requires documentation and discussion with the community of your automated edit plans before actually doing the upload.

From my side I'm keen to understand how you validated these detection weren't false positives, and how you conflated with existing data in OSM to ensure you haven't added duplicate data?

addr:unit is for specific addresses not ranges.
addr:flats is for marking the ranges.

glad to hear

https://www.mapillary.com/app/?pKey=1207284873025559 has a vehicle gate, and the track certainly looks designed for maintenance or emergency service vehicles. The access tagging already specifies horse, walkers, bikes may use and authorised vehicles only.