Yeah in fact traffic_signals and tidal flow signals are the only two types of street_cabinet=traffic_control I can think of. I guess variable message sign could be considered since the messages are designed to stop traffic or slow traffic or tell them one route is closed.

Per man_made=street_cabinet#Street_cabinet_categories I think street_cabinet=traffic_monitoring is a better fit than traffic_control. These devices all appear to be related to traffic monitoring rather than control, although I'm just guessing.

I guessed that TC was for Traffic Counter or Traffic Classifier based on node/12282844010 being TC. You can see the road markings where the embedded device is installed, but not sure about this location.

hi I can see a number of issues here.

1. https://www.mapillary.com/app/?pKey=178701610829910&focus=photo seems to show a bike lane between the left turn lane and through traffic lanes. while I couldn't see any bicycle signage, I think it still can be considered a bicycle lane, there's no other reason they'd paint the road like that otherwise.

2. It appears you've removed a number of other valid tags like turn:lanes and lane width tags.

I think best we revert this change, unless you had any other comments about your change?

It looks like we already have a childcare mapped at node/12311154657 which is now duplicated at way/113359611

If we only have 1 childcare here there should only be 1 OSM object marked as childcare per osm.wiki/Good_practice#One_feature,_one_OSM_element

It looks like there's also a shop in the same building, so in that case if the childcare doesn't occupy the whole building best to use the node and not apply childcare to the building.

from your link this looks like a shared path, not exclusivly for bicycles only, is that the case?

If so in iD there is a "Shared Path" preset otherwise best to apply both bicycle=designated and foot=designated then segregated=no.

Previously it was tagged `compacted` which is "A mixture of larger (e.g., gravel typically 20mm) and smaller (e.g., sand) parts, compacted (e.g., with a roller), so the surface is more stable than loose gravel." per surface=compacted

You'll also see on the wiki that many roads signposted as "Gravel Road" in Australia would be tagged surface=compacted and not surface=gravel.

The `gravel` value is documented as "This tag has very large meaning range. Used for cases ranging from huge gravel pieces like track ballast used as surface, through small pieces of gravel to compacted surface." Typically I'd use surface=gravel for larger railway track ballast type of surfaces, then for fine gravel use surface=fine_gravel surface=fine_gravel

For a highly landscaped area like here it seems unlikely to be surface=gravel and surface=compacted seems more likely.

OSM tag values can't always be literally interpreted because this interpretation varies a lot among geographies.

This changeset has been reverted in changeset/162810447

This changeset has been reverted by changeset/162810411

This changeset has been reverted by changeset/162810358 due to the above mentioned reasons.

Longstanding OpenStreetMap principals include

1. Do correct errors -> osm.wiki/Good_practice#Do_correct_errors

2. Don't remove objects that you don't need or like -> osm.wiki/Good_practice#Don't_remove_objects_that_you_don't_need_or_like

In this case, the these existing building features are reasonable, and in my view they are pretty good. If you don't agree you're welcome to improve them, but don't delete others work just because you don't like it.

We'll revert this change, please avoid this going forward.

way/1316363251/history is non existent

I've reverted node/12381862239/history in this case you added a highway=crossing between the surface road and the underground walkway. Yes iD issued a warning here, but it's a false positive. Please take care when editing.

way/1249459181

man_made=water_works is "a facility where water is treated to make it suitable for human consumption before being sent to the water network." per the wiki.

However the building is labeled "SPS", which is per osm.wiki/Sydney_Water a Sewage Pumping Station. A water_works (water treatment plant) would be WT.

I've since added this detail to the building at way/1249459180 so I'll just leave the landuse but remove water_works.

The Curve and Gradient diagram has unclear copyright and per osm.wiki/Australian_Data_Sources#New_South_Wales we don't feel comfortable using it directly as a data source.

Possibly these buildings should have ref=A through ref=K?

hi the traffic cabinet was already mapped at node/12470392128 and you've added a duplicate, I'll add your new tags to the existing node.

Firstly I value local mappers and everything to do with this import was done in consideration of how it would impact mappers, the intent was to support local mappers and minimise disruption and grief. So I'm disappointed that you feel otherwise.

You don't need to be active on the community forums, but at a point we need to collaborate as a community, you don't need to partipate, but if you don't then you may miss out on an opportunity to shape the project direction.

The Community Discussion points were documented at https://gitlab.com/alantgeo/vicmap2osm/#community-feedback with most of the discussion happening in the thread at https://lists.openstreetmap.org/pipermail/talk-au/2021-May/014622.html

You're welcome to take this up with the DWG, of course I welcome any review of my work on this import, at all times I've tried to balance all community feedback and points raised. The vast majority of feedback I've recieved has been positive, but I do understand you feel this import missed the mark for you. In a broad community, not everyone will be happy.

Regarding your specific issue, you're arguing that addresess should have been added to existing buildings rather than as nodes, and that's you're only issue? Take it up on the community forum, and we can have a discussion there.

But regardless I'm still not seeing how the integrity of the data in OSM is compromised by this import. It didn't delete any existing addresses, and mostly didn't add any duplicates, or even modify existing ones even when Vicmap data disagreed with what was in OSM.

A valid option from the community could have been "no we don't want this data imported, we'll keep adding addresses by survey only" however this was not what I heard from the community, I head that an import is best.

If you want to do an automated edit to merge these address nodes onto the buildings, then please as an automated edit please post your plans and methodology to the community forum for review and discussion.

See destination=*

`destination=*` should go on the road you turn into, not the road you turn from, but it only really works when there it's not different from each of the from roads, and even then it's usually for a place not a street (see destination:street=* for that). On the first wiki page you can also see there is destination:lanes which can be set per-lane on the from way.

However there is yet another method (first was destination on the to way, second was destination:lanes on the from way) which is use a relation, which exists here at relation/10699075/history this can capture more detail about the destination sign.

No worries, I didn't look back to see it was building=building before.

skyscrapercenter.com is a database, which holds a vast collection of information about buildings, they consider this their proprietary data and while their terms mention "public use" after I asked them about use in OSM they clarified that commercial use of their data is not permitted. Since OpenStreetMap publishes data under the ODbL license which does allow commercial use, we can't use their data at all. That's why I removed those tags because it was all copied from that website.

What someone needs to do is go survey this building and measure the height and count the number of levels, and see what's there, is it offices, residences, then use that survey to re-add that information.