I didn't hear back so have reverted this in changeset/93389097 based on the Mapillary imagery here, though I'm still interested to hear a reply back when you can with further information about your change.

not sure if you read amenity=university#Complex_areas but it says there is no agreed solution for campus names vs uni name. It says you could use the name for the campus name and operator for the uni name, but I don't think that's helpful here. I went to uni here but generally just know it as UNSW and don't think of it as the Kensington Campus. Maybe for now we can just add a tag campus=Kensington

If those school buildings weren't originally build as residential homes then it should be building=school instead of building=house see building=*

There's a lift gate, not sure exactly what the mechanism is but it makes the road itself restricted to drive through even without doing a dropoff/pickup.

Hi could you please confirm your source for this? The signage from 2019 says this is "Taxis only" and directs "All other vehicles" away from this road https://www.mapillary.com/map/im/gn1tchPjWyM9_AB6XGoi5Q

I'll point out is_in=* which you may or may not have seen, and to quote "The is_in tag pre-dates boundary polygons. When a region has a well developed set of boundary polygons the information that could be placed in the is_in tag on an object can usually be derived from the boundaries that contain it, in which case the information in the tag seems redundant. Some contributors have advocated deleting this tag because they see it as equivalent to the boundary information. Other contributors consider that view to be short-sighted at best."

My view is this is redundant because the data is already implied by this being geographically within the NSW relation, and it's a waste of effort to tag every single feature in NSW like this when it can easily be determined.

That might be an issue for the https://github.com/osm-search/Nominatim project, since you're talking about the Nominatim API which is a project which uses OSM data.

For example way/326321292 doesn't have addr:state=NSW tagged, yet Nominatim does infer the state from the NSW state relation see https://nominatim.openstreetmap.org/ui/details.html?osmtype=W&osmid=326321292&class=building

However checking the one you mentioned the Bulli Tops place https://nominatim.openstreetmap.org/ui/details.html?osmtype=N&osmid=113322767&class=place it is not inheriting the state.

Maybe something to ask Nominatim if that's intentional or not.

Sure you could go round and add addr:state=NSW to all of these, but personally I think it's good enough to determine this from the state relation.

The city (node) is mapped at node/20920968 the suburb (node) is mapped at node/6071581395 there should be one of each because Wollongong is both a city and a suburb. Generally you'd just use a point in polygon check to find which state they are in.

hi, thanks for the edit. The old BP tags were on the grounds not on the building, so I've transferred the ones you added over to the grounds to replace the BP ones and restored the building=retail tag on the building way.

Yeah I'm with ortho_is_hot, it's standard to have a node with role=label which is important to:

1. de-dup the point and relation (so users know they are for the same feature), while still giving data consumers the flexibiltiy to choose points or areas based on their needs.
2. Provide a suggestion for label placement which is near "center" of the suburb, which might not be the same as the centroid or other label placement algorithms.

I think we should roll this back, but still keen to hear your motivation and reasoning for this change.

For way/849190283 if it's in someones backyard, best to add access=private, so when the public is looking for places of shelter they don't get routed to someones yard.

I think it's unlikely that at these points this far upstream that it would have enough flow to be classed as a river. Generally the name is irrelevant to the tags just because it's named Kedumba River doesn't mean it must be waterway=river. If it's got less flow and not that wide then waterway=stream is better.

Looks like iD will "upgrade" the building=commercial into building=yes https://osmlab.github.io/osm-deep-history/#/way/23693353. Probably should be building=retail, but unless you've looked at the building tag you should inspect the tag diff that the "upgrade" would do and if it breaks the building tag it needs to be manually fixed.

Hi, in this changeset you added duplicate streets on top of the ones which were already there so I've reverted this change.

Yeah and I agree with mos6510 that the changeset comment is just saying the imported data is rubbish, not the person doing the import or process of importing, so don't see this as publicly degrading the contribution (which is the act of importing/tracing existing datasets).

I do think we place too much trust in this "imported" government data. OSM has always been from the start first and foremost from field surveys, supplemented by imagery. So while generally I'd say we shouldn't just blindly track LPI data to provide a base data where no existed prior, if it's already been done, then I think let's try and focus our efforts on moving forward. So be bold in fixing issues, especially if it's originally from data without a survey.

From the imagery you used I can't see way/863483510 as a road, and the DCS/LPI imagery also shows no road here, only a few seats, so unless you have local knowledge or a better source I'll remove this road.

hi, welcome to OSM. It looks like you've realigned a few roads based on the Maxar Premium imagery layer. You'll notice if you swap the imagery layers there aren't all aligned with each other, so generally we'll use GPS traces of the roads as guide of where the road actually is. The more GPS traces we have then the more reliable we can align things. You can turn on the GPS traces in the iD editor under Background > Overlays. In this area here the GPS traces indicate that the LPI/DCS Imagery is pretty well aligned so best to have everything aligned to that.

hi in your changeset here https://osmcha.org/changesets/91076437/ you've dragged a node from another road, I've fixed that now, but something to watch out for next time.

hi, The Court road was actually broken from a changeset before yours version 2 at https://osmlab.github.io/osm-deep-history/#/node/701823806 so to properly fix this road and keep the original history I've reverted your change and then the problematic one. Where there is an issue like this best to not try and fix it in the same changeset as other changes like adding buildings so that it can more easily be fixed. Because I reverted your whole changeset, I'll now reinstate the buildings you added here.