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.

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.

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

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?

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 asecond task, and can happen outside of the current method. This one is finished.

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

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

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

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 (nothow it does that), and it'll be fine.

Ok :D

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

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-specificwidth.
• 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