Doesn't persist seen area after closing JOSM

[mattwelke]

Hello. I was pointed to this tool after posting in the forums.

It's brilliant! It's already making things easier for me. I'm adding rooftop solar and also going to be coordinating with others too to add lots of rooftop solar, and it's helpful to be able to keep track of what I've seen as I pan across the map.

But I found that it didn't persist. When I close JOSM, I tried using the "Save Session" option. But when I finish re-opening that session:

The viewer loses that pink area showing what's already been seen. After I re-open JOSM, it looks like this:

I'm thinking JSOM doesn't consider the state stored by this plugin for that seen area as state for the session.

Do you think there's a way for me to solve this? Or would I have to work around it by tracking the seen area at a macro level somehow else, and using this only for micro seen area tracking?

[risicle]

I'm afraid you're not likely to see that anytime soon, markseen being more-or-less in maintenance mode.

The first thing someone would have to do is invent a file format for a quadtree-bitmap... zip file of z/x/y.png dir structure only including the "canonical" tiles perhaps?

[mattwelke]

I was thinking of taking this feature on myself if it's in maintenance mode. I'm guessing we need a file format because plugins have some sort of persistence interface and if we can set things up correctly, it can store files (maybe inside the session saved to disk) and read them to keep going when the JOSM session is resumed later?

[risicle]

From my previous suggestion, forget using a z/x/y.png structure, it'll be much easier to base the directory structure directly on the quadtree structure - much harder to generate an invalid dir structure. But a zip file full of a dir structure of pngs does make sense, if only because java has native support for writing both.

So what you'll want to do for saving is descend the QuadTreeNode tree until you reach the "canonical" level for each tile (where canonicalMask != null). Neatest way to do that is probably to give QuadTreeNode a method that will, if the current QuadTreeNode is belowCanonical, generate a directory for itself and recurse down into the method on each of its children, passing them a reference to the new directory which they can either generate their own directories in (if still belowCanonical) or if canonicalMask != null, write that to a PNG in the directory. I don't know how good java ImageIO's support for writing 1-bit PNGs is - the BufferedImages use TYPE_BYTE_BINARY, hopefully you won't have too much of a fight on your hands.

For loading, I guess the best bet is a special constructor that does effectively the inverse. There aren't many data members on QuadTreeNode, so it should be hard to screw up. children below the canonical node can be left null during construction because they will be auto-generated as needed. mask can be ignored for the same reason.

The rest of the classes should know what to do with a valid QuadTreeNode tree via a QuadTreeNodeDynamicReference. The only thing you may have trouble with is transplanting a new tree into an already-running plugin because any QuadTreeNodeDynamicReferences will now be invalid (or at least have cached references to objects from the old tree).. possibly you'd be best off starting from scratch with a fresh MarkSeenSlippyMapBBoxChooser if loading from a file after first init 🤷