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

queryRenderedFeatures should return world-wrapped longitudes #3688

Closed
peterqliu opened this issue Nov 23, 2016 · 2 comments
Closed

queryRenderedFeatures should return world-wrapped longitudes #3688

peterqliu opened this issue Nov 23, 2016 · 2 comments

Comments

@peterqliu
Copy link
Contributor

peterqliu commented Nov 23, 2016

Scenario

I'm rendering a bunch of point data as circles, and would like to generate a popup when hovering or clicking them. This is done by retrieving the lnglat of the point, and setting the popup there.

A snag

When I interact with features more than a world-wrap away (when Math.abs(longitude)>180), the popup doesn't show up anymore. Or rather, it gets projected to the un-worldwrapped location (-180<longitude<180). This is because queryRenderedFeatures returns the same longitude coordinates for the same feature, no matter how many worldwraps away I go.

A proposal

Return world-wrapped longitudes with qRF queries. This also makes it consistent with current project/unproject behavior.

@mcwhittemore
Copy link
Contributor

@peterqliu - just to make sure I'm understanding this request correctly.

Currently queryRenderedFeatures returns [0,0] for null island for world left, center and right.

Where the west world extends from -540 to -180 lng, the center world extends from -180 to 180 and the east world extends from 180 to 540.

But you'd like to see queryRenderedFeatures return

  • [-360,0] for the west world
  • [0,0] for the center world
  • [360,0] for the east world

@jfirebaugh
Copy link
Contributor

We discussed this and other edge cases (bounding box that spans more than one world) when implementing queryRenderedFeatures, and decided on the current behavior. Instead of revisiting that, I think we need to fix #2071.

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

No branches or pull requests

3 participants