Topological search/filter

[Zverikk]

Could you please add inside() clause for selecting or filtering all objects inside some area? And probably also intersects() for objects that have common nodes with specified ones.

[joshdoe]

I've been thinking about this as well. "inside selected" would find objects inside the currently selected way(s) or multipolygons. This would be useful tool for finding amenities inside a park, address nodes inside a building way, etc. I don't think JOSM has any capabilities for this kind of topological check. Has there been any consideration given to using the Java Topology Suite (JTS)? While perhaps not for replacing existing classes, perhaps there could at least be a translator. Is there any method of implementing search functions as plugins?

[joshdoe]

For reference the relevant JTS functions are part of com.vividsolutions.jts.geom.Geometry, ​within() and ​intersects(). We'd gain all sorts of other useful functions as well.

[stoecker]

Replying to joshdoe:

Is there any method of implementing search functions as plugins?

If not, then send a patch and it will be included.

[simon04]

Replying to stoecker:

Replying to joshdoe:

Is there any method of implementing search functions as plugins?

If not, then send a patch and it will be included.

This is also the current status of #6232. :-)

[akks]

There are similar functions (intersected objects and objects insisde) in UtilsPLuins2 (Select menu). You can use them for adding search clauses.

JTS can be faster, but it needs conversion of original geometry, does not it?

Extension search with plugins is a good idea. I hope someone will implement it.

[joshdoe]

I've created a patch which allows plugins to register search operators, and for a demonstration I create an inside search operator. Read more at #7178. I'll add other operators once the design is finalized and committed.

[joshdoe]

Note that #7178 has been accepted into core, so this functionality can now be implemented. If you see that ticket, there's a patch implementing search keywords inside, intersecting, and allintersecting. Are these good names? What about for the other keywords? adjacentnodes, adjacentways, allconnectedways?

[akks]

Thank you, it is really a big advance in search!
Some of my thoughts:

inside looks really good. I did not optimize the performance of Utilsplugin2 function (only BBOX checking), so some search queries may be extremely slow for big datasets :)

intersecting can be also useful, name is rather long to type (maybe intersect or cross?)

allintersecting - does someone need recursive intersection search? Find all ways that intersect some ways that intersect some way that intersect some way... It can be rarely used for selecting large groups of connected/intersecting ways. It can be very slow, I warn :)

Maybe we need some queies like adjacent for ways ("residential adjacent unclassified", for example), it is much harder to imagine adjacent nodes searching...

allconnectedways can become something like connected ("track connected trunk" with unclassified between that roads?), if it id needed.

[akks]

@joshdoe
Why does not author apply (or modify) the patch for Utilsplugin2 adding new keywords from #7178? ;)

[joshdoe]

Replying to akks:

@joshdoe
Why does not author apply (or modify) the patch for Utilsplugin2 adding new keywords from #7178? ;)

Sorry, just got around to this, in [o27936] with JAR updated in [o27938]. This just includes inside, intersecting, and all intersecting. I won't close this ticket until other operators are implemented. Others are welcome to follow my pattern and implement others.

[akks]

Thank you very much!
I tested int on city fragment (4500 ways, 26000 nodes) and it works correctly.

shop inside building, building inside amenity, building inside landuse works surprizingly fast!

building intersecting highway works, but it is extremely slow (maybe because of slow intersection checking and lot of highways), I'll try to look at the code (maybe it is because I was lazy to optimize something)

[akks]

While debugging the code I noticed that Match objects (IntersectingMatch in my case) are created by SearchCompiler.compile twice for one search:
first in buttonAction: ​http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/actions/search/SearchAction.java?rev=4832#L280
(just to check expression for errors it performs full search...)
then in search function: ​http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/actions/search/SearchAction.java?rev=4832#L569

Is there any meaning in doing the same search twice? It double search time...
I tried to add lazy initialization in Utilsplugin2 (removed init call from constructor), but I am not sure if it was right.

[akks]

I have added adjacent and connected(=recursively adjacent). They select only ways for now (building adjacent building, service adjacent tertiary, etc.). Please check my initialization approach: [o27998].

[joshdoe]

Replying to akks:

I have added adjacent and connected(=recursively adjacent). They select only ways for now (building adjacent building, service adjacent tertiary, etc.). Please check my initialization approach: [o27998].

Looks good, and thanks for adding these. The initialization was misplaced for Inside, so I've fixed that.

[akks]

Replying to joshdoe:

Replying to akks:

I have added adjacent and connected(=recursively adjacent). They select only ways for now (building adjacent building, service adjacent tertiary, etc.). Please check my initialization approach: [o27998].

Looks good, and thanks for adding these. The initialization was misplaced for Inside, so I've fixed that.

Thank you! I had a feeling I missed something simple :-)

Do we need ability to find nodes adjacent or connected to something?

[joshdoe]

Replying to akks:

Do we need ability to find nodes adjacent or connected to something?

Might be useful. I'd say pretty much all of the selection actions should have corresponding search keywords, eventually.

[Zverikk]

I guess this ticket can be marker as fixed?

[akks]

Maybe something of this could go to core... see #7352

[Zverikk]

Ok, I consider this fixed.