I did NOT map for the renderer. As said, I *actually* did a survey myself and all pathing and stop positions (stop posts) were put down as they are *at the ground*.

Conversely treating the entire area as a single platform is not accurate at all. You mentioned multipolygon but let me tell you, mapping all those columns would need many, many more "inner" shapes. Paths both represent the ground feature more accurately and cause much less intrusion to the surroundings.

Sorry, I retract the word "hard to read". It only hurt my eyes, but I do think it's inaccurate and caused quite some problems.

The platform is bad or wrong for at least three reasons.

1. It does not address all the columns and structures in between. In effect that's not a single platform, but two corridors with a third in between for much (but not most) of their lengths.
2. It leaves a very bad looking dark grey area and covers up the buildings above them. I admit that you probably drew that it before Ocean Pride was built, but now as it's up and running leaving such a thing in the middle made the map very hard to read.
3. The presence of the platform made other mappers put up bus line relations arbitrarily, and the platform became a horrid rectangle with line numbers on them in Transport view. In reality they all have their own stopping positions (and quite some of them like 31 and 36 had been so for most of their tenures in the complex), and all queue structures are not labelled. It's far more accurate to put the stops up as I did.

I have been wanting to get rid of the platform for quite some time, but after I found out it's you who made it, I KNEW you would complain if I simply do it without some backing, so I actually went to the place and did a survey myself to ensure my initiative is justified.

About the source, I only looked up HKBUS for the KMB reference numbers; every other bit was from my own outing and records, so I admit that I should just have stuck to "self-survey".

Re 1.
I also try my best to keep history of paths, but nodes are much more difficult to do so and frankly it's part of the reason why so many paths are unnecessarily zig-zaggy.

Re 2 - 3.
Yes I can relate what you mean to, say, A86 in Paris, which is a motorway but only cars can use. However, Wing Tak Street is not like this. Also, Wing Tak Street is not the only way to access the Pavilla Bay and Tsuen Wan Sports Centre. Cars coming from the north probably find it faster / more convenient to use Yi Lok Street and Yi Hong Street to "turn around", because Texaco Road cannot right turn into Wing Tak Street.

That said, I have read osm.wiki/Hong_Kong/Transport/Road and it seems that "unclassified" was reserved for bad roads, which I don't know why and don't agree (Probably you don't too). But in any case, maybe let's just keep all of Wing Shun Street and Wing Tak Street as tertiary as a compromise.

Re 4.
The part of Tsuen Wan Road over Wing Tak Street has already started to fork, which means there're two gaps through which sunlight can enter. Therefore it is hard to define which part of the street underneath is actually covered.

Both "covered=yes" and "tunnel=yes" are rendered the same. It's easy to distinguish the two though. As example, Wing Shun Street under Tsing Tsuen Road is a tunnel; while Kwai Chung Road under Tsing Kwai Highway is covered.

IMHO the Tsuen Wan Road over Wing Tak Street seems too open to make the road under it qualify as covered. Also, previously the covered path extended well beyond the actually covered part.

"Wing Tak St is the main access from Tsuen Tsing Interchange." >> No it is not. It has a restriction of length which means buses and HGVs are not legally allowed to use it.

"Actually you should not use standard as the criteria for classification. Function in the road hierarchy is used."
>> I don't understand this sentence at all. Also, I am aware of the road hierarchy

JOSM is not always the best tool to use. Using browser is often more convenient as they displays points and paths better IMHO.

In any case using housename as the estate part sounds very wrong to me. You can proceed to change the tags if you like, but I refuse to comply myself and can only accept not to add anything under addr tags. Sorry.

addr tags certainly needs to be improved then. Actually most of the time we simply cannot fill in anything in the default UI.

In Hong Kong most (public) housing estates have the word "邨", which indeed is an alternative form of "村", meaning "village".

I cannot find any documentation which support your rationale. Can you give a link to support your case?

Replaced with something else. The signs there asked cyclists to dismount so re-pathed to reflect the regulations there. The resulting short stretches is the ridiculousness on the part of the related authorities but if the structures are like that so be it.

Awww you again.

I'll take a look at the description documents and see how they are done.

For the "addr:place", again, I changed tag because it seemed more appropriate than the previous one ("addr:housename"), which itself means individual houses. There are buildings in, say, Mong Kok which would fit "addr:housename", but I don't think buildings of a housing estate, some of them separated by named streets, qualify.

As a matter of fact, the foliage does not span across the road.

https://www.google.com/maps/@22.3549622,114.1038481,3a,75y,309.59h,91.31t/data=!3m7!1e1!3m5!1sHaiseeOft6ADoeh6gV8p4w!2e0!6shttps:%2F%2Fstreetviewpixels-pa.googleapis.com%2Fv1%2Fthumbnail%3Fpanoid%3DHaiseeOft6ADoeh6gV8p4w%26cb_client%3Dmaps_sv.tactile.gps%26w%3D203%26h%3D100%26yaw%3D315.20917%26pitch%3D0%26thumbfov%3D100!7i16384!8i8192

There are too many things to fix and it is take me a day or two. I do aim to add tree areas back where they should afterwards, but I can't stand seeing those polygons going across roads and paths for no good reason.

Also, most of them are not natural wood areas -- they are artificially placed alongside paths or roads in a very orderly manner. I do think tree rows are more accurate description of them than , at least for the roadside areas.

My upcoming change will conditionally preserve wood areas, but my interpretation of the area is that they are not actual woodlands and should be changed to something else wherever applicable.

Sorry I did not notice I did that kind of change. This change was mostly about setting up the bus route. Can you please point specifically to where your concern is about?

Frankly the reversal action by you is very rude.

It's the Openstreetmap team who are wrong by refusing to render shrubberies. Please join me and many other contributors at the discussion at https://github.com/gravitystorm/openstreetmap-carto/issues/4473

The tree areas are not presented correctly and make the place messy. I am using the tag "shrubbery" as well as things like tree lines and hedges to make them look more accurate.

I don't think they are presented correctly.