could probably even mark it as disused then with disused:highway=path per osm.wiki/Lifecycle_prefix#Stages_of_decay

reverted in changeset/161852842

firstly way/1302411156/history was added July 2024 Bing, and Esri imagery don't have dates, DCS is from Feb 2022. If you haven't done a survey and don't have more recent imagery, then don't delete. Or better yet ask first.

secondly, if you check the original changeset I listed the source as Sentinel, obviously you didn't bother to check this otherwise you would see the construction.

I've since confirmed the rough locations via a survey.

This is not the first issue where you've deleted things based on outdated imagery, please take more care, review the history of objects you're unsure about and consider leaving a changeset comment first.

Please see osm.wiki/Why_can%27t_I_delete_this_trail%3F

Based on this guidance even if the trails have no public access, we still include them in OpenStreetMap data but with the appropriate tags setting no public access.

FYI footpaths should also have the footway=sidewalk tag

How did you trace or derive way/1326456127 since it doesn't appear on Bing Maps Aerial?

Actually I just realised I thought the tidal tag was meant to be used on any feature that is affected by the tides, ie. the full length of the waterway from tidal limit to where it ends at the ocean, but seems from tidal=* it should only be the small section between high tide and low tide.

Interesting. oneway isn't mentioned on waterway=* or waterway=flowline.

However while these are tidal bays and the current changes based on the tide, downstream is still towards the ocean and the way should be drawn that way.

What would oneway=yes/no even mean in this context that's not already covered by tidal=yes/no?

way/1279812527

I think calling this a building is a stretch. I believe it should be waterway=drain which I'm tried to document at osm.wiki/Sydney_Water#Sewage_Network

motor_vehicle=permissive means "Open to general traffic until such time as the owner revokes the permission which they are legally allowed to do at any time in the future." see access=*

It sounds like this one is not open to motor vehicles, but your tags indicate it is.

From Mapillary and imagery it just looks like an informally used path (highway=path) and not a track, in which case I'd just remove access=no and motor_vehicle=permissive

waterway=flowline was recently documented waterway=flowline as a suitable tag for this purpose and I've since apply the tag to these ways

waterway=flowline was recently documented for this purpose waterway=flowline

Yeah I did that one together with this one, changeset/161365383 I hope I got it right.

I added this based on the new school name appearing in the Geographic Names Register, but I realise the name can be approved well before the construction even starts and the location data isn't always accurate, so I added this one a bit too much in haste.

Looking into it more, it looks like the school will open in temporary buildings on George Street for Term 1 2025 at way/1004226287

I'll move this one across to that site, but any further local knowledge or improvements welcome!

Thanks! I didn't realise there were new boundaries here, looks like it was done 1.5 years ago too.

Thanks. I think we should the

1. Get a documented consensus that addr:suburb, addr:state, addr:postcode should not be tagged where they are inherited from the admin_boundary, providing reasoning and justification for this as well.
2. Take this consensus to iD and then request these fields not be included in the preset field.

It's not just this one, it'll all of them. I think systematic bulk changes like this should be first discussed, or at least discussed before continuing further.

Even changing cycleway/sidewalk:left and :right into a single tag https://osmlab.github.io/osm-deep-history/#/way/447120360 I think it's not helpful, while the two different ways of tagging can be interpreted as the same, for mappers entering data it's best to retain what was mapped.

I'll ask if you can please stop doing these validator edits, then I believe we should just go ahead and mass-revert all of them, then going forward systematic changes should be first discussed with the community.

Yeah in my view a lot of the JOSM validator warnings are too strict.

For example source:geometry is fine and acceptable to use to document the source of the geometry source:geometry=* even on nodes. It doesn't need to be changed to source:position doing so has no benefit and just creates noise which makes it harder for mappers.

level=0 is a good way to tag something as being explicitly on level=0, otherwise you can't know if it wasn't mapped yet or really is on level 0. In fact for this reason alone I think we should/need to revert all these "Batch edit tags using JOSM validator" as it's damaging the data.

Furthermore can you explain your exact process for these changes? Because it appears like an automated edit, or are you manually reviewing and applying fixes. If an automated change it should be discussed first.

Hi could you please advise the rationale behind theses changes? To me these look questionable and I don't think we should necessarily be actioning all JOSM validator issues.
---

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