I ran josm with your patch. Here are some initial general observations which do not include any analysis of the algorithm itself.
It seems the QuadBuckets class is referenced only through the Collection<Node> interface, and none of the features (i.e. fast searching within a bbox) are actually used? Rather than adding dead code (presumably with a view to enabling it later), an easier path into the trunk might be to first refactor josm to use a "SpatialIndex" interface that initially is backed by a List/Collection (i.e. low risk and no change to current performance), and adding working indexes later (initially via plugins for testing). Another observation: It looks like QuadBuckets only works with actual Lat/Longs (i.e. no numbers above 360). It would be nice to handle arbitrary coordinates - two use cases that come to mind are: 1. index screen coordinates (e.g. so that a highlight can follow the nearest object to the cursor and indicate what would be selected if the mouse was clicked). 2. index projected coordinates Finally, a spatial index implementation should be generic enough to be used in multiple places in the code (e.g. an index of way segments, or whatever), so implementing Collection<Node> is too specialised. Aled _______________________________________________ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev