save editing session similar to other GIS app

[emmanuel.sambale@…]

When editing in JOSM, I usually load several gps traces, an OSM file and a some WMS. I often upload/download changes. But when I close JOSM I need to reload all the traces, etc. I want something like a qgis project file to save my editing session for future edits.

[Nakor]

I was thinking of a similar thing:

When closing JOSM it would save layer names with associated files (or set of files) + current view in a session file.
When loading JOSM layers would be reconstructed from that list and current view would be restored.

[Nakor]

Temporary patch

[Nakor]

I attached a temporary patch. It works quite well with Osm and Gpx layer. It fails with Image Layers. Other are not yet implemented.

As explained on the mailing list I am having trouble with getting the layer sometimes a they are created in the background. Just look for FIXME in the code.

[anonymous]

There are 2 threads: Event Dispatch Thread (EDT) and the main worker thread (Main.worker). User interaction happens in EDT and to change a GUI element, you must be in EDT. The worker thread is for long processes (e.g. opening a file or removing duplicate nodes in validator) so that the GUI does not freeze. When you are in EDT, you can schedule a task for the worker thread like this:

Main.worker.submit(heavyTask);

When you are in the worker thread you can submit a task for the EDT like this:

SwingUtilities.invokeLater(uiStuff);

In this basic setup you will not know from one thread when a certain task has finished in the other thread. So this does not work:

final Object result = null;
Runnable loader = new Runnable() {
  public void run() {
    result = loadAlot();
  }           
}
Main.worker.submit(loader);
System.err.println(result);

But luckily the second task will not start before the first has finished, so this works:

final Object result = null;
Runnable loader = new Runnable() {
  public void run() {
    result = loadAlot();
  }           
}
Runnable postProcessing = new Runnable() {
  public void run() {
    System.err.println(result);
  }           
}
Main.worker.submit(loader);
Main.worker.submit(postProcessing);

(The reverse is also true, i.e. submitting 2 GUI tasks from the worker, the first finishes first.)

Most of the stuff that you are dealing with happens in the worker thread. This is from OsmImporter:

    protected void importData(InputStream in, File associatedFile) throws IllegalDataException {
        DataSet dataSet = OsmReader.parseDataSet(in, NullProgressMonitor.INSTANCE);
        final OsmDataLayer layer = new OsmDataLayer(dataSet, associatedFile.getName(), associatedFile);
        // FIXME: remove UI stuff from IO subsystem
        //
        Runnable uiStuff = new Runnable() {
            public void run() {
                Main.main.addLayer(layer);
                layer.onPostLoadFromFile();
            }
        };
        if (SwingUtilities.isEventDispatchThread()) {
            uiStuff.run();
        } else {
            SwingUtilities.invokeLater(uiStuff);
        }
    }

As the comment says, it might be a good idea to remove the gui stuff from the importer and move it into the OpenFileAction and SessionImporter (?) respectively.

[bastiK]

anonymous is me

[bastiK]

Another thing: you should probably move the code for reading and writing the xml data to the individual layer files. After all, there might be all kinds of layers from plugins, like OpenStreetBugs and so on...

[Nakor]

Not sure when I'll have time to look into this again. Anyone is free to implement it using the preliminary work I did if they want.

[bastiK]

In [4668/josm]:

session support (first part, see #4029)

Idea: Save and load the current session, i.e. list of open layers and possibly more.
This change includes only support for reading session files and only for osm-data layers.

session.svg: Public Domain

[bastiK]

Here is the general idea:

A .jos file looks like this, and contains meta-data in a human readable format:

<?xml version="1.0" encoding="utf-8"?>
<josm-session version="0.1">
    <layers>
        <layer index="1" name="test.osm" type="osm-data" version="0.1">
            <file>file:/home/user/test.osm</file>
        </layer>
        <layer index="2" name="test2.osm" type="osm-data" version="0.1">
            <file>file:/home/user/test2.osm</file>
        </layer>
    </layers>
</josm-session>

A .joz file is a zip archive that contains at least one .jos file. In this case, data files (.osm, .gpx, .png) can be included in the zip archive, so the file gets self contained.

I can see two primarily use cases:

• Save work in progress and easily restore the selection of layers, viewport etc. after restarting JOSM.
• Distribute packages from a website, e.g. for bug-fixing. You could even include map paint styles and presets or ensure that a certain projection is selected.

(Menu entry is currently hidden, unlock with session=true.)

[Zverikk]

Don't forget saving current position and zoom :)

[bastiK]

In [4685/josm]:

session support (second part: "save as", see #4029)

still osm-data layer is the only implemented layer type

[bastiK]

The basic setup for exporting and importing the list of layers is finished. Now we need to add more layer types.

[bastiK]

I don't know how to export a marker layer to a file. Normally the markers come from a gpx file, but not always - the user can add additional audio playback bookmarks and so on.

[bastiK]

Ticket #7656 has been marked as a duplicate of this ticket.

[skyper]

Ticket #7718 has been marked as a duplicate of this ticket.

[bastiK]

Ticket #7809 has been marked as a duplicate of this ticket.

[bastiK]

Ticket #7810 has been marked as a duplicate of this ticket.

[bastiK]

In [5391]:

add session support for imagery layers

[bastiK]

In 5501/josm:

add session support for gpx layers (see #4029)

[bastiK]

In 5505/josm:

add session support for geoimage layers (see #4029)

[bastiK]

In 5551/josm:

see #4029 - remember layer visibility/opacity

[anonymous]

Will this also remember other settings, such as suppress errors from TMS layer etc. The reason I ask is that I sometimes uses a OpenSeaMap layer as layover to see existing seamarks rendered. This layer returns errors for each tile without any seamarks as it returns Error 404 instead of a blank tile. I generally deselect the "show errors" on this layer to avoid cluttering the screen with error messages

[bastiK]

Replying to anonymous:

Will this also remember other settings, such as suppress errors from TMS layer etc. The reason I ask is that I sometimes uses a OpenSeaMap layer as layover to see existing seamarks rendered. This layer returns errors for each tile without any seamarks as it returns Error 404 instead of a blank tile. I generally deselect the "show errors" on this layer to avoid cluttering the screen with error messages

Not yet, but I'll put it on the TODO list.

[bastiK]

In 5670/josm:

session: save & restore map position and scale (see #4029)

[bastiK]

In 5684/josm:

add session support for marker layers (see #4029)

The data is exported to a separate GPX file that contains one waypoint for each marker.
This is not very elegant, because most of the time, all the info is already contained in the original GPX File.
However, when dealing with audio markers, they can be synchronized, or additional markers are added
at certain playback positions. This info must be retained.
Another complication is, that two or more MarkerLayers can be merged to one.

All these problems are avoided by explicitly exporting the markers to a separate file (as done in this commit).

[bastiK]

Most of the changes in [5684] affect only the code for the (unpublished) session feature, so I hope it doesn't introduce any bugs for the release next week. :)

[Don-vip]

Replying to bastiK:

I hope it doesn't introduce any bugs for the release next week. :)

This particular change, no, but older ones did broke a bunch of plugins (compile errors):

• globalsat
• gpxfilter
• openvisible
• livegps
• public_transport

I have myself broken reverter plugin with r5680, fix on the way :)

[bastiK]

Ok, plugins updated in ​[o29222], ​[o29223].