On Tue, Dec 27, 2011 at 8:59 AM, Dirk Stöcker <openstreet...@dstoecker.de> wrote: > On Tue, 27 Dec 2011, Josh Doe wrote: > >> I'd like to work on this functionality this week, any comments? > > > Only one: It is very unlikely that for most installations additional > searches are registered and if, then only a few. So the aim should be to > have the internal searches be as fast as possible and not to reduce > performance too much due to large overhead. > > I think at least for filters the compile speed may be relevant.
I've got some trivial search plugins working now, by extending Match with PluginMatch (which has abstract getKeyword() and getDescription()), and only checking for these plugin search operators after the core operators, so there should be no impact on compile speed unless you're using plugin provided operators. I'm most interested in creating an "inside" or "within" search operator using the functionality from utilsplugin2. I refactored the relevant bits in SelectAllInsideAction and moved it to NodeWayUtils, but I don't think I can directly use Match for this. For example, I would like to be able to search for all buildings within school boundaries, so I would imagine using this search string: "building=* inside amenity=school" (knowing full well that not all schools are tagged this way). However a simple boolean match doesn't work for this. Instead I would need a function which returns a Collection<OsmPrimitive> for a given OsmPrimitive. Any idea how I could make this work? Perhaps allow something like "inside(amenity=school)"? I think I'd need to understand the search compiler much better to tackle this by myself. Thanks, -Josh _______________________________________________ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev