Formally tagging "shop spaces" / "building spaces"

Previous discussion e.g. "Disused shop" or "vacant shop"?

While going through the replies, I remembered something.

I previously asked “what if the shop is unused/vacant”. The discussion continued on “shops can change to other shop types, but is still largely a shop”.

I then remembered that, in extreme cases, a disused shop can suddenly become amenity=*, e.g. being converted into an elderly home, or just become a clinic, which would then become either amenity=clinic or healthcare=clinic.

By following the “keep the history” principle, these changes should be retained onto the same node/way. For example, all these changes all occur in the same “shop space”, so the node/way would implicitly represent such “shop space”.

Then, do we need to somehow explicitly establish a new tag to designate a “shop space”? I imagine that if we have e.g. shop_space=yes without any other information, then we can use that to indicate a vacant shop. This would be an alternative to e.g. vacant:shop=yes, which imo feels clumsy.

Conceptually, this “shop space” is similar to a building=* . No matter what happens (unless demolished), a building remains a building, even if it is currently unused. As buildings get internally partitioned into various “shop spaces” for lease (unless re-partitioned), these spaces remain such spaces, even if they are currently unused. Tags like disused:shop=* can then further clarify the situation of specific shop spaces, and we can unify shop=*, amenity=*, education=*, and healthcare=* (and future tags) under the same “parent” tag, if you may.

How does the community feel about this?

Note that it is merely nice to have, not mandatory.

And often (when shop merges/splits) hard to follow.

2 Likes

Yeah understandable. In Hong Kong sometimes the mall owner decides to re-partition the shop spaces, and then it’s essentially impossible to maintain these shop space lineages.

But the idea is that, if shop spaces are not re-partitioned, should we enable a way to formally track these e.g. shop to healthcare transitions? Currently the entire feature changes type, but in theory these are still different usages of the same “shop space”.

I don’t even know how to properly call/identify this “shop space” concept.

The fact that “the entire feature changes type” appears to already track the transition. And if a life cycle tag is used in between, the tracking is more granular. I’m not sure what information is missing in this situation?

Would it be an idea to tag the shop space as indoor=room + room=shop? The last tag is discouraged here, but if we give it the meaning of “a space built as a shop” (similar to how we tag buildings for what they were built for, not how they are presently used), why not? What the space is then actually used for can be described by adding a shop=*, amenity=*, etc. tag.

2 Likes

exactly, it is not even clear which history should be preserved, imagine a shop moving to a different location, should the node be moved and the address be updated, or should the node (or way) be kept and changed to represent the new shop that is now at this location?

1 Like

Most of the discouraged list are misunderstandings. They can have both room= + shop= / amenity=

In British English, we’d probably refer to the spaces occupied by shops “retail units”

indoor=room is really only supposed to be used as an area and if you know the exact geometry. Tagging it on a node isn’t really a proper use of the tag in my opinion.

If you know the area that a shop occupies in a building and it’s a single room, then I guess you could do some indoor mapping and map it as a room with the shop tag on the same object. That’s definitely not a solution that’s useful for the general case though.
It’s pretty hard to accurately map the floorplan of a building without referencing any plans, which isn’t really going to be possible for most shops and it’s also pretty tedious. Shops also very often have more than one room.

1 Like

That’s true, but if we want to change that, we can. There are precedents: car parks, playgrounds, etc. are really areas and should eventually be mapped as areas, but are now frequently mapped as nodes.

1 Like

there is organic growth of rooms mapped as nodes for the last 11 years, up to 7500 now:

Clearly an area is preferable (as for any Poi with some extension), but if you absolutely can’t guess an outline there may still be reasons to map at least a node (e.g. rooms with names, or numbers). When you want to put things in a room, an area makes things easier.

1mn =building , and 100k landuse= are points. Not the best, but do exist.
Store spaces being multiple =room is more critical. That rejects it.
Some shops don’t occupy an entire =room either, only part of it. Some are counters, booths, or kiosks on =corridor side.