Repository navigation
Doesn't persist seen area after closing JOSM #7
Description
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?
Activity
risicle commentedon Nov 18, 2025
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.pngdir structure only including the "canonical" tiles perhaps?mattwelke commentedon Nov 18, 2025
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 commentedon Nov 19, 2025
From my previous suggestion, forget using a
z/x/y.pngstructure, 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
QuadTreeNodetree until you reach the "canonical" level for each tile (wherecanonicalMask != null). Neatest way to do that is probably to giveQuadTreeNodea method that will, if the currentQuadTreeNodeisbelowCanonical, 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 stillbelowCanonical) or ifcanonicalMask != 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 - theBufferedImages useTYPE_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.childrenbelow the canonical node can be leftnullduring construction because they will be auto-generated as needed.maskcan be ignored for the same reason.The rest of the classes should know what to do with a valid
QuadTreeNodetree via aQuadTreeNodeDynamicReference. The only thing you may have trouble with is transplanting a new tree into an already-running plugin because anyQuadTreeNodeDynamicReferences 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 freshMarkSeenSlippyMapBBoxChooserif loading from a file after first init 🤷