I'm not saying driveway crossing is not unmarked, my thoughts are highway=crossing probably shouldn't even apply at all.

What I just posted on the Talk page is I guess I see a distinction between crossing a road and crossing a driveway, with a crossing on highway=primary you're crossing the road because you're walking along the sidewalk and need to get to the sidewalk on the other side, but with the intersection of a service=driveway and footway=sidewalk, you're never crossing to the other side of the road, you're staying on the same sidewalk, just you reach a point where vehicles may cross your path, so I don't see this intersection node as the same kind of feature.

crossing=unmarked includes driveways as a tricky case and simply acknowledges that sometimes highway=crossing is being used in OSM (it's just documenting usage "as is" in OSM) and also says "if such place would be considered as taggable with highway=crossing".

It's true, as a data consumer, I can check the highway types of the intersection and drop these out if I don't want them, but I can also ask, if they are always unmarked and always should be highway=crossing, why even bother at all?

The reason I noticed these is they started spamming my StreetComplete quests with all the other crossing tags, none of which should apply.

some discussion osm.wiki/Talk:Tag:highway%3Dcrossing#When_should_a_sidewalk/service-road_crossing_be_tagged_with_highway=crossing?

My understanding is that highway=crossing is for street crossings per highway=crossing and should not apply if a footpath simply crosses a driveway. In this changeset I see a few instances of highway=crossing be applied on the junction of a highway=service and footway=sidewalk where that the service road is actually a driveway as opposed to a road like a laneway. I'm planning to fix these up, but maybe something to consider for your workflow? Are you applying an particular logic for identifying these missing crossings?

Given these roads just service small block residential houses, and don't connect to anywhere else I feel they should be classified as highway=residential. Do you think this is okay?

are you sure the school zone was removed at way/755189316/history#map=19/-33.878906/151.236409 ? From all the imagery sources I can see it's still there.

Thanks for your edits here, though I noticed you've used a lot of multipolygon relations eg. the parking areas, which I feel make editing more complicated. Is there a reason these couldn't just be ways which share nodes so the boundaries are snapped together?

Just looking on their website
> Residences One – Construction complete, ready to move in

> Residences Two – Construction to be completed September 2024 

> Watermans Residences – Construction to be completed December 2024

hmm admittedly I made this change based on the towers being complete, which I was thinking shouldn't be marked as construction if complete. Based on your photo I think we should at least convert way/1068760239 back to construction landuse. Do you think that works?

hi northchun, you'll find that in Australia, common practice has been to map out roundabouts as a circular way and tag them as junction=roundabout. I realise this does conflict with highway=mini%20roundabout?uselang=en but due to this longstanding practice you should consult the community before changing things around.

Regardless the style of mapping you've used here adding a single node not connected to the highway=* way is incorrect and would cause validation issues.

Are you sure this is not signposted for use by bicycles? Because this was previously tagged bicycle=designated (explicitly signed for bicycle use) and this changed it to bicycle=yes (bicycles okay to use but not designated as for bicycles).
I realise this is old imagery but https://www.mapillary.com/app/?pKey=562459894724126&focus=photo shows bicycle markings on the ground indicating the tagging should be bicycle=designated.

You also removed the ferry route from the way to Palm Beach https://osmlab.github.io/osm-deep-history/#/way/247939475 since then TfNSW have re-added it, but now the two tags conflict, so I'll remove the intermittent:route=ferry tag you added based. I agree that I believe Brooklyn to Patonga is water taxi only.

Is this not serviced by https://www.boathouseferryco.com.au/timetable?

I feel this is a bit unnecessary to split the way, it complicates the data model when a simple tag on the way to say there is a median barrier would have worked.

But regardless the lane tagging was not correctly updated, which I've now fixed.

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.