Feature request: "Open osmChange file" / "Upload osmChange file" / "Import CS"

[sun-geo]

Currently there is an option to save a changeset as an osmChange-file, e.g. before uploading to the osm-db, which is a kind of an CS-"export".

It would be also nice to have the ability the other way around to open an osmChange-file, for loading cs-data into iD, which means for preparing a later upload to the osm-db as a next step, the whole procedure could maybe also called as a CS-"import".

[mmd-osm]

Do you have a similar use case like #7071 in mind, i.e. saving your current work and continue at a later point in time? If not, I was wondering a bit how you manage to create some osmChange to be imported in iD in the first place?

[thibaultmol]

I've also been thinking about this. If you're working on a big changeset, somehow it's nice to have a 'real file' with your changes, in case somehow the browser storage gets cleared or you accidentally clicked on the wrong button when resuming and removed the edits.

[sun-geo]

use cases:

• transfer a cs from JOSM to iD (other way around is working fine already right now)
• kind of batch uploads, if you want define a specific upload time
• start a cs with one osm-account upload it with another one

@mmd-osm btw, what were the use cases at that time, when JOSM did implement the option to open *.osc files?

[thibaultmol]

That's actually also something I forgot to mention. I'd also use it for batch uploads. Sometimes you feel like working on adding some new businesses, sometimes you want work on road surfaces. So either I submit the changeset and start working on the other thing. But If I could just download the one dataset and then start a new one, that'd be nice

[mmd-osm]

btw, what were the use cases at that time, when JOSM did implement the option to open *.osc files?

I think that's a good question. I don't recall ever seeing a JOSM version without osc support, and my gut feeling is that is has been supported for at least 9 years now, probably longer. I don't really know when/why it was added in the first place.

Working with osc files is a bit of an advanced topic for the "typical mapper" (if that even exists), and I was curious about the use case you had in mind.

[mikini]

Another use case:

• Reverting a change by editing text of saved osc file directly, then reloading it

The need for this could be alleviated by more flexible undo/redo functionality (undo a change not on top of stack).

@sun-geo 's first use case above could also be generalized to "from one editor to another" (example of user wanting to load osc file from OsmAnd).

Strangely, JOSM seems unable to produce an osc file from the changes done on a layer. Only the complete layer can be saved.

[bananu7]

The need for this could be alleviated by more flexible undo/redo functionality (undo a change not on top of stack).

Even being able to revert changes per-feature would be nice. Right now I can see the list of features I modified and added, and download the .osc file. However, I think I've edited one thing by mistake, and it seems I have no way to revert just that part; I'd need to discard everything and start over.

If I could upload the .osc file, I'd just edit it and remove the changes to that feature manually. Being able to see what changes I made in the web UI would be amazing, but if that's too much work, at least selectively discarding them seems like a no-brainer.

Edit: tbh even after submitting the edit, the OSM changeset view isn't really helpful. I can see the current state, but I can't see what exactly I've edited...

[mmd-osm]

OSM changeset view isn't really helpful. I can see the current state, but I can't see what exactly I've edited...

You can use OSMCha or Achavi for that purpose. Achavi can also display diff files when you drag and drop your osc file to the app.

[quincylvania]

@bananu7 Thanks, resetting individual entities is #537.

[dabreegster]

Another use case: I'm running routing or rendering software locally that consumes OSM data (either as XML or PBF). I'm considering uploading a changeset to OSM to fix an issue with that software. But I'm not sure my change will actually fix the problem, and there's no clear consensus for how to tag the particular situation. Instead of uploading the changeset, updating my local .osm file from the live data, reimporting into the local software, and checking how it works, I'd like to just save the .osc file, use osmupdate to locally update my copy of a .osm file, and try in the software.

Today, part of this works: I can make a change in ID, save the .osc, try it out locally. But after I try a few possible ways of tagging, I want to upload the changeset, and maybe I've closed my browser tab by then. Or maybe I want to send the .osc to somebody else, have them modify it a bit, and send it back. Loading the .osc in ID is the gap.

I can sort of use this workflow with JOSM, but ID's UI is significantly easier to use. :)

I'm not a JS developer, but I'd be happy to try implementing this, with some gentle guidance.

[sun-geo]

Because there is a recent de-forum talk Data protection for mappers - it would be nice to see this implemented in the future :-)

[CocolinoFan]

Bump

[endolith]

I saved from iD to an .osc file assuming I could load it back in later to finish the changes, but I can't. :/