[josm-dev] Path to spatial index [long][Was: Refactoring of the JOSM architecture vs. Plugins]
jh at foobar.de
Thu Aug 21 23:51:36 BST 2008
thanks for your brilliant analysis! Your grasp of the issues around
JOSM(-NG) ist quite a bit tighter than mine at this point :-)
May I ask some stupid questions?
Petr Nejedly schrieb:
> Right. You do some attempts on relation rendering, so filtering them will come handy.
> Not because there are many of them (to the contrary), but because the index API
> would be very simple then: Iterable<OsmPrimitive> giveMeAllThePrimitivesInside(Bounds bounds);
> (or better "visitAllThePrimitivesInside(Bounds bounds, Visitor vis);"
Speaking of bounds: I saw that in -NG your QTree indexes all primitives
by bounds. Have you considered indexing ways (or rather their segments)
by intersected (crossed) nodes instead of using the segment bounds? I
guess with a bucket size of 100 that might not make that much of a
difference, because segments are usually relatively short compared to
the node density, but you might have had other reasons as well.
> Not initially, but you will, earlier or later, end up caching the associated style too,
> (this is the "below" where you'll clutter OsmPrimitive with another field) and this is
> tags dependent.
Yes, also because damage tracking is dependent on the visual (pixel)
extent for a primitive which, in turn is style dependent.
> Also, the index might take current zoom into account too and structurally
> filter out unimportant (highway=residential, untagged node) primitives when looking
> at the whole shebang. See:
> The second important thing is the way you'll react to modifications. You've got the hook
> in the form of setCoords, so what would you do?
> 1. Update the index for given Node (that is, remove and readd it)
> 2. Find all the referers (ways, relations). Well, (d) from third paragraph has higher
> importance, it seems, as long as you don't have self-consistent backref baked into
> the DataSet (josm-ng does)
> 3. Update referer bboxes (maybe recursively)
> Is this right? NO! Imagine a user drags a 4000node forest (there is one such in Germany,
> and I've even been (physically) to one 5500+ nodes in Poland recently ;-) )
> You're going to get 4000 node updates and you're likely to end up visiting all the 4000 nodes
> each time to compute the new bounds (4000^2).
Sorry, you've lost me with the -squared. Why would we have to visit all
other nodes per node?
> Also, possibly traversing a large hierarchy
> of relations (there is one such in Germany, covering all the motorways, boundaries and so on)
> each time won't be nice too. Safer is to:
> 1. Add the node to a queue. Period. Full stop.
> OK, 2. before each index inquiry, collect all the primitives influenced by the queue content
> and update them only once.
Are you talking about transient operations (like repaints during a drag
operation) with a "commit" into the index after the drag ended here, or
about longer-lived entries in this queue?
More information about the josm-dev