Consider operational_status = out_of_order as deprecated?

I propose to consider operational_status=out_of_order as deprecated and recommend using lifecycle prefix such as disused:, abandoned: or construction:

It is not a good idea to use one tag (for example tourism=hotel) and add second tag that negates or massively change its meaning (for example mapping prison using tourism=hotel involuntary=yes instead of using amenity=prison). Additional tags should clarify meaning of main tags rather than negate it.

It is a trap for data consumers not supporting them and there could be an endless array of them.

Data consumer in that situation should not be expected to check for proposed=yes, demolished=yes, construction=yes, completely_fictional=yes, operational_status=out_of_order or end_date=1990

I propose to consider operational_status=out_of_order as deprecated


Note: I created Tag:operational_status=out_of_order - OpenStreetMap Wiki complaining about this tag, with recommendation to not use it and with unfilled status in infobox.

I created this thread to validate this edit and confirm that it is fine to add “deprecated” as tag status.

This sounds completely different to disused, abandoned or construction. Which lifecycle prefix do you think should replace it and why?

Why disused: would not fit? That is what I use for drinking fountains that are not working and out of order.

(many were disabled during COVID, despite that it was no real transmission via surfaces)

“disused” implies “was a thing, but is not functional as a thing any more”

“out_of_order” implies “very much still intended to be in use, but temporarily unable to be used because of (some reason)”.

Except in the case of exact duplicates, it isn’t necessary to dumb down OSM data for data consumers (and I speak as a data consumer here).

1 Like

That seems more abandoned: ? Was used, now it is not and will take noticeable effort to reactivate it.

While in my mapping disused: was applied for thing which are well, not used right now and may easily come back.

With very temporary and short term “out of order” not being mapped.

A simple example is an escalator or an elevator. It might be out of order for a few days or even a few months at the extreme. But the feature still exists unless it becomes permanently closed. In the example of a water fountain, it might be turned off in the winter time, but it is not really out of order, it’s just not being used, but it will likely still continue to exist and be turned on later in the spring or summer.

that is seasonal=yes rather than things mentioned so far

Mapping things that are “temporary” out of order or not accessible is always tricky in OSM context.

I once planned a cycle route and following it I found that part of it was not accessible were not accessible because the dykes were fortified. That process took/takes multiple years so access=no?

The thing is once you map it I forget to update it after the work is done although I did set a tracker on the website of the project. In my experience these kind of problems are also not found anytime soon by others.

So for this project I did change the access=no to access:conditional=no @ (period). The good thing on that is that once the period is over:

  • Anybody interpreting access:conditional correct will see it is not valid anymore
  • It is flagged by sites like Osmose

Back to operational_status=out_of_order: exactly because I am quite sure way too many people will forgot removing it once operational so I agree it should be deprecated.

Unless there is some good mechanism to make sure the status is updated once operational again, do not map these kind of temporary things.

One thought is that while a disused shop shouldn’t be marked as a shop, having an out-of-use public toilet/fountain marked on a map isn’t the end of the world.

In addition, if an app tries to route you though a closed path it wouldn’t be ideal, but the user can ignore the path themselves as if a tree had blocked it this morning or if it had flooded.

For this tag to work effectively, a check_date or a note would be important to stop the tag going stale/unchecked.

Yes, and that is why I would mark such features as disused: (if mark that at all)

Is “disused” having also meaning “it is not going to be repaired” in English that I missed as I am not an native speaker?

It is definitely obnoxious to plan a route across city or while hiking as a tourist and discover that supposed source of drinking water is gone, even marked as gone in OSM - just in one more weird and unexpected way

Yes that is correct. For example since it is common for a river to destroy a road. The road is disused, it no longer possible for anyone to use it. In the immediate aftermath it is disused and “out_of_order”. But at some point there will be a decision whether or not to repair the road. There might continue to be some trace of the road remaining, for a short period of time. But in this specific case (North Fork Skykomish River), there are no plans to repair the road where the river destroyed it. It will be re-routed around the washout. In addition they also chose to remove the asphalt. In another few years the river will flood again and it will be difficult to tell there was ever a road there.


1 Like


  • object unavailable for use with no decision what will happen with it can be called “disused”
  • object unavailable for use with repair plans is not “disused” (can it be called “inactive”?)
  • object unavailable for use with decision to not repair it is “disused”

Similarly, shop waiting for opening can be inactive:shop=supermarket but not disused:shop=supermarket - right?

Or is there better name for such state?

1 Like

Yes the inactive supermarket is not disused. There is a reasonable expectation it will re-open.

For my example of a washed out river, the wiki suggests using the abandoned prefix, based on the test of how quickly “significant repairs” can be made. Something disused is often also abandoned, but sometimes it is not always easy to tell in the immediate aftermath once something becomes “disused” if it will then become abandoned. In this case it is now razed. So disused is more general.

As someone who is somewhat new to OSM, I have always understood one of the main purposes of using the disused prefix is as a way to signal to other mappers that a feature is not in present use, even though from a quick glance it might appear otherwise.

I wouldn’t overthink it.

Let people tag stuff according to what makes sense to them; and if it’s an obvious duplicate a quick “did you mean X” changeset discussion should sort it out.

At the risk of pulling “tagging astronauts” down to earth, suggests no usage currently.

I know. Partially because I tagged this kind of thing as disused: so far (and partially because almost all qualified for disused anyway)

And I invented it 40 minutes ago and posted here as I want to check is it also suffering from Engrish issues.

operational_status=out_of_order is (fortunately) used quite rarely, badly designed and I think that it would be better to replace with something better working than trying to get every single data consumer to start supporting this silliness.

At least for me it makes as much sense as tagging tourism=hotel involuntary=yes instead of using amenity=prison and expecting people to support this.

disused is for features that are not currently in use, but could still be in working condition, e.g. I use it for turned off drinking fountains, while those that by the looks couldn’t work without repair (and look as if they are like this for some time already) the abandoned status. Admittedly there is a gap for things that are currently broken but expected to be repaired soon. I also tend to tag them as disused, but loose the info that they are actually broken

1 Like