Well, for example, a careful observer can also see bridge joints at Tai Chung Road, Tsuen Wan. Then, should Tai Chung Road also be retagged as bridge=yes?

Hi

Re place=neighbourhood Tai Yuk Road (osm.org/node/12744462800), can you confirm whether one of the following:
- This is real (the neighbourhood name is unusual but is real)
- This is a mistake (see Yuen Long actual Tai Yuk Road)
- This is an inaccuracy (eg nearby Solar Villas probably has "Tai Yuk Road" as a street name)

Thanks!

Hi there, please see note osm.org/note/4705824

See osm.org/note/4681270

Hi there, since the note says "permanent closure", does it make sense to slap on "access=no" for the affected roads?

Hi there, may you provide more information about this "Tai Teng"? I can't seem to find any online info about it, and it sounds generic.

The validator has been told to shut up via osm.org/changeset/163674665 .

Someone should probably go there irl to confirm things, I can see this part of the map is very messy in terms of the footpath shapes. Mainly my concern is about the "paths" that goes into the buildings; might actually be access=private due to being inside the lobby of the building (not for through foot traffic), and then it might not be 100% suitable to include them on OSM.

I may have indirectly caused these issue(s); these are cleaned up via osm.org/changeset/163674517 .

To philosophically add to Kovoschiz's point, if the warning system could automatically fix warnings (i.e. blindly accepting the fix proposals) and the fixes were correct, then we all would not even need to be here.

We OSM mappers are needed because warning systems don't know what's actually happening irl. It is only us that can like go there and have a look. Warning systems at most are assistants that point out problems, not executives that actually knows what's up.

If you are trying to handle "feature intersect with feature" warnings, then perhaps there's another way of doing it.

Hi there, it seems this changeset has modified the section of Tung Chung Line near Nam Cheong. Why is "bridge=yes" added when the tracks are built on the ground?

Note that "covered:by=bridge" is descriptive mapping and I support it. But just don't add "covered=yes" just because the driver cannot see the overhead sun.

If following consequential mapping principles, then multi-stacked highway interchanges will have many useless "covered=yes" segments that does nothing but to indicate "the driver cannot see the overhead sun here", which is useless and nonsensical. Like, you can just analyze the map and then realize, some other bridge is crossing over the road but at a higher layer, and so this segment very likely cannot see the overhead sun. It should be like that. Empower the tools.

Also another angle:

See note osm.org/note/4588210 for another very likely case of "consequential mapping".

Another angle:

Some turn restrictions on OSM are actually wrong, with same principle: they are consequential. Some irl turn restriction signs are a reminder that, due to the destination road having special restrictions (e.g. wholly bus lane), it is as if there was actually a turn restriction that prohibits e.g. turning left. This is "consequential", and should not result in a creation of a turn restriction relation; instead, map the destination path as "with special restrictions" and let the routers figure out the rest.

To clarify, what I mean by "consequential" is that, the cover doesn't actually belong to the road. In this case, the cover is "caused" by another road going over it, so the underside road should never get "covered=yes".

I generally do not see "bridge parts" as useful data. That belongs to the topic "micro mapping" and it makes future "minor" edits more difficult to manage because suddenly I would be touching 10 other items that I never intended to touch.

"covered=yes" is reasonable in the following cases:
- full-cover sound barriers
- slope protection covers
- building "covers" that are pre-planned (!!!) such as Kwai Hing BT under a cover, upon which New Kwai Hing Gardens is built
- and perhaps more

Resolved via osm.org/changeset/161194537

My apologies. It was a careless mistake while figuring out why the crossing was "partially tagged".

To add onto {2}, usually when there is a "plot merger" such as in this case, the addr:house_number will remain null and unknown until the construction is "almost finished (TM)" and the relevant whatever gov-dept announces "thy number is XXX", and then we will write that into the data. Right now since there is not even a foundation laid irl, there is nothing for us mappers to do.

Re

{1}
The government doesn't understand what is a permalink, but see this FB post: https://www.facebook.com/gakeicom/posts/2936533403285783/?locale=zh_HK
The new layout (while lacking details) can be seen as significantly different from any of the old/interim layouts. This warrants a cleanup since those old paths are no longer there irl. It seems likely the new terminus will be a sawtooth one (as per planning preference), but whatever, by the time it needs to happen, someone will draw them.

{2}
I can add back the 485-487 number, but I really don't think the new building(s) will have exactly 485-487 (think: the old bus terminus is probably 483, right?)

{3}
While OSM aims to capture "the essence", at least I think OSM should also capture "the form", especially when it comes to multi-phase constructions. You notice I actually drew 2 construction yards; presumably, you can move them around to suit the updated irl situation, such that one of them will be for the High Block, another for the Low Block. People will be confused when the map says they have to enter a construction yard when in fact the yard is separated by a road. Again, it do be like that irl, and all maps should at minimum capture the irl factor to be called a proper map.