Id: Display status/lifecycle tagging separate from preset

[quincylvania]

Lots of issues have come up around adding presets for features with statuses like construction, proposed, and disused. For examples see #5599, #5741, #6151.

The problem with such presets is that there are too many combinations to tag (Proposed Motorway, Abandoned Motorway, Motorway Under Construction, Proposed Trunk Road, etc.) Instead of adding hundred of presets, we should just match these features to the base preset and show the status separately.

We'll need to do this alongside #2341 so users can actually set the status.

While there have been several methods of lifecycle tagging, it doesn't make sense for iD to attempt to support multiple and worry about what features use what status pattern. We should normalize to the <status>:<key>=<value> pattern since it seems to have the fewest drawbacks.* This pattern is already well used. Most mappers don't care what the actual tags are anyway and all data consumers would benefit from consistency.

_*See https://github.com/openstreetmap/iD/issues/6168#issuecomment-483023910 for my updated take on the tagging_

[westnordost]

With this feature added, would it still be possible to use the search, type "_proposed motorway_" and find the correct preset?

Independent of that, there are some arguments that may speak for using the <key> = <status> + <status> = <value> pattern instead:

• it is used roundabout 30 times as much as the other one, at least for construction
• it is documented on taginfo to be used already by some data consumers, including a QA tool that is specifically about maintaining highways and (ahem) also StreetComplete :-). For the other tagging pattern, I did not find any usage documentation.

[quincylvania]

With this feature added, would it still be possible to use the search, type "proposed motorway" and find the correct preset?

We could definitely build this, though they would be dynamic results rather than unique preset matches.

Independent of that, there are some arguments that may speak for using the <key> = <status> + <status> = <value> pattern instead

I know this change will be a pain point for some people, but I'm confident that the lifecycle prefix pattern (<status>:<key>=<value>) is the existing method that's best suited to iD.

While the <key> = <status> + <status> = <value> pattern is popular for some statuses of highways, railways, and buildings, it simply doesn't scale up well. With iD we want to let user tag the status of _any_ feature. We can't expect every data consumer to realize that entrance=proposed isn't actually an entrance. When the tag is instead proposed:entrance=garage, data consumers can easily ignore the tag by default. There are other benefits as well if you'd like me to go into detail.

[matkoniecz]

is the existing method that's best suited to iD

I would at least consider other parts of OSM ecosystem.

highway=construction + construction=* is for example quite standard, supported by many data consumers.

I am not convinced that expecting everyone to adjust to iD preset design is a good idea.

---

And mapping things like proposed entrances is a horrible idea anyway. Even mapping proposed roads is usually mess, frequently not worth it. Encouraging people to map even less important not actually existing objects is in my opinion a mistake.

---

I would propose to

(1) use highway=construction + construction=* and
railway=construction + construction=* and construction:<key>=<value> for other keys.

(2) avoid supporting mapping of proposed features

(3) Be careful with disused. Note that while for example disused theme park should use <key> = <status> + <status> = <value> pattern. But disused canal is still waterway=canal!

[slhh]

<key> = <status> + <status> = <value> is a bad tag design, because the second tag is meaningless without knowing the key of the first one.

<key> = <status> + <status>:<key> = <value> would solve this, but do we need the first tag then?
I think it depends whether we need it to describe the current state of the object while the second tag describes the future or former state of the object.

[slhh]

Reasonable support of the the lifecycle prefixes should allow to assign a preset (including all fields) per lifecycle.
Example usecases:

1. a disused railway which is a cycleway now
2. a disused highway/railway with bridge=yes could be tagged as man_made=bridge in present
   (the brige is still a landmark and potential height restriction)
3. a road which is under construction as a primary, but planned to become a motorway later
4. a road which is currently extended to become a motorway while it is still in use
5. a road which is currently rebuild: we need to differentiate access during the rebuild and future/former access.
6. A disused power house which is used as a sports center now.

[matkoniecz]

Most mappers don't care what the actual tags are anyway

Are you interested in discussing this proposed deprecation of highway=construction in iD with wider OSM community? (I thought about doing more with it, but there is no point in spending time on it if it would be ignored or considered undesirable).

For now I opened https://josm.openstreetmap.de/ticket/17607 proposing to handle construction:highway in JOSM (either by supporting both tagging schemes or by migrating from highway=construction or by migrating to construction:highway or some other variant)

[quincylvania]

So now that I've actually built this feature (not merged), I've come away with a more nuanced take.

iD currently assumes is that each feature is a single thing as it exists in the present to our best knowledge. Outdated data should be updated or removed. This makes any kind of lifecycle tagging an enormous headache. We're saying "this is a thing, but it was once another thing, and it might later this other thing still". This means different tags could refer to different things, only some of which are current. How confusing! Especially from UI and validation perspectives, not to mention data processing.

There's also been some conflation of access/usage and physical lifecycle. A disused subway is still a physical subway. A motorway under construction is still a motorway, and it may or may not allow traffic to pass during construction. One argument against just keeping the main tags like highway=motorway and defining lifecycle independently like construction=yes is that outdated data consumers will use the feature. Why not use access=no for old consumers and call it a day? The complexity of lifecycle prefixing and dual tagging seems worse.

In sum, I think both the <key>=<status> + <status>=<value> and <status>:<key>=<value> patterns are insufficient for use in iD and likely OSM more broadly. I suggest:

• Not supporting proposed or demolished features in iD. If people still add these then they should continue to purposely make the tagging incompatible with everything else.
• Not mixing lifecycle tagging with feature type tagging for disused, abandoned, or under construction features. Instead, new tags should be developed for construction state, operation status, and maintenance level. Access tags should be set accurately.

[tordans]

@quincylvania I agree with your last analysis (https://github.com/openstreetmap/iD/issues/6168#issuecomment-483023910).

Maybe it will help to re-list the usecases again to see what should and can be solved.

a. There are roads and railsways under construction - for the whole way and all traffic types
This is something an iD user should be able to map, IMO.
The current tagging schema is <key>=<status> + <status>=<value> which is well established and documented https://wiki.openstreetmap.org/wiki/Key:construction. Personally, I also find it a very weird tagging schema that took me ages to understand.
The good thing is, I don't need to understand it, once iD makes it just one click – which is the beauty of iD, that I don't need to (but can) understand the tagging in detail.

_To solve this, my suggestion is:_
Extend all highway=* tags with some UI-feature to toggle "is under construction". This feature then moves the tags around to fit the above tagging schema (the user does not need to know about it). Technically I think of this like a link that transforms from the a highway-preset to the corresponding highway-construction-preset. Which means, all highway-presents need duplicating for the highway-construction-part; but is that really bad?

Same goes for railways (https://github.com/openstreetmap/iD/issues/6151).

b. There are roads and railways under construction but only a few traffic types are effected
This is something an iD user should be aware of IMO. But I don't know if there is a simple way to also make it easy to edit. But at least the case (a) should clearly state _"This will block the whole road with all traffic types, only do this if all traffic types are blocked. Otherwise {leave a Node with description}(LinkToAddNodeUI) for others to fix."_
The current tagging schema is motor_vehicle:conditional=no @ (2018 May 22-2018 Oct 7) which seems to be well established and documented https://wiki.openstreetmap.org/wiki/DE:Conditional_restrictions; the wiki/Key:construction references it for this use case.
Ideally, iD would make those conditional access-tags easy to edit; which is not easy to do.

To solve this, my suggestion is:
b.1 For now just render motor_vehicle:conditional as part of the access-preset-group if present.
b.2 Build a dedicated conditional access UI (which we should talk about in a separate issue).

c. There are planned roads and railways
Like https://www.openstreetmap.org/way/134480069#map=17/52.49402/13.46167, which actually might never get build.
I think is very OK to leave this kind of mapping to pro-users that know how to set the tags manually.

d. There are features that are razed or abandoned
I believe those data types are useful for some situations, eg:

• Instead of removing a building I mark it "razed:building" to indicate that is was there before. So once someone looks at an areal image he knows that its not an error that it is missing on the map. An example is https://www.openstreetmap.org/way/504630765 with the areal images from 2005 that still has it.
• Same goes for matching external data sources, eg the tree-index of a city. Some trees I don't delete but mark as razed:natural=tree so I know OSM is up to date and the city index is not updated yet.

Both cases are IMO fine the way they are ATM. Like (c) they are something for advanced users.

To sum it up, IMO all we need is:

1. A nicer interface to handle the construction=* tagging
2. A solution to handle *:conditional tagging

Instead, new tags should be developed for construction state, operation status, and maintenance level. Access tags should be set accurately.

Looking at those usecases I don't see an advantage in starting the process to change the existing tagging for construction. IMO just build iD around it – for this specific case highway + railway.

Did I forget any use cases? (That are relevant for iD…)