[josm-dev] Allow plugins to register search operators

[Josh Doe]

On Tue, Dec 27, 2011 at 8:59 AM, Dirk Stöcker
<openstreetmap at 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