It kinda feel like Phase 2 was an afterthought when planning the buildings, so I am really not sure how to approach this. Kinda like "oh we need something extra, then here are some proper shopping malls", and name those Phase 2.

My guess to mapping these, is to create a relation of areas and give that relation shop=mall, but not sure how it would appear on the map.

Let's not get started on eg why Island Line HKU station, the tracks and the station area is not consistent.

Tbh, at some point I was also thinking maybe I should avoid calibrating elevated portions of roads, due to the inherent "transformation" that may or may not exist for satellite imageries.

But then the unexplained space between HKU Main Building and Pok Fu Lam Road is too obvious. And the old shape seems inconsistent with the sidewalk shapes.

As long as it is still mostly accurate, then it should be ok. No point in pursuing 100% accuracy: even satellite coordinates might shift slightly every once in a while, and then we will all be building houses on sands. When it looks nice (ie shape form, relative positioning, etc), and is mostly accurate, then it is a good map.

The problem is, Phase 1 is just 2 small buildings, and Phase 2 is 2 large buildings. It seems you mean that we should have exactly 1 shop=mall for the entire Yan On Shopping Centre? The problem is, with that approach, we may lose information about which part is "phase 1".

To whom it may concern:

This changeset was later rolled back after discussion with international OSM mappers on the forum.

Thanks!

Notice how everyone responded until a month later, with me mistakenly believing another changeset was to blame.

Not sure about the osmcha tool, but I am someone who uses OSM/osmcarto more often than the average user.

And then one day I saw a sus path shape near Chung On Estate.

Note: found the correct changeset to blame here: changeset/144435963

Hi there, this changeset has caused a path mapping blunder near Chung On Estate; please double check that your changes do not have unintended side effects next time.

Fixed via changeset/145503514

Update: I eventually found the correct problematic changeset: changeset/144435963

My knowledge is that moving a node will mark the way as changed, so I was looking at this changeset. It turns out the offending node is actually in the above linked changeset instead.

Apologies for the wrong accusation!

tbf now I am also secondguessing what really happened

I should really look again who did it, seeing that your changeset really did not contain the affected segments

ref changeset/145539177

hmmm... either I was wrong, or the physical signs there were wrong.

will double check later.

(specifically, Sai Sha Road)

The paths near Chung On Estate looks like a mapping blunder. Please double check that your changeset do not have side effects next time.

My bad. Reverting.

In theory, indeed, this is how we should do things, to preserve the shop point for the next tenant, etc.

In practice, due to the extreme incompleteness of data (eg all the shop points in the building), I think there really is no effective difference if I deleted the point instead of converting to a "blank" point.

The wiki currently suggests simply "building=yes" with "telecom=data_center". (I would prefer to have something like "building=telecom", but that would be for another time.)

I personally believe OSM items should be self-explanatory, so that, eg, it is reasonably easy to locate "data center buildings" via Overpass Turbo. If we go for "avoid duplicated tags" then it would be difficult to locate buildings inside data center land uses (search "telecom=data_center" -> for each area find buildings within polygon -> for each building reject if is non-generic building).

imo at least there should be an easy distinction between "civilian private" and "military private"/"off limits"

there is no mention of "private=military" on the other side either; another possible followup vector

ref private=*

well tbf at least the wiki mentioned the existence of access=military; if you want a proper followup, might as well check there

ref access=*#List_of_possible_values