iD Lifecycle Menu (WiP)

Added a new Lifecycle Menu in the Sidebar for editing entites lifecycle.

Main Code Changes:

Added a new lifecycle_editor.js class to manage entites lifecycle.
- Only general purpose for now, does not take into account particular feature preferences
- Can add and edit additional lifecycle into the entity (like planned:maxspeed)
Expandend on how lifecycle are defined in tags.js (defaultVisibility, defaultIcon and more)
Modified how preset.js and index.js handle lifecycle to consider for lifecycle
- The matchScore function has been modified to take into account possible lifecycles
- Added a setLifecycle function and a lifecycle attribute to keep track of an entity lifecycle
Added some tags in tag_classed.js
Added a safe to check.js so that the undefined value is not cycled through (only in extra lifecycle)
Added some code in feature_type to show the lifecycle status to better flash out the current lifecycle
Added some CSS class
Added some core.yaml strings

Still wip (expect bugs!). Testing, opening issues and generally telling us what you think will be of great support!

Thanks to @tyrasd for the continuous support ❤️

Mar 06 '25 14:03 mattiapezzotti

Still wip (expect bugs!). Testing, opening issues and generally telling us what you think will be of great support!

Is it possible to setup an iD instance so it can be tested more easily?

Mar 11 '25 15:03 Dimitar5555

I just did a local build and dropped the dist folder into netlify to get a working online preview. That works really nicely and will probably be easier using the CLI.

Here it is https://timely-marzipan-975952.netlify.app/#disable_features=boundaries&map=19.14/50.82217/6.36224&background=Bing&locale=en&id=w1208199370

Note to self: https://app.netlify.com/sites/timely-marzipan-975952/deploys/67e90a27a0eeb070396c1409

I cannot add members to my free Netfliy account, so this is all just temporary. But using the CLI it should be quite quick to have a half manual process to create temporary additional staging environments @tyrasd.

Mar 30 '25 09:03 tordans

Thanks for sharing this WIP state of the project! It's looking very promising to me!

I looked around a bit – here are some unordered "first impressions" notes:

I kind of expected the UI to be somewhere here . To me this is the area that represents the feature that has the live cycle.

Maybe some icon next to the (i) icon?

One idea I had was, that the life cycle is more like an edit action on the object. Which would mean, it belongs into the menu of the object

Then the question is, how to expose this in the left panel. Maybe we need some of the action buttons there as well? Maybe straighten, life cycle, square for roads, for example?

I wonder if we should add something to the tagging schema like "enable lifecycle" or "has potentially lifecycle". Right now, the new UI is quite prominent one you scroll down. But is it really relevant for all presets?

For example: natural=tree_stump would not really need a live cycle. One could argue a razed:natural=tree_stump but the preset itself is kind of the end of the life cycle for a natural=tree. Actually, my pattern in berlin is natural=tree becomes natural=tree_stump becomes razed:natural=tree a few years later.

Usually changing the life cycle is something that happens very rarely. That might also be why I wonder if it is too prominent right now.

Are the options in the life cycle the same for all objects? Is this something iD want to take a stance on to standardize? Or do we need a way to customize those per preset via the schema? Or maybe this is something based on the primary key? Like for natural the prefix abandoned: and demolished: don't make much sense. Actually, none do. It would be more likely razed:natural=(tree)

Visual glitch:

Typo: visibleByDeafult

I don't quite understand the + button at the bottom:

It feels to much for me. If I need a prefix that is not recommend/predefined, I just add it via the "Tags" UI. That is faster and I will likely need to go there anyways.

Where is the decision being made to use the one or other life cycle tagging schema? (Adding a tag vs. adding a prefix) (Scrolled through the code but it did not jump out to me.)

When looking at the life cycle section, I am missing an option in the list that is "all good". The way to do it ATM is to click the trash Icon, right? That feels counter intuitive to me. It is kind of how the other fields work, but we are not in the fields section here. I think the options list should have a "no life cycle" at the top"

The remove > re add flow does not work quite right, yet, I think:

select preset building under construction
building=construction
trash life cycle
building=yes
add live cycle via UI:
```
building=construction
construction=yes
```
The second line should not be there, right?

Something change in how the icons are picked in the map as well, right? Did we always "ignore the prefix for the icon? Like this tree and tree_stump show the preset icon but have life cycle prefixes:

I think this needs some kind of additional indication on the object.

Maybe just making the border dotted, to indicate "some life cycle"?
Maybe add the icon from the options as a secondary icon on the pin?

I think option 1 I the one that is good enough and has less potential side effects. I think we wanted to use a second icon for something else at some point for thinks like "unspecified shop/building/…"? (See id tagging schema thread on unspecified shop where we added the ? to the icon (hard coded))

I might be missreading this, but why is foo:natural=* displayed as natural | foo below … when the new UI shows the form as prefix | key (so foo | natural)

Again, just my unfiltered first impression. Hope that helps in some way.

Mar 30 '25 09:03 tordans

Hi @tordans, thank you very much for the feedback, I really appreciate it. It sounds like you got a past version, as some of the things you mentioned are currently fixed. One thing I would like to be clear about is how we decided what should be a prefix and what should not: you can find all sort of information at this link. As you can see it's still a WIP so any decision is not final. I'm open to all kind of suggestion/criticisms so just let me know!

Mar 30 '25 15:03 mattiapezzotti

Just wanted to note that the OpenHistoricalMap development team is following along with interest. OHM has a different approach to recording lifecycle that doesn’t necessarily require namespacing, so we’d probably end up hiding this feature at the outset or reusing it for a different purpose later on. But we’d be very happy to see something like this make it into OSM’s version of iD; it could serve as a good entry point for a future workflow for transferring data to OHM for safekeeping, or at least to inform the user of that possibility.

Mar 30 '25 16:03 1ec5

It sounds like you got a past version, as some of the things you mentioned are currently fixed.

I just updated the version at https://timely-marzipan-975952.netlify.app/#disable_features=boundaries&map=19.14/50.82217/6.36224&background=Bing&locale=en with the latest changes

One thing I noticed was that this UI seems to not work (anymore). I can write things but I cannot apply / add the tag.

Mar 31 '25 05:03 tordans

how we decided what should be a prefix and what should not: you can find all sort of information at this link.

Thanks for sharing! In general I always find it easier to follow and evaluate changes/features when some spend is spendon the reasoning for the and details of the change. Usually this happens by discussing the "what" in an issue and (only after) the "how" in a PR. I am just mentioning it here, because I think the life cycle project lacks some of the pieces that we usually have, yet, so they might come up now.

The text you linked makes me think again on what I briefly mentioned above: Where do we store those decisions per preset and how do we handle requests by the community. And, given this an area that is IMO badly documented until now… how to we make sure we have something that we can roll out without either opening us to criticism of "but in this case I like to do Y and now you promote Z" and at the same time, not spending month on discussing many edge cases before the feature can be rolled out at all. — A way that could work is by first managing a very explicit list on where the feature is active and gradually rolling out more presets that will show the feature. This sounds like what we do with the tagging-schema repo so maybe we should manage it there?

What would the data need to tell us?

for a preset like highways…
… show this list of live cycle options
- planned
- …
- construction
… and for each of those options, use that life cycle schema
- planned => prefix
- …
- construction => key+subkey

We will probably find many presets that use the same set of option-defintions, so we would want this to be shareable between presets or maybe even manage it the other way around (flip the data structure to list the presets on a given file cycle option-defintions).

Mar 31 '25 06:03 tordans

It sounds like you got a past version, as some of the things you mentioned are currently fixed.

I just updated the version at https://timely-marzipan-975952.netlify.app/#disable_features=boundaries&map=19.14/50.82217/6.36224&background=Bing&locale=en with the latest changes

One thing I noticed was that this UI seems to not work (anymore). I can write things but I cannot apply / add the tag.

Yeah I'm still working on how to handle and display errors, But technically this is intended to not work as you are trying to use a prefix that isn't generally used by the community (you can take a look at what's allowed in the tags.js module). And it's still an older version somehow (?) currently it's a bit different: you are only allowed to add a new "extra" lifecycle if the prefix is allowed and the tag is included in the "fields" of the preset (by desing as chosen by Martin here, so we can re-use the fields UI)

When looking at the life cycle section, I am missing an option in the list that is "all good". The way to do it ATM is to click the trash Icon, right? That feels counter intuitive to me. It is kind of how the other fields work, but we are not in the fields section here. I think the options list should have a "no life cycle" at the top"

I feel like this is the right way, when no lifecycle is selected the menu is clear from selection and when something is "lifecycled" you can delete the lifecycle only, the trash icon surely wasn't the best so I changed it to be a minus, but I still think that there should be a unique icon to "make a feature functional".

The text you linked makes me think again on what I briefly mentioned above: Where do we store those decisions per preset and how do we handle requests by the community.

Currently there isn't a way to change how the lifecycle class behaves based on the preset. This is surely something that we can think about and makes a lot of sense.

Thank you again for all your suggestions

Mar 31 '25 08:03 mattiapezzotti

Hello

I'm really happy of this undergoing work to ease the management of lifecycle of features in OSM, thank you for making this happen. I wasn't aware of it yet, that's why I couldn't answer to the initial question about practices regarding power key.

I gave it a try on timely-marzipan-975952.netlify.app and hope it's the latest version. One important feedback about the lifecycle menu is it should prevent any mixup between lifecycle steps. Unfortunately I was able to do this without receiving a warning: It assumed my feature was under construction but it was possible to decide it was just existing. Invalid combinations between lifecycle steps arise and mappers would get great help from iD to warn them about such mistakes.

Removing the construction state by using the trash icon from the lifecycle menu remove both construction:power=line and power=line and replace them by power=yes. I expected power=line only.

To me, existing is an implicit lifecycle step and it should be part of the list between Under construction and Disused. Remove lifecycle just make the feature exist, so it's a particular lifecycle step although it's default.

And, given this an area that is IMO badly documented until now… how to we make sure we have something that we can roll out without either opening us to criticism of "but in this case I like to do Y and now you promote Z" and at the same time, not spending month on discussing many edge cases before the feature can be rolled out at all.

I don't want to over clutter the discussion and feel free to indicate a more appropriate place to discuss about it. As I understood power wasn't part of the preliminary study in the shared sheet. Lifecycle usage is documented here: https://wiki.openstreetmap.org/wiki/Key:power#Lifecycle We would be even happier if this enhancement won't encourage power=construction as it is highly undesired please.

Keep up with the good work!

May 13 '25 15:05 flacombe

I gave it a try on timely-marzipan-975952.netlify.app and hope it's the latest version.

It was probably not. I just updated it with the latest changs. https://timely-marzipan-975952.netlify.app/#disable_features=boundaries&map=19.14/50.82214/6.36230&locale=en

note to self

git checkout github-desktop-mattiapezzotti/lifecycle
git pull upstream
npm run all
npm run build
open https://app.netlify.com/projects/timely-marzipan-975952/deploys
open .
drag n drop /dist

May 14 '25 05:05 tordans

Hello @tordans and thank you for updating your staging.

My previous comments remain valid this morning with the up to date version.

May 14 '25 06:05 flacombe

Hello everyone! I am thankful that my work is being watched by other mappers so that I can always improve. There are things we hadn't considered (or took for granted) and certainly hearing more voices is one way to avoid these mistakes. I should have fixed the problems with the powerline, but the problem of how the “construction” lifecycle is added remains. As it stands, the class does not take into account whether or not a preset may prefer a certain type of tagging (construction:power = line instead of construction = line etc..) or not (razed rather than demolished). The section has been constructed to be as general as possible for now and then if needed it can be adapted (or removed) as needed.

If you find more bugs please report them so we can fix them, there are a lot of presets and feature types in iD and not everything might respond in the same way. Again thank you for testing things out and happy mapping!

May 14 '25 10:05 mattiapezzotti

Hi @mattiapezzotti

Thank you for quick care of feedback, I look forward testing it. @tordans if not too time consuming, can you update your Netlify please? Or I'll wait further improvements to group the update with others.

The section has been constructed to be as general as possible for now and then if needed it can be adapted (or removed) as needed.

Aren't we fear that significant downward will be hidden under some goodwill? Isn't it possible to make the panel available for a small group of presets we would update at first, to show how relevant it is? Deploying on further presets will require to update them case by case, when they're ready as to not introduce wrong data. "If you want it, build it".

Forcing the panel to appear everywhere even when presets not ready is a good strategy to get it finally rejected.

May 19 '25 16:05 flacombe