I tried to survey this, but couldn't work out how to get access, at both the Pacific Highway onramp and Ku-ruing-gai Chase Road onramp there are no bicycle signs on M1 present.

ah I went looking for this once, seems I was way to far north on the Freshwater side. Maybe next time I'll succeed, thanks for correcting the geometry.

Ideally you'd do both, split the way and mark the section of road as private and if there is a physical barrier like a gate then add barrier=* with access=* on the node.

No worries thanks for confirming.

Hi AntBurnett,
FYI that the waiver we have from Nearmap which was used for the SSSI mapathon has strict condition of "data on bushfire affected areas" per the second waiver at osm.wiki/NearMap_PhotoMaps

So you could only use the imagery during the event and for the bushfire affected areas. Can you confirm if Nearmap imagery was used here or it was simply still on in your editor?

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).