Proposal talk:Tag:operational status

But, there's more

Life cycles have quite a few more stages than are yet codified in OSM tags. For example:

• Citizen concept (no landowner/government involvement yet)
• Proposed
• Planned
• Under construction
• Operating
• Broken (but expected to be fixed)
• Disused (not expected to be fixed). Shades of this include abandoned, vacant, empty.
• Preserved (e.g. a stabilized ruin).
• Converted (e.g. historic:railway=funicular).
• Proposed for removal.
• Under demolition.
• Historic.
• Rebuilt.

Brycenesbitt (talk)

Agree to move forward - with other usage

I agree with Bryce that operational_status is a useful key. I would suggest it also applies to various public services besides toilets and such, and should be used in conjunction with the emergency=* key; i.e. fire_extinguishers, emergency_phones, and especailly aed's as these have a battery life.

russdeffner

"(inserted automatically)"

• operational_status:date=2013-11-01 (inserted automatically)

What by? Please specify, and acknowledge that normal mapping software will not do this. --achadwick (talk) 14:30, 5 July 2013 (UTC)

Shares the same problems as the old styles of using disused/abandoned

Strongly disagree with this article in its current state. It suffers from the same issues as disused=* and abandoned=* prior to their rehabilitation. The example is a case in point: if a public toilet is closed, then it should not be tagged with amenity=toilet, though it could still be tagged as a building. Sure, your rendering may do something special with {operational_status=closed, amenity=toilet}, but no-one else's will, and that will be misleading and inconvenient. For emergency facilities it may even be dangerous. Formalizing this tag in this way encourages other mappers to enter bad data too, so the article really needs fixing.

Please find a different way of expressing this concept that doesn't result in new tags contradicting old ones. Don't get me wrong: if it's helpful to people to use the OSM db for identifying broken water pumps or other specific kinds of facilities, that's a really cool use of OpenStreetMap. But it shouldn't be done at the expense of correct data for all users.

For what it's worth, a standardized namespace prefix to be used when an item is inoperable or defunct is possibly the least worst approach. May I suggest recommending inoperable:<oldname>=<value>, as a nod to the name of the proposed tag? For use only when the object cannot be operated / does not provide basic functionality, of course

--achadwick (talk) 16:56, 5 July 2013 (UTC)

The use of inoperable:<oldname>=<value> hides it from most maps and processing software, which is really undesirable for facilities that are likely to be repaired. The goal here is for objects to retain their database identities as whatever they are, but add a (possibly useful) observational note. (e.g. 'it is still a hospital, but the windows were blown out by the storm'). Brycenesbitt (talk)

If it needs fixing so bad that it can't be used as a hospital, it's not a hospital, until it's fixed. If it needs fixing, but still operates as a hospital, it is a hospital. Duck tagging and all that. It's easier for specialists (so-to-say) interested in finding facilities needing a fix to check other values, than for everybody to check a myriad of tags (like inoperable=yes, broken=yes, disused=yes etc.), or an unconstrained set of values of operational_status. Alv (talk) 08:08, 22 July 2013 (UTC)

I second that. There are certain basic assumptions about the availability of a mapped feature. For example, an amenity=restaurant might not be open every day of the week, so people can be expected to check the opening times before going there. The restaurant is still a restaurant on Mondays even if it is closed on Mondays, because it is usual that restaurants may not be open every day. If, however, the restaurant is burnt out and awaiting reconstruction, then it is outside the usual envelope for a restaurant and should not be mapped as such. What the usual envelope is, probably depends on the region and type of feature. For example, some holiday destinations might have hotels that are only open for a few months every year and they would still be mapped as hotels. Something in the middle of Paris that is only open a few months a year would likely not conform to what is usual for a hotel and not be mapped as such. The issue becomes much more serious with something like a hospital where (at least where I live) the usual expectation is that they will be open and staffed and able to respond to an emergency 24/7. Drawing a hospital on a map when it is burnt out and awaiting renovation can cost lives. Therefore I do not only disapprove of "operational_status=something that means it is closed", I disapprove of the whole notion expressed by Bryce Nesbitt above ("... hid[ing] it from most maps and processing software, which is really undesirable") - I think it is not only desirable, but mandatory to hide such things until they are repaired. If you do need to add extra tags, you must err on the side of caution, i.e.: put "inoperable:amenity=hospital" and then "operational_status=will reopen on DATE". That way, software that does *not* know about operational_status will do the right thing (not show the hospital), and software that knows about operational status can show the thing as a hospital with a special marker or whatever. --Woodpeck (talk) 19:31, 20 June 2019 (UTC)

Note, Date, Source, unspecified status

I see several things that might lead to confusion:

• note vs description, note is used to notify other contributors of some mistakes/or immprovement in the OSM database, description seems better for this case to add info on the element. So, I would go to description
• date: you could use survey:date (500000 use)which is more explicit, else what date is for here? source:date then?
• source: why adding a source as a tag when you can add it inside the changeset? (for me there is a risk that source tag is not updated when people update tags, and so get wrong after a while)
• unspecified : is it useful to have an unspecified type here? It's filling the database and servers..--Violaine Do (talk) 23:14, 19 June 2019 (UTC)

Consider operational_status = out_of_order as deprecated?

https://community.openstreetmap.org/t/consider-operational-status-out-of-order-as-deprecated/2687 is proposing deprecation of value not proposed here but arguments used there apply also to operational_status=closed and other tags negating object existence Mateusz Konieczny (talk) 15:58, 16 September 2022 (UTC)