I'll fix this but also wanted to point out here that https://pewu.github.io/osm-history/#/way/760475671 was deleted only to be re-added again https://pewu.github.io/osm-history/#/way/802774744. I'll fix this by reinstating the original building tagged as a shed, but curious about what happen in the process which caused this?

> offset started up there

It's a good idea to re-check your offset as here it was quite a bit off from the GPS traces.

> Oh this is for a HOTOSM project by the way.

Yep I saw that, any idea who organised it?

> Wait I also noticed you unmapped all of the buildings I mapped. Do I really have to redo this again?

I reverted the whole changeset to reinstate the path and revert the road shift, I noticed a few other changesets which shifted the roads too which I'm working through reverting but it's quite hard when there are ongoing edits in this area. I can try to reinstate the buildings you had mapped.

Hi I've re-classified a few of these roads as driveways or forest/agricultural tracks. What source did you use for these roads, a few of them are very unclear based on the imagery.

hi I've reverted this change since it shifted the alignment of roads, which put them quite off compared to the GPS Traces Layer. I also restored the deleted path. If imagery is not aligned you can manually set an offset using the GPS traces layer as a reference.

https://osmlab.github.io/osm-deep-history/#/way/143812389 I believe freqency=0 indicated it was dc, did you mean to remove that tag?

The section at https://www.mapillary.com/map/im/OGNWdJkgd0Pk3viFIxjHnA only looks like shared lane heading west, heading east it's one of those doorzone cyclelanes. I've updated the tag, but if this has changed since my mapillary capture just shout out.

I've reverted this changeset since the other changesets by this user appear to be fabricated and/or spam and so don't think we should be trusting this change. Indeed the OpenStreetCam imagery here does not confirm any Telstra office, telephone exchange or mobile tower and so likely this was also fabricated.

This changeset has been reverted by changeset/84587904 as suspected fabricated and/or spam.

This changeset has been reverted by changeset/84587904 as suspected fabricated and/or spam.

This changeset has been reverted by changeset/84587904 as suspected fabricated and/or spam.

This changeset has been reverted by changeset/84587904 as suspected fabricated and/or spam.

This changeset has been reverted by changeset/84587904 as suspected fabricated and/or spam.

cycleway=lane only needs to have a marked (painted) separation from vehicles, whether that bicycle lane is in a door zone or not is irrelevant to if it's a cycle lane or not per the OSM definition. ie. being in a door zone does not all of a sudden mean it's not a bicycle lane.

The tagging list discussion on how best to tag a door zone is at https://lists.openstreetmap.org/pipermail/tagging/2020-May/052328.html and my preference from that discussion is cycleway:lane:doorzone=yes. I'm working to put this through a formal proposal process so it can be an approved tag, then data consumers can look for this tag. In the meantime this should still be counted as a bicycle lane.

Since cycleway=doorzone is has not really been discussed or gone through a proposal process, I feel we should still use cycleway=lane so data consumers can still make use of this. cycleway:lane=doorzone has been used in Australia to mark cyclelanes which are in a doorzone but now this conflicts with cycleway:lane=* so we need a new tag, but to replace cycleway=lane with cycleway=doorzone I think needs to be discussed.

I've reverted your change for now.

When I surveyed this a month ago there was still some evidence that the used to be a track here, so I marked it using the lifecycle prefix osm.wiki/Lifecycle_prefix as an abandoned track "Still visible but fallen into serious disrepair and which could only be put back into operation with considerable effort". Unless it's completely regrown with nothing left visible on the ground, it wouldn't hurt to leave it here with a suitable lifecycle prefix.

What happened to the elevator?

I've removed it now then.

As mentioned on talk-au, lcn=yes is valid on ways which make up a route. The network tag can go on a relation, but I don't think it should go on the way.

node/7443163061/history is there anything on the ground here?