Thanks BaileyNelly and nevw.

Don't think it would be a 'park' then,

Could be boundary=hazard, hazard=contamination and even contamination=lead ...

relation/17803642 is wrong in several ways...

building= one thing or the other not hospital;roof..
Multipoygon outer ways cannot share segments!!!

--------------------- corrections...

way/17803642 building=roof, layer=1

way/276984375 building=hospital, name=Normanby House

This simplifies things to one OSM entry for one feature.

Hi,
The multipolygon relation for the picnic site does not meet the 'multipolygon rules'. I have deleted the relation. Made the south western area into the camping area, and thee north eastern area into the picnic area. See what you think?

I have removed this 'park' from the Marine Park.

The 'park' appears to contain some houses... The 'park' does need some explanation.. does not appear on the Regional Council webpages.

Hi,
Welcome to OSM!

For information... multipolygon outer ways cannot share segments.
relation/17806381 has been deleted. What were the outer ways are now tagged building=retail.

The bing imagery looks to have an offset to the OSM mapped roads by 5 metres..

The different tool looks to be metro only .. that would not cover the Gahn, India Pacific etc.

These and not part of PTv2 'stop_on_demand', 'stop_entry_only' etc. Useful - yes. But not part of the original PTv2. These additions should make it a new version...

Arr found it. Unfortunately not compatible with PTv2 .. raised on the wiki suggested using PTv3 and keeping PTv2 for the present.

Why remove the platforms???

Recognized roles are 'stop' not 'stop_on_demand', 'stop_entry_only' and 'stop_exit_only' - all rejected by QA tools... see https://tools.geofabrik.de/osmi/?view=pubtrans_routes&lon=148.82043&lat=-33.21512&zoom=9&baselayer=Geofabrik%20Standard&overlays=ptv2_routes_valid%2Cptv2_routes_invalid%2Cptv2_error_ways%2Cptv2_error_nodes%2Cptv2_routes_valid%2Cptv2_routes_invalid%2Cptv2_error_ways%2Cptv2_error_nodes

Why have the platforms been removed from the relation/16305120 ???

The relation role 'stop_on_demand' does not seam to exist? It is being rejected by the QA tools.

Hi,
Multipolygons outer ways cannot share segments .. so the relation is faulty.
The DCS Base Map is another source for the legal boundaries of things. For instance the road side footpath is not part of the park but part of the road infrastructure .. comes out of a different accounting pocket.

I have made some 'corrections'. See what you think.

Ok .. I hjave locally reverted this changeset .. and that looks like it confirms that this changeset is the cause of the issue..

I have fixed up 2 problems down in Vic. that may also be caused by these reversions. Is the name of the beaches the only issue?
Might be better off using a different reverter and notifying the author of that reverter..

Hi,

Not certain what is going on... but there are a number of issues with both the coast line and the Great Barrier Reef World Heritage Area relation/10156269 - self crossing ways e.g. Way: 20670282 and relation not closed.
Is this a reverter fault???

Hi,
In Austrlai we associate an address with a building, not the entrance way. In the case of Node: 12008941940 this appears to be the entrance to a vehicle garage, not the residence.

The address for Node: 12008889339 is incorrect, see the DCS Base Map!

The buildings appear to be offset and not well recognized. Use the DCS Imagery for better resolution and location accuracy. Observe the vehicle driveways to see which are garages?

2 month later?
See changeset/148866385 .. the mapper did not respond, the listed source did not support the entry.
Is this now residential, not planned nor under construction>?

Reverted.

A source for admin boundaries that is easy to use is the DCS Base Map.

Please don't damage a boundary such that it is not useable, fix it yes but damage no.

Where the address should be is 'contentious' within OSM. Some think it should be where the post goes - a 'letter box'...
However it should only be on one feature, that is the OSM guide.

See osm.wiki/Addresses

The role 'address' in a relation .. will probably be flagged as an error in the QA tools.. so those will need to be looked at.

Hi
Welcome to OSM
Concerning relation/17722831 -farmland;
If this has an address then the address tags should be on the relation, not on a node as a member of the relation.
As the address is within a building I have left that there - deliveries would then be directed to that building. I have removed the address node from the relation, but added the farmyards as inners in the relation.

The address node in the relation raised a flag in QA tools that I use, hence my interest here. Keep mapping!

Ok,
I have attempted to detail this library...

The building base is way/1292752686 - this carries the tags for the library. It should have the highest level tagged on it.. I think arr yes .. building:part=*

I think I have it right, please check it!
Other than the base library way above the 2 other ways are ;
way/205303849
way/159946355