I've just gone through and deleted a lot of duplicates you've added. Bear in mind that many features are mapped as ways and so to ensure we only have one feature in OSM you don't need another node inside, which was the case for the vast majority of your edits, so I've deleted these.

Hi GIID,

Welcome to OSM. Just bear in mind that "So, please, don't make any changes." is not in line with how OSM works, we're a collaborative project and the data is maintained by contributors, of which any one can contribute or improve upon the data you've entered.

You might also want to see osm.wiki/Verifiability, we strive for verifiability and things like restaurant ratings aren't a good fit for OSM since they are subjective and we can't survey them. Where have you sourced these ratings that you've entered from?

Hi in this changeset you added lit=yes to way/34233840 in May 2018 however in my Mapillary image from July 2018 there is no lighting poles visible https://www.mapillary.com/map/im/9_48jZW2lWIcBU9FQkhz4Q are you sure this way is lit?

Hi looks like this change the east bound road of Captain Cook Drive unconnected with Wollooware Road North is that right and still the case now? changeset/81703749 re-added some of those connections for traffic, but without ground level imagery it's hard to verify which is correct.

Is your only source NSW LPI Imagery? One month ago this area was changed in changeset/80055995 due to re-development and construction to remove the turns.

Hi I can't see any evidence of a cycleway at way/286201267 see https://www.mapillary.com/map/im/vYDHTuJkM619XNBMk6GjAw has it since changed since July 2017?

I've changed this back to footway for the time being.

Hi welcome to OSM, if you're adding backyard swimming pools could you also set access=private so that people don't start showing up to the house expecting it to be a public pool?

hi there is nothing on the ground I could see that indicates way/209792992 is a shared path? Could you point out where the signage is so I can verify?

I've changed the Duck River back to waterway=drain since this is what it is on the imagery, not a waterway=river as you retagged.

Hi Seb

I noticed in way/473020371 you added a few cycle tags. Per cycleway=*#Shared_cycle_lanes since there is no distinct motor vehicle and bicycle lane, instead both share the same space this is just cycleway=shared_lane.

Then since it's a shared lane, cycleway:lane doesn't make sense anymore.

On top of this I'm not sure what cyclelane=yes is for?

Lastly it's not wrong to add oneway:bicycle=yes but this is already implied by oneway=yes so not necesarry.

hi and welcome to OSM.

In some of these there were already lanes:forward+lanes:backward which added up to a different number, and comparing to the imagery you used I changed a few back to what they were before since this is what matched the imagery, but a couple of the ones you added were correct and I've left in place.

Yep, it's good to map them individually, with fitness_station=* on each of the nodes, but then just a single leisure=fitness_station. This is more in line with the wiki recommendation and osm.wiki/Good_practice#One_feature.2C_one_OSM_element. It means data consumers can know there is 1 fitness station here with multiple equipment.

See leisure=fitness_station.

"Similar to playground equipment, individual exercise equipment within a fitness station should be mapped individually as separate nodes inside the fitness station area using fitness_station=* for the equipment type.

Alternatively it is acceptable to describe the available equipment on the leisure=fitness_station object with prefix-tags in the format fitness_station:<equipment_type>=yes."

So there should only be one leisure=fitness_station.

I've fixed this in changeset/81202581

Which maproutette task is this.

The relation is the top level feature for the suburb relation/5682414 and already has the wikidata, it's easier to maintain if we avoid duplicating this on the label node.

I haven't been here and don't have the local knowledge, but from what I can see from the aerial imagery it looks perfectly mapped now, and when comparing with the LPI Basemap it looks contained within the two lots of the park.

> The Krauts map amenities as node primarily. Additionally the surroundings may get building=fire_station; landuse=commercial but they do not carry further information like branch or telephone numbers.

We'll here we map as accurate as we can and try to map what's on the ground. Usually fire stations have grounds where buildings are located, equipment is located and trucks are parked so it's a more accurate model of reality by using an area for the amenity=fire_station than an arbitrary node.

I agree with Hb- here, we should map what's on the ground, the park in OSM should match where it exists on the ground, not where the legal boundaries are, which is in link with he good practice guideline Hb- pointed out.

Thanks for explaining the background of this edit. I think it's okay if you see a photo or read a book which hint you to look at a particular area in OSM that might need updating, however it was pointed out that the fence is not visible on imagery, so how are you determining the exact geometry to use?

Hi @vakulya Given the license of the source you've used for this data isn't compatibale with OSM I've reverted the admin boundary in changeset/81089443/.

Please next time don't import data from sources incompatible licenses and if in doubt feel free to reach out to the local AU community on the talk-au mailing list.

I'd also like to point out an import of admin boundaries is planned in osm.wiki/Import/Catalogue/PSMA_Admin_Boundaries