Petr, 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: > http://svn.openstreetmap.org/applications/editors/josm-ng/src/org/openstreetmap/josmng/view/osm/View.java > Great Idea! > 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? Joerg _______________________________________________ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
