Please take care moving features when editing with iD as it will snap unexpectedly. node/3018096089/history#map=19/-33.81230/151.17152 was incorrectly snapped to the tunnel in this change. I've fixed it now.

Given these are not current military installations, only historical I believe we should use one of the lifecycle prefixes osm.wiki/Lifecycle_prefix

I've restored node/2921282680/history which was deleted here, and merged in your changes, it's important to try and retain the history of existing objects when you are making improvements to the data.

That syntax does conform to the proposal at osm.wiki/Proposal:Defaults so I'll change it.

What about if we did something like this?

def:operator=City of Sydney&highway=residential;maxspeed=40

It doesn't. It tries to make some assumptions that mostly residential roads are controlled by the LGA and will mostly be 40km/hr. However we know that might not always be true so best to always explicitly tag maxspeed on each way.

As I understand it, these tags for setting the default aren't implying that there's never exceptions.

Do you think we shouldn't tag a default residential limit for City of Sydney in this way?

"data I've held for a long time originally obtained from the DMR/RTA in the 1980s" is likely not a compatiable source for use in OSM due to copyright. We have a license to use the open data from https://data.nsw.gov.au/data/dataset/1-52821edb8608470abf117897b6ef7385 which may be used. That said if planning to bulk import these, it's best to discuss your plans with the community first for feedback.

This changeset has been reverted by changeset/154001143

I mixed this one up with the tree edits, but still from my perspective these kinds of edits border in the region between an import and an enthusiastic mapper. An enthusiastic mapper taking a lot of photos and mapping in OSM from those photos is core to OSM and we don't expect the data to be perfect. It's just on the other end where we have automated feature detection and automated imports, the potential to cause harm is much larger so we have osm.wiki/Import/Guidelines as a way to try and support imports while minimising the risk of harm.

It's hard to review these without the source images you used, but from what I can see in the imagery we have around node/12032276774 you have placed 4 trees, but I can only see the eastern 2. Are these new plantings? Or false positives?

done

way/1254815681 I can't see any footpath here, with nothing on the ground I would suggest we delete this one. Thoughts?

secondly, I feel the name "TfNSW Traffic Controlled Site X" is a description and not a proper name per osm.wiki/Names#Name_is_the_name_only

If feel the information would be better encoded with ref=* for the number and operator=* for the operator.

Since I can see you've worked on a lot of traffic lights, is this work all from a ground survey?

hi, I've moved the ref=0634 tag back onto the traffic signals nodes after it was re-modelled. I can't see any documentation on the type=site site=traffic_signals relation, did you come up with this scheme or was there some documentation somewhere you referred to?

I don't have any local knowledge here, but the physical attributes here are less important (and are mapped as their own objects or tags on the ways for data consumers to consider), based on importance in the road network with this road appearing as the main connector to the town tells me it should have a high classification.

Hi Harsimranjit,

A few things, if you're only relying on this dataset, then I don't think you should be replacing existing speed limits data in OSM, as how would you know this dataset is correct and OSM is not?

What you could do is use this data to as a hint to check other sources like aerial imagery and street level imagery and then perhaps use this to add a changeset comment to the original contributor.

Third, looking through you're account it appears you're importing this dataset and if so then you must follow the guidelines at osm.wiki/Import/Guidelines

Yes, I have no idea why I did it that way, fix now. Thanks for flagging.

While I still don't fully support mapping like this, at the very least I've removed the descriptive names and fixed the incorrect (upstream) directions.

fortera just pointed out that this source is on data.sa.gov.au and therefore falls under the existing DataSA waiver.

> OSM definitely is cautious about using data sources and I have always respected that

did you end up reverting those SA speed cameras you added from these non-compatible sources you mentioned at https://lists.openstreetmap.org/pipermail/talk-au/2021-April/014539.html , honest question I couldn't find a response to the original thread.