Apologies if these questions have already been answered, but I didn’t find anything substantial with a search.
How should closed businesses be dealt with - specifically, where the building still stands, but is currently unoccupied? Certain commercial mapping apps have a ‘permanently closed’ tag, but there doesn’t seem to be an equivalent in OSM.
OpenStreetMap Somewhere like this, we have both buildings and points. To my mind, the points should be deleted, and any useful information they contain should be integrated into the building. Am I right?
If it’s a retail thing with the branding still up you can change it to shop=vacant. If it isn’t a shopfront but the building still looks like a disused xyz then you can use the disused:lifecycle prefix to indicate that you will see an obviously disused thing if you go there.
If all traces are gone then the business related tags can be deleted. If there are any generic tags relating to the building (e.g. address tags) then those can either be left on the node or transferred to the relevant building (if it’s split up correctly). If the node is left with no tags or referrers it should be deleted.
Not necessarily, no. It’s quite common to have the actual building details (address, number of levels, possible building name etc) on the building outline, & also a / several node/s inside the building for the businesses that are there.
In case of a multiple-storey building that has a shop on the ground floor and flats above, it seems somewhat incorrect to have shop tags on the building as the shop isn’t taking up the entire building
In case of multiple-storey building with shops on several floors (e.g. shop on ground floor, nail shop above or below e.g. Node: The Final Nail (4866289424) | OpenStreetMap) we have to use at least one separate node anyway
Thank you all for the advice. I certainly hadn’t considered Jarek’s example #1, despite living next door to one, and I now have about 10 tabs of OSM Wiki to study!
I just ran into a variant of issue #1 as another OSM newbie: A restaurant closed, and a cafe expanded into its place. If you search for the restaurant in Google Maps, it knows where you mean, informs you the business has permanently closed, and you can see the cafe is there. In my OSM-based map apps, they both show up right now as though they are both open, and the only alternative appears to be to delete the restaurant. Neither of those is a good UX.
Yes, I know. That doesn’t really address the issue. Basically, these are the user flows I am trying to understand how OSM addresses:
On Google via map search:
Person searches for Dumpling Daughter Cambridge.
Map shows its former location and identifies it as permanently closed. Vester is the only business shown in 73 Ames Street.
On Google via map exploration:
Person moves the map to 73 Ames Street.
Dumpling Daughter doesn’t appear; Vester is the only business shown in 73 Ames Street.
Person may then search for Dumpling Daughter as above and discover why it isn’t shown.
On an OSM-based app via map search earlier today:
Person searches Dumpling Daughter Cambridge.
Map shows its former location as though it were still there. (Incorrect)
On an OSM-based app via map search now:
Person searches Dumpling Daughter Cambridge.
Map brings up nothing. (Technically accurate, but comes off as a failure of OSM.)
On an OSM-based app via map exploration earlier today:
Person moves the map to 73 Ames Street.
Vester and Dumpling Daughter both appear at 73 Ames Street. (Incorrect)
On an OSM-based app via map exploration now:
Person moves the map to 73 Ames Street.
Vester and a vacant shop both appear at 73 Ames Street. (Incorrect)
No OSM experience is helpful to the person searching.
Nonexistent features - OpenStreetMap Wiki says if Vester simply replaced Dumpling Daughter, 73 Ames Street should be updated, and Dumpling Daughter would remain in its edit history, but I am not sure how to handle a situation like this where the existing adjacent business expanded into the space?
OSM is just the database. Changes are “online” as soon as the editor closes the changeset (normally by uploading his changes). The demo-map on OSM.org reflect changes within minutes (there a exceptions, e.g. coast lines). When / How frequent other applications and services update their data depends on the developer / maintainer.
In this specific case I’d delete the vacant shop and move the restaurant to it’s new location.
I see, so OSM’s UX for recently closed businesses is delete them from the map the moment they move out, and have people figure out elsewhere why a place they are searching for doesn’t come up? There isn’t a status for a “permanently closed” business someone might realistically still search for like OP mentioned?
It depends. It might make sense to do that (if business X has closed and business Y has opened in its place, and there’s no indication that business X is now somewhere else). Alternatively, sometimes places close but signage or some other indicator remains. As an example, here is a pub that has closed under one name and hasn’t reopened as any other sort of place yet. That’s an example of a lifecycle tag, as mentioned earlier.
Maps (and search engines) may choose to omit it, or show it and say “this was something, but it isn’t that any more”. It is entirely up to them. There is no “OSM UX” - you can use OSM’s data to create any user experience you like. As also noted earlier, OSM is just a big pile of data.
That rare case is a case where we do tend do delete the business that has disappeared: generally, disused: for a shop means permanently closed, but it wouldn’t be accurate to say there’s a disused former dumpling shop next to the café, when the café has taken over the unit and expanded into it, and the dumpling shop has disappeared completely.
@ZMYaro you can think of an OSM node inside a building as representing the retail unit. In the more common case where one business replaces another it might go from shop=hairdresser to disused:shop=hairdresser to amenity=cafe. And yes, that means that from then on it would no longer be possible to find the hairdresser in an OSM-based app.
If an app developer really wanted to implement that feature, then I suppose they’d have to look at the object history, but I’m not aware of any that do.
(Sometimes mappers move the name of the former occupant from name into old_name. In that case it would still be possible to find it. I only do this when the business rebrands e.g. when one hairdresser replaces another. Not when a hairdresser is replaced by a café.)
you could use lifecycle tags, but should probably make a distinct object then to avoid confusion (i.e. each would get address tags, one would be amenity=cafe name=* … the other something like was:amenity=restaurant name=* etc.
yes, old_name refers to the same feature with a different (former) name, so IMHO it would not apply here because the restaurant name is not the old name of the cafe.