Modify

Opened 9 years ago

Closed 6 years ago

#5905 closed enhancement (fixed)

Topological search/filter

Reported by: Zverikk Owned by: team
Priority: normal Milestone:
Component: Plugin utilsplugin2 Version: latest
Keywords: search Cc: joshdoe, Zverikk

Description

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.

Attachments (0)

Change History (20)

comment:1 Changed 9 years ago by 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?

comment:2 Changed 9 years ago by joshdoe

Cc: joshdoe Zverikk added

comment:3 Changed 9 years ago by 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.

comment:4 in reply to:  1 ; Changed 9 years ago by 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.

comment:5 in reply to:  4 Changed 9 years ago by 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. :-)

comment:6 Changed 9 years ago by 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.

Last edited 9 years ago by akks (previous) (diff)

comment:7 Changed 9 years ago by 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.

comment:8 Changed 8 years ago by joshdoe

Component: CorePlugin utilsplugin2
Keywords: search added

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?

comment:9 Changed 8 years ago by 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.

Last edited 8 years ago by akks (previous) (diff)

comment:10 Changed 8 years ago by akks

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

comment:11 in reply to:  10 Changed 8 years ago by 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.

comment:12 Changed 8 years ago by 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)

Last edited 8 years ago by akks (previous) (diff)

comment:13 Changed 8 years ago by 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.

comment:14 Changed 8 years ago by 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].

comment:15 in reply to:  14 ; Changed 8 years ago by 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.

comment:16 in reply to:  15 ; Changed 8 years ago by 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?

comment:17 in reply to:  16 Changed 8 years ago by 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.

comment:18 Changed 7 years ago by Zverikk

I guess this ticket can be marker as fixed?

comment:19 Changed 7 years ago by akks

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

comment:20 Changed 6 years ago by Zverikk

Resolution: fixed
Status: newclosed

Ok, I consider this fixed.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.