Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

radius=0 leads to zero results with PIP #36

Closed
mapsam opened this issue Oct 31, 2017 · 2 comments · Fixed by #42
Closed

radius=0 leads to zero results with PIP #36

mapsam opened this issue Oct 31, 2017 · 2 comments · Fixed by #42

Comments

@mapsam
Copy link
Contributor

mapsam commented Oct 31, 2017

When radius is 0, we expect point in polygon style results (ie 1 result if we’re within a single polygon). Right now we get zero results since the query point is a double (lng lat) but by the time we’re comparing the distance from closest_point we’re in integers, which then get converted to a lng lat and can be different than the original query point since it’s an interpolation. This means the distance check looks something like if (0.00011241241 <= 0) { ... } which evaluates to false.

Three possible solutions:

  1. We’ll want to use something other than closest_point for PIP (radius=0) operations
  2. Do all calculations in doubles instead of ints
  3. Instead of using zero (if radius is zero) we use some sort of very small number like if (0.0000234 < 0.5) to catch these instances

cc @flippmoke

@mapsam
Copy link
Contributor Author

mapsam commented Nov 1, 2017

Per chat with @flippmoke we've got a relatively solid solution for this problem. Basically, closest_point won't work for point in polygon use-cases if we work in integer space. In the name of cleanliness and performance, point-in-polygon should probably be a different code path or method entirely. Before we split them apart, here's the route I'll go down:

  • radius > 0: stick with current case as-is () then we treat it as closest_point algorithm in ints (or doubles) and try to find the distance in ints (or doubles) with what we have.
  • radius = 0: run down a different code path with either intersects/within (via spatial-algorithms), and start thinking about these two use-cases as separate methods in vtquery.

Once we get this working, splitting the code paths out into two methods could be helpful, giving the implementers (JS devs) opportunity to use two different methods depending on their needs. For example:

// current radius-based query
vtquery.closest(tiles, ll, options, cb);

// point in polygon method 
// (since the implement will know if they are working with radius=0)
// probably work within doubles space and only worry about polygons
vtquery.within(tile, ll, options, cb); 

// OR - if we are dealing with integer space and want to 
// return points/polylines as possible features
vtquery.intersects(tile, ll, options, cb);

@mapsam
Copy link
Contributor Author

mapsam commented Nov 27, 2017

Radius 0 is now part of #42 . We are using the internal mechanism of closest_point to verify the value is 0.0 (and not less than 0.0).

@mapsam mapsam closed this as completed Nov 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant