-
-
Notifications
You must be signed in to change notification settings - Fork 66
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
Add projection expression syntax (#888) #899
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #899 +/- ##
=======================================
Coverage 92.77% 92.78%
=======================================
Files 105 107 +2
Lines 4678 4739 +61
Branches 1323 1346 +23
=======================================
+ Hits 4340 4397 +57
- Misses 338 342 +4 ☔ View full report in Codecov by Sentry. |
See my additions here: |
It's probably OK for the projection to have it's own type, but I am wondering a bit if it's too close to the StringType - the projection interpolation... it has, after removing the function number(from: number, to: number, t: number): number {
return from + t * (to - from);
}
function projection(from: string, to: string, interpolation: number): Projection {
return new Projection(from, to, interpolation);
}
function color(from: Color, to: Color, t: number, spaceKey: InterpolationColorSpace = 'rgb'): Color {
switch (spaceKey) { We could in principle have a fallback function anyInterpolation<T,U>(from: T, to: U, t: number): [T, U, number]: AnyInterpolation {} And for Projection, where we know the type function string(from: string, to: string, t: number): StringInterpolate {} |
The only problem I really have before merging this is that the |
Ok, if you need anything let me know.
So the question is if to rename |
I think that's a great idea - will get to it. "Projection" is overloaded by the class in geo/projection. |
I'm not sure if theres anything left We could technically replace projectionDefinition type, with an expression compatible string-type. This can be done under the hood later anyway, affecting users just through a change to the url of the relevant documentation page section. Also, i'd prefer to introduce such big change separately, because a new string expression support, could affect all the existing string values. If we land it at some point we can just move projectionDefinition -> "string" / "expressionString". Haven't really thought it to completion, just have intuition there's a win-win kind of thing to get here, by both simplifying the code and bringing generic interpolation support for strings with same api as we have now for projections. |
Maybe the array values in step could make sense to add |
test/integration/expression/tests/step/projection/step-array/test.json
Outdated
Show resolved
Hide resolved
I'm working to move the types to the right place in the folder structure, to make things a bit more organized. Just FYI... |
Thanks, that does sounds great. Are you working on it in a separate cleanup PR, or on this branch? |
Update: Will wrap that up and get back to this |
I had the same observation lately when working with the code, this is needed indeed. Thanks! |
64f5c8c
to
76bfcf0
Compare
I've fixed the tests and addressed the comments I found when reviewing. |
537eb32
to
2eeba43
Compare
It's running fine in GL JS, with this syntax now const exprestInt = createExpression(['interpolate', ['linear'], ['zoom'], 10, 'vertical-perspective', 12, 'mercator'], v8.projection.type) Screen.Recording.2024-11-17.at.12.26.22.movI believe it's ready to go - I can't approve it, since I opened the PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great!
This is a merging branch for
Docs here
https://maplibre.org/maplibre-style-spec/projection/
https://maplibre.org/maplibre-style-spec/types/#projectiondefinition
Launch Checklist
CHANGELOG.md
under the## main
section.