When radius=0 (default) do we validate the tile and query point intersect? about vtquery HOT 10 CLOSED

Good questions. The pure "Point in Polygon" usecase (radius=0) is an important one and I think can be accommodated fairly cleanly using the same interface as "Nearby features" (radius>=0) searches.

My feeling is that:

• Yes, if radius=0 it is safe to assume only one tile buffer will be passed and therefore we could throw if not (since that would be programmer error)
• Also, if the bbox of the buffer's z/x/y does not intersect with the query point we could also throw - that would be programmer error again, right?

Then we'd want to keep on eye, during later performance profiling, that this validation is not showing up > 1% in the callgraph. I don't presume it would and I'm not worried about any meaningful perf penalty of this validation, but it would be good to confirm.

Other performance question to consider:

• If radius=0 is there meaningful overhead in using closest_point? Could @artemp provide a faster PIP solution when radius=0? Would it be contains, within, covers? Or, do the usecases downstream always expect to know the closest point on a polygon boundary even when radius=0?

from vtquery.

Yes, if radius=0 it is safe to assume only one tile buffer will be passed and therefore we could throw if not (since that would be programmer error)

Already throwing if there are no buffers, so this case is covered.

Also, if the bbox of the buffer's z/x/y does not intersect with the query point we could also throw - that would be programmer error again, right?

Since we're working with a relative query point (something that can be positive or negative tile coordinates from the current tile buffer, we could add a check that says "if radius is 0 and the query point is > the tile's extent" throw since this will return zero results anyways.

if (radius == 0 && 
    (query_point.x > tile.extent() || 
     query_point.y > tile.extent() || 
     query_point.x < 0 || 
     query_point.y < 0)
) {
  // return callback error
}

from vtquery.

We're already have fast tracking return path for when point is within polygon:

https://github.com/mapbox/spatial-algorithms/blob/53d7861dc0ecca66ecbbae8fcef6b231ddbb2752/include/mapbox/geometry/algorithms/closest_point_impl.hpp#L36-L39

/cc @springmeyer @mapsam

from vtquery.

"if radius is 0 and the query point is > the tile's extent" throw since this will return zero results anyways.

👍 on this check. Although without this check throwing would it potentially return results in the case that the tiles have buffered data outside the extent?

from vtquery.

We're already have fast tracking return path for when point is within polygon:
https://github.com/mapbox/spatial-algorithms/blob/53d7861dc0ecca66ecbbae8fcef6b231ddbb2752/include/mapbox/geometry/algorithms/closest_point_impl.hpp#L36-L39

Brilliant, thanks for already thinking of that @artemp :)

from vtquery.

@springmeyer another question here:

"If radius is 0, should we only default to decoding polygons?"

Since we're only looking for PIP at this point, perhaps would speed things up?

from vtquery.

Good question @mapsam 🤔 . I noticed our current docs https://www.mapbox.com/api-documentation/#retrieve-features-from-vector-tiles say:

The radius parameter has no upper bound and is required for queries against point and line data.

So it sounds like radius=0 is understood to mean only polygons currently. Though technically I think in node-mapnik it could still return points and lines if you are exact. So, I think making radius=0 actually only try to query polygons would be ideal: both from a performance perspective and from a clear usability perspective (so you don't get surprised with points and lines in rare cases).

from vtquery.

I agree @springmeyer 👍 - plus the "direct" hit will never be fully accurate, considering a vector tile's coordinates are already simplified. Returning a point/polyline hit could be misleading in that way.

from vtquery.

Good point @mapsam - that the likelyhood of also returning a direct hit for lines/points increases to the extent that the precision is lost. So, yeah, that is another 👍 to only worrying about polygons and maybe in a far off future, supporting returning polygons with radius=0 that are "almost" hit (though we'd need to test that extensively to ensure it is actually needed).

from vtquery.

Radius=0 is only polygons, and we are only using a "within" operation and not an "along" operation. Closing!

from vtquery.