Transform specific projectPoint

[ibesora]

This PR is my first take on fixing #5255
It moves circle-layer specific projection code to each transform to make it transform-aware.
Globe projection is implemented using the view projection matrix, which works as a simple approximation

Before (Notice how the cursor changes to a hand when the underlying feature is detected)

Screen.Recording.2024-12-24.at.18.13.16.mov

After

Screen.Recording.2024-12-24.at.18.11.10__.mov

@kubapelc I'd love if you could take this PR and follow along with a more exact implementation if you have time

Launch Checklist

• Confirm your changes do not include backports from Mapbox projects (unless with compliant license) - if you are not sure about this, please ask!
• Briefly describe the changes in this PR.
• Link to related issues.
• Include before/after visuals or gifs if this PR includes visual changes.
• Write tests for all new functionality.
• Document any changes to public APIs.
• Post benchmark scores.
• Add an entry to CHANGELOG.md under the ## main section.

[codecov]

Codecov Report

Attention: Patch coverage is 37.50000% with 10 lines in your changes missing coverage. Please review.

Project coverage is 91.83%. Comparing base (f967780) to head (bd7cfd2).
Report is 28 commits behind head on main.

Files with missing lines	Patch %	Lines
src/style/style_layer/circle_style_layer.ts	0.00%	5 Missing ⚠️
src/geo/projection/mercator_transform.ts	50.00%	2 Missing ⚠️
...c/geo/projection/vertical_perspective_transform.ts	50.00%	2 Missing ⚠️
src/geo/projection/globe_transform.ts	66.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5267      +/-   ##
==========================================
- Coverage   91.84%   91.83%   -0.01%     
==========================================
  Files         281      281              
  Lines       38856    38864       +8     
  Branches     6793     6795       +2     
==========================================
+ Hits        35686    35690       +4     
- Misses       3043     3046       +3     
- Partials      127      128       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[HarelM]

While this may solve this case, I'm not sure it will solve the cases for other layers.
When I looked into the code, what I found problematic was the following method:

maplibre-gl-js/src/source/query_features.ts

Lines 61 to 70 in 9fc7e73

	function getPixelPosMatrix(transform, tileID) {
	const t = mat4.create();
	mat4.translate(t, t, [1, 1, 0]);
	mat4.scale(t, t, [transform.width * 0.5, transform.height * 0.5, 1]);
	if (transform.calculatePosMatrix) { // Globe: TODO: remove this hack once queryRendererFeatures supports globe properly
	return mat4.multiply(t, t, transform.calculatePosMatrix(tileID.toUnwrapped()));
	} else {
	return t;
	}
	}

It is part of the code path that causes this bug as far as I understand.
The method is not typed so it passes well for transform that has the calculatePosMatrix method, which is basically the mercator transform.
I was hoping that solving this method and adding the relevant posMatrix would solve this.
I'll see if I can create a failing test never the less as it will be helpful regardless of the solution.

[HarelM]

I've tried to test this code with:
'circle-translate': [100, 100] and it doesn't look like this fully solve this.
I'm guessing there's still a need to fine tune the relevant matrices etc, which is very confusing to me to be honest...

[kubapelc]

I'm confused by this doccomment, I think the implementation in vertical_perspective_transform.ts does something different than what this comment states it should do.

[kubapelc]

I've taken a look at the queryFeatures code and this is what I found:

• QueryRenderedFeatures takes an input bounding box in screen space - this is not 100% clear from the doccomments, they could probably be improved.
• getPixelPosMatrix should return a matrix that projects from in-tile coordinates (the 0..8192 coordinates) to screen pixels. This is then used in *_style_layer.ts to project the map features from in-tile coordinates to screen pixels and then intersect that with the query geometry, which is also in screen space.
• The // Globe: TODO: is there because getPixelPosMatrix returns the wrong (but still somewhat usable) matrix when globe is active. The required transformation cannot be described by a matrix for globe anyway. I think if (transform.calculatePosMatrix) was intended to determine whether mercator transform is active.
• I'm pretty sure that the globe implementation of getCameraQueryGeometry is wrong, I think I just used the mercator code, since it seemed to work well enough. QueryRenderedFeatures is one of the things I didn't take care to make sure it works 100% correctly.

The main problem is that the projection from tile coordinates to screen pixels cannot be described by a matrix when globe projection is active, so all the queryFeatures-related code needs to be changed to get correct results.

[kubapelc]

I think that instead of correctly projecting all features to screen space for globe, a better appoach would be to project the query geometry to mercator coordinates or tile space and approximate it with some polygon (since it will get curved by the projection), and then query features against that. The reason is that projecting from tile space to globe is slower than projecting from tile space to mercator coordinates, so we want to prefer the other projection where possible, and bulk of the projecting will be done for the features.

[HarelM]

The question is about all kind of transformation related to screen space like circle radius, circle offset, the padding that is used in pixels, all of those are in screen space so there is a conversation back and forth.
These are defined in the style.json and most of them are in pixels.

I added some comments recently to help understand in which domain the coordinates are, but it's confusing.
Can we use a method instead of a matrix to do the transformations or will this be too slow?