add LocationIndexTree.query(BBox)

[karussell]

This PR adds a new query(BBox) method. Currently we can fetch only nodes from one leaf and so with this querying areas is inefficient. Related to #1127 and #1324.

Furthermore a possibility to visualize the index

and some description for the index is added. The description now makes clear that we have a Quadtree implementation with some special tuning. E.g. for bigger areas one node branches not only into 4 subtrees but can branch into 16. Previously also 64 was possible, but we removed this as this has no advantages in terms of storage, query or creation speed. (Measured it for Germany and world wide)

TODOs:

• to make this correct we need to add +1/2 cell on every side of the BBox. The problem is that we do not add the node to both cells due to the bresenham line to cell limitation Does not seem to be necessary (no problems e.g. in Render vector tiles from graph storage /mvt #1572).
• make it working with Polygon too (use JTS Polygon e.g. via embedding in ours so that we can implement Shape)
• use PrepareGeometry -> use PrepareGeometry in QueryGraph.query and Weighting using a Polygon #1589
• use intersect and contains!
• use quality vs. speed properties like UNIQUE_NODES (just make sure nodes come to the Visitor just once), FILTERED_NODES (unique nodes plus filtered again through the shape), HIGH_PRECISION (filtered node but use fetchGeometry instead of just junction nodes)

[karussell]

Will make it possible via a SimpleVisitor class or something. Often this iteration has to be done again on the client side e.g. to fetch the edges and so this work would be an unnecessary overhead then.

[michaz]

Nice, this closes some open ends for me. Is the current state mergeable, meaning, do we think that the bounding-box query does more or less what it should? Because I'd like to.

[karussell]

Well, this is not fully ready unfortunately. Currently all nodes are returned where the tile intersects with the shape. This is ok for visualisation, but for other use cases we have to filter these nodes and call "shape.contains(node)" as a post processing step. Now the problem is that this could be done cheap like this or in a more expensive manner if we need high precision via "shape.intersects(edge.fetchWayGeometry)". Currently exploring the options on how to do this so that this also works for a Polygon (which basically means using JTS Polygon behind our Polygon class). But we could also bring it into a mergable state faster and I'll create a new issue for the open tasks.

[michaz]

Oh, that's exactly what I need: "May include more nodes than are contained, but never fails to return return a node that is contained". I think that's also how other implementations work.

[karussell]

Oh, that's exactly what I need: "May include more nodes than are contained, but never fails to return return a node that is contained". I think that's also how other implementations work.

Ah, ok. I think there are indeed two use cases. This one, which you need and we need for fast visualization. But also the other to e.g. block certain edges but not too many!

Maybe I'll bring this PR in a mergable form for the first use case and explicitly mention this and work later on the second "high precision" use case?

[michaz]

Maybe I'll bring this PR in a mergable form for the first use case and explicitly mention this and work later on the second "high precision" use case?

Yes, please! For me, this doesn't even mean that this is currently unfinished -- filtering the result to the desired level of exclusivity is a second task, and can happen outside of the current method. This one is finished.

[michaz]

And this method can still narrow down what it returns later on without changing its promise.

[karussell]

filtering the result to the desired level of exclusivity is a second task

This is exactly where I'm unsure because the method index.query(shape) could also imply that this should be an exact filter and no post-processing work needs to be done.

[michaz]

Well, "query" as a method name is vague enough that I think it can't be misunderstood as promising anything specific. ;-)

Let's add a Javadoc which explains what this method does and does not (not how it does that), and it'll be fine.

[karussell]

Ok :D

Will do this ... let me just do some minor stuff.

[karussell]

I did the following changes (let me know if this was too much):

• moved the Visitor interfaces and the query method to the LocationIndex interface
• removed the extra visualize method and made it possible via the Visitor setting isTileInfo (now Visitor has to be an abtract class as default methods are not possible in 7). onTile now directly includes the depth not the too-visualization-specific width.
• avoid duplicate nodes (and edges for the EdgeVisitor)
• introduced a new "queryBBox.contains" branch to avoid bbox checks on greater depths, should make the query slightly faster
• renamed Shape.intersect to intersects, also to make later migrations to JTS easier
• renamed *cell* to *tile*
• made some methods non-public

[michaz]

Just as a small remark: This Visitor is not very Java-8-friendly (see my call of the new query method in the commit I added - I can't do a lambda there, because the visitor is not a single-method interface but a multi-method abstract class), and also a bit unusual. If I understand it correctly, as a client, I have to override isTileInfo if I want onTile to be called? I think interfaces are most clear when control flows in one direction only: An interface is either for me to call, or for me to implement and be called.

[michaz]

An interface is either for me to call, or for me to implement and be called.

Okay, that's actually the case here. :-) But the information flows both ways.

[karussell]

Yes, I tried with a separate QueryOptions class but this was not much prettier. Should I revert it back to this to make it easier with lambda?

[michaz]

Ah no, it's okay.

[michaz]

Thanks! I'm doing more Isochrone experiments with this right now... ,-)