This changeset has been reverted in changeset/162275515 due to use of proprietary data in the changes.

This changeset has been reverted in changeset/162275408

I reached out to CTBUH and heard back that "Republication of our data for commercial use in not allowed." and they did not provide a waiver to this, therefore on this basis the data is incompatible with OSM. We'll need to go through and remove all instances where you copied this data previously, and please going forward don't use their data as a source.

For building heights i would recommend other sources like compatible LIDAR data, a physical survey, or photogrametry.

While it's good they do include some information about the use of their data, I still feel "public use" is not clear enough. For example if I build their data into my commercial product and sell it, is that public use? because it's totally okay to do that with OSM data.

Even with regards to attribution, we usually confirm that a listing on osm.wiki/Contributors is sufficient, because we can't guarantee each item will directly include attribution.

It's nice to see the interest in improving our building heights data, however you can't use proprietary data when editing OSM osm.wiki/Copyright#Proprietary_data.

While sourcing a fact might be okay, in this case doing a bulk sourcing of their database is not okay. While their licensing terms at https://www.ctbuh.org/about/faq mention "public use" this is unclear.

hi could you please document your source of these building heights? It's a bit hard to claim you're "fixing" them without backing up how you came to these results?

Also for example way/466884767/history I set both ele and height, so that you can obtain the elevation of the top of the building, which could make 3D rendering more accurate as you're less dependent on the DEM, adjusting just the height without changing the ele would move the top of the building elevation.

Is this based on local knowledge, or otherwise how do you know this?

At the Newell Hwy intersection here, I couldn't see any street signs on the street level imagery, and further south we don't have any street level imagery, so it's unclear.
It was originally named based on DCS data, which still records it as Sherriff. I have no local knowledge here but it appears this follows the original Sherriff street before the new bridge was built.

Based on the DCS roads data and DCS address data, Wambat Street only starts south of the lake.

Okay but according to the wiki "boundary=protected_area is used to mark boundaries of protected areas", that's a very broad definition, but "Wiildlife Protection Areas" seem like they should come under this tag.

I don't have any knowledge of IUCN, I simply read the documentation on the wiki for protect_class and found the best match, like any other tag in OSM.

I guess it also comes down to is protect_class meant to be for the officially assigned class, or is it just an OSM tag which can be applied.

In the same way that we set sac_scale on walking tracks here even though nobody is assigning official sac_scale values to tracks.

Sorry but I still don't understand what this has to do with iucn.org.

Yes these may not be in CAPAD but that doesn't mean they aren't protected areas for species protection.

Regardless, the signage present at these locations indicates these areas as "Wildlife Protection Areas" with details showing the intent by the council that they are for the protection of native animals.

At a minimum could the backyard trampolines way/1356111675/history be tagged access=private to indicate they aren't part of a public playground.

https://www.northernbeaches.nsw.gov.au/environment/native-animals/wildlife-protection-areas

> Wildlife Protection Areas are public places set apart for the protection of our native animals and their habitats under the NSW Companion Animals Act, 1998.

From protect_class=*

> Habitat/Species Management Area (IUCN Category IV): "...aim to protect particular species or habitats and management reflects this priority

Either way it's still a protected area and protect class 4 seems the correct class. If there's no objection I'll reinstate it.

I missed this change earlier by why was boundary=protected_area removed? It's a Wildlife Protection Area with protection_title tagged and should have protect_class=4.

2. It should be footway=crossing for the crossing sections not footway=sidewalk.

Please try to keep the history osm.wiki/Good_practice#Keep_the_history of objects

This way way/898239664/history could have been retained and amended into the new way you added way/1356111699/history

Keeping the history makes it easier for others to understand the history of changes and to attribute those who contributed.

I'll echo TheSwavu's comments, this was already discussed. It was a conscious decision not to merge addresses onto other features on the map as part of the import.

Firstly there's different ways addresses can be mapped, as a lone node, on the building, on the landuse representing the lot, and the import took the simplest option leaving it to local mappers to decide the best option for each location.

Secondly, there is more risk merging to buildings, particularly in areas of high density, like narrow terraces the risk of mis-assigning address to the wrong building was too high so this was left to be done manually.

The notion that it requires cleanup to attached addreses to buildings in an opinion about how addresses should me mapped, it's also not incorrect for them to be simple nodes, so I reject that they require cleanup. You may improve if you like, but it's not required.

way/526335498/history

what's the reason for removing the gas pipeline way/526335497/history ?

Per osm.wiki/Abbreviations we try to avoid abbreviations in the name no in this case the name should be "Avalon Beach Surf Life Saving Club" without the "(SLSC)" bit at the end.

If you want you could tag short_name=Avalon Beach SLSC

Thank you. This is because I was using StreetComplete EE trying to edit tags directly without any field presets to guide me.