6. You have not asked beforehand though? Simply coming in and deleting everything.

1. Explain how they are wrong? Iterative refinement, mate.
2. Have you read what `=ridge` is for?
3. This is renderer problem then. Complain to them if you want them less visible. Or in your application, reduce their visibility. You are also deleting this for everyone. And , ah yes, you are using "hack tools" too now. iD is also "3rd party" if you claim this way. Are you uploading to the APi directly?
You are committing vandalism by mass deleting while claiming others are graffiti.
5. One Feature One Object. You have not added `=ridge` to `=path` either, which is still wrong. A `=ridge` is more continuous and longer. A `=path` has many attributes that can be split.
6. EDM is not the same as `=ridge`. SRTM is not the most accurate. Moreover, the contour is also generated artificially.

You yourself have attached a `=peak` to `=path`. So I don't know what you are complaining.

1. `=ridge` and `=path` are different things.
2. `=peak` are supposed to be on `=ridge`.

Other features should not be attached to roads. This makes editing difficult, and doesn't represent reality.

Please always improve objects. This is a continously refined process about increasing quality over time. Never delete them without replacement.

Pleae explain what you are doing.

The entire outline being `building=apartments`. The podium/base `building:part=` `=commercial` or `=retail`.

Please use `building:part=` when it is a single tower.

Also that's a `crossing=traffic_signals`, not `crossing=uncontrolled`.

It's not supported by signs to add `foot=no` when it is not signposted. `sidewalk=no` is sufficient at first.
There are many roads where it is not realistic to walk or bike, but have no signposted bans.

Some have also discussed whether `addr:building=` should be used. Perhaps it can be used in subbuildings ie `addr:building=1` + `addr:unit=1A` to show Tower 1A and 1B belongs to the same buildings. In this case, they are the same for one house, so not especially needed yet.
Another question is whether "Tower" or "House" should be included. For `ref=`, numbers are enough for blocks, and "Tower" is usually coded as "T1". But to generate an address with `addr:unit=`, it is unclear how it should be.

Thanks. There is another good question, as `addr:housenumber=` is the number used with street or village. It's unclear what blocks should use. I have used `ref=` and `addr:unit=` together for now.
(According to some definition `addr:unit=` can be used when "inside divides into different units or staircases, where certain apartments/flats/offices can only be reached through a specific unit", so it seems more applicable to subbuildings found in modern apartment towers, ie Tower 1A and 1B inside the same Tower 1 physically. Consequently, it looks usable for houses, as different buildings in a compound can be called "units" overseas. Shop "unit" in a building may be better off using `addr:door=`.)

`addr:place=` should only be used for villages which have address numbers assigned to them. It is very common to have housing estates within villages.

Also `usage=` should not be used together with `service=` with few exceptions.

This is already added as way/530830954 ?
Please don't attach unrelated features along areas. This makes editing difficult, and does not represent reality.

Please don't attach unrelated features to tracks. This makes editing difficult, and does not represent reality.
Unless the structure edge is exactly below the centerline of track, this does not make sense. The entire shape has also been broken here.

Please don't add random transliterations. This is unneeded, and doesn't reflect common usage.

Please don't attach unrelated features to roads. This makes editing difficult, and does not represent reality.

`name=` is for the most common name in existing public use.
Please discuss with the local community first before these changes. Use OpenHistoricalMap to show the full history.