OpenStreetMap logo OpenStreetMap

Changeset When Comment
165924537 3 months ago

I want to point out that Sha Lek Highway is designated as an expressway, while Airport Road is not.

If the standards require that only numbered expressways get "=motorroad", then I do not understand why this section of Airport Road should also get "=motorroad". I see no problem demoting the highway down to "=primary" the instant it is no longer a numbered highway.

For example, Route 7 (TKO side) instantly demotes to "=secondary" right as it ends.

165754694 3 months ago

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?

164951098 3 months ago

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!

164612310 4 months ago

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

164576142 4 months ago

See osm.org/note/4681270

164576142 4 months ago

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

147057250 4 months ago

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.

163640651 5 months ago

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

163642017 5 months ago

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.

163641198 5 months ago

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

161402025 7 months ago

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.

161402025 7 months ago

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

161402025 7 months ago

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?

161347413 7 months ago

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.

161347413 7 months ago

Also another angle:

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

161347413 7 months ago

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.

161347413 7 months ago

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

161191247 7 months ago

Resolved via osm.org/changeset/161194537

161191247 7 months ago

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

160901136 7 months ago

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.