Would never have guessed it. Placing features at dense urban area without an "anchoring" housenumber is just asking for "can't find this" deletion.

If keeping the polygons, then at least the bus stop polygons should be smaller than the construction area polygons. Will make improvements.

It seems, in general, intersections need not be quadrilaterals (e.g. this intersection here). Most are quadrilaterals (or more complex), but that's not a given.

So far the aforementioned right turn is still legible and is still somewhat representative of irl.

I see/guess the objective is indicating the reclamation protection area. Placing the harbour to be equivalent to other natural reserve areas in the world is imo unexpected, but I guess this is still technically correct per the "protected area" definition.

Hi there with the mega changeset; specific concern at note note/5416561

Thing is, it's still in the same building. The same mall extends westwards to the other side. Entrances cannot possibly exist.

The line blurs when we think about HK style commercial 24/7 walkways that "implements" a bridge.

Based on https://www.td.gov.hk/tc/traffic_notices/index_id_83845.html ; unless we have newer situations that I am not aware of.

OSM data previously claimed to have a staircase that connects with the bridge area. I could not identify any staircase at the bridge area that satisfies this property.

I basically tried to find by "buffer:*=*", which essentially returned nothing. It seems there is currently no effective way to document these "attached" tags.

This I know, but we still know what's up when looking at the website field.

I can't effectively respond to your texts. Ultimately, all those fancy "buffer:*=*" tags, I don't even know where they are documented, just that I can see you can systematically print them out. I am supposed to read their docs first *before* doing this changeset, but it seems there are no docs to be read.

Still, separation:* is already kept even as I draw the area as two separate ways. The road_marking schema is clear and interesting, so perhaps the wiki page should be improved; or perhaps I should just re-read them and learn them better.

Disappointing, but the idea was that "number 80" at least should not be here.

It is OK to persist the shop space, but this cannot possibly mean we can affirm the relationship between this suspiciously-placed bakery and subsequent legitimate users of "number 80".

Though perhaps the topic of shop space itself can be further discussed at Discord.

Admittedly, it is surprisingly difficult to correctly determine the actual project name. Different sources seem to have different names.

Somewhat experimental. By avoiding ultra-short road segments, we assist/improve vector rendering e.g. by having enough space for street labels and oneway arrows. This has the nice side effect of simplifying the road tags and associated restrictions relations.

The road_marking schema should be equivalent to the poorly documented / highly-fragmented "buffer:*=*" etc tagging. (What are these even called?)

This style may be preferred when the "shared space" area is small/short, as compared to the existing "strictly respect separation" convention. In particular, this style may assist in enhancing path accuracy when dealing with large-and-long chevron areas, which would have previously forced some road paths to diverge too much from irl coordinates, which may then affect map matching usages.

Actually, now that I think about it, maybe Broadcast Dr should also be highway=unclassified . Tertiary roads should ideally still fulfill the "bring you to somewhere" requirement, but Broadcast Dr being a neighbourhood access road just doesn't bring you anywhere new. We did allow highway=tertiary for those L/R turn alternatives between higher-tier roads.

Here I count neighourhoods as areas, but not specific roads.

Fundamentally there should be no problems even if a secondary road connect directly with unclassified/service roads. Example is Kowloon Tong Kent Road, etc.

The thought was that, Broadcast Dr is largely oneway circular street that covers a large (physical area) neighbourhood, which justifies tertiary status. Here is only a mostly-linear dead-end street, and the ending part is not even one-way. Imagine a no-branch street that leads into multiple residential buildings (entrance into Waterloo Road not too relevant). This would be highway=unclassified.

Re 1, I am inclined to believe that, due to traffic light phases, we have the following:

- from Shum Wan, it might be faster for vehicles to reach Route 1 first, and then turn back to OP
- from OP, if needing to reach Aberdeen and beyond, just turn straight to Route 1 westbound, which simply has no traffic lights, compared to Heung Yip Road having 2 (chained?) lights

Vehicles can still take Heung Yip Road for being the shortest-distance path, but generally speaking Route 1 should be much better than Heung Yip Road, unless HYR is a strict requirement (e.g. Nam Long Shan Road ordinarily cannot turn left to Route 1).

Or maybe these are on wrong premises, idk; eg what about the ordinarily-green traffic light outside Graham Hospital, is it somehow chained (or not) with HYR, this I do not know.

It is unclear whether it should be "unit" or "door" (as always). However, in most cases, since the shop(s) should be easily observed from the streets anyway, there should not be too much issue even if the shop number is placed inside the notes field. Regular users can still physically find the shops, and OSM mappers still know what's up when the specs are finally clear.

Hi there, I noticed this changeset added details to the rural village, but e.g. way/1491526318 does not have a house number. Perhaps the changeset is incomplete?

But other than that, it should be OK for unclassified roads to join together to form a (wide) network of unclassified roads for local areas. It just so happens that, very often in HK, the roads are planned such that some unclassified roads are "forced" to become tertiary despite visually looking similar to nearby streets (e.g. Yu Chau Street at SSP).