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

Match GlobeView projection parameters with Maplibre v5 #9201

Open
wants to merge 3 commits into
base: x/globe-test-app
Choose a base branch
from

Conversation

Pessimistress
Copy link
Collaborator

For #9199

globe

Grid lines are rendered by Maplibre, points are rendered by deck.gl.

Change List

  • Match GlobeViewport's scale, nearZ, farZ with maplibre's GlobeTransform
  • GlobeView switch to WebMercatorViewport at zoom>=12. maplibre performs interpolation between the two projections at z [11, 12]. We may need to do the same, but the difference is honestly very subtle.
  • Some golden images are updated because the zoom -> scale mapping has changed. The new implementation uses an adaptive scale that depends on the latitude of the viewport center.

Copy link
Collaborator

@felixpalmer felixpalmer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks promising, but I get the page freezing after playing with the controls when viewing the full globe

@@ -9,6 +9,9 @@ import {MapState, MapStateProps} from './map-controller';
import {mod} from '../utils/math-utils';
import LinearInterpolator from '../transitions/linear-interpolator';

// matches Web Mercator projection limit
const MAX_VALID_LATITUDE = 85.051129;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if math.gl shouldn't export this - it is used in a number of places

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 - we have a web-mercator module after all, and this is one of the primary web-mercator constants.

@@ -9,6 +9,9 @@ import {MapState, MapStateProps} from './map-controller';
import {mod} from '../utils/math-utils';
import LinearInterpolator from '../transitions/linear-interpolator';

// matches Web Mercator projection limit
const MAX_VALID_LATITUDE = 85.051129;

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm seeing strange things when moving near the poles

Screen.Recording.2024-10-04.at.10.40.03.mov


constructor(opts: GlobeViewportOptions = {}) {
const {
latitude = 0,
longitude = 0,
zoom = 0,
nearZMultiplier = 0.1,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you document somewhere how you updated these defaults? Is there some magic formula?

@@ -275,7 +275,7 @@ const TEST_CASES = [
viewState: {
longitude: -6,
latitude: 58,
zoom: 1.5
zoom: 1.5 + 0.7353406094252244 // Math.log2(1 / Math.PI / Math.cos(58 / 180 * Math.PI))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel it is better to update the image than having some weird constant here. There is a significant change in output anyway

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this constant help see us abnormalities in the images, or have some other benefit for testing?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice if comment explained what the formula is doing in a few words.

fovy = altitudeToFovy(altitude);
}
// Used to match globe and web mercator projection at high zoom
const scaleAdjust = 1 / Math.PI / Math.cos((latitude * Math.PI) / 180);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth guarding against division by 0? Despite this, the viewport could still be manually constructed with the pole value

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have had a LOT of problems over the years in deck and kepler with mercator viewports throwing due to bad inputs somehow being generated - every time it arises, it confuses a couple of new engineers and PMs, tickets get created, discussions in sprint reviews etc - ultimately hours of time are lost and little is done.

So I agree that avoiding the issue would be great. The question is what to do instead. Force the value to the closest value that will work?

zoom: 0,
pitch: 0,
bearing: 0
zoom: -1
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's a negative zoom mean for globe?

@@ -50,6 +51,8 @@ export type GlobeViewportOptions = {
zoom?: number;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth adding a comment about zoom's range in a globe view?

Copy link
Collaborator

@ibgreen ibgreen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks quite clean, I don't see any immediate reason why we wouldn't want to merge this as experimental in 9.1.

@@ -9,6 +9,9 @@ import {MapState, MapStateProps} from './map-controller';
import {mod} from '../utils/math-utils';
import LinearInterpolator from '../transitions/linear-interpolator';

// matches Web Mercator projection limit
const MAX_VALID_LATITUDE = 85.051129;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 - we have a web-mercator module after all, and this is one of the primary web-mercator constants.

@@ -20,7 +23,7 @@ class GlobeState extends MapState {
if (longitude < -180 || longitude > 180) {
props.longitude = mod(longitude + 180, 360) - 180;
}
props.latitude = clamp(latitude, -89, 89);
props.latitude = clamp(latitude, -MAX_VALID_LATITUDE, MAX_VALID_LATITUDE);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we go all the way? or do we need some offset to avoid issues?

resolution = 10
} = opts;

let {height, altitude = 1.5} = opts;
let {height, altitude = 1.5, fovy} = opts;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: FWIW, I have consistently been adding a defaultOptions object to classes in luma.gl so that I can document all default options in one place rather than spreading out the default values in a bunch of descructuring calls like this.

static defaultOptions: Required<GlobeViewportOptions> = {
 ...
};
this.options ={...GlobeViewport.defaultOptions, ...options};

fovy = altitudeToFovy(altitude);
}
// Used to match globe and web mercator projection at high zoom
const scaleAdjust = 1 / Math.PI / Math.cos((latitude * Math.PI) / 180);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have had a LOT of problems over the years in deck and kepler with mercator viewports throwing due to bad inputs somehow being generated - every time it arises, it confuses a couple of new engineers and PMs, tickets get created, discussions in sprint reviews etc - ultimately hours of time are lost and little is done.

So I agree that avoiding the issue would be great. The question is what to do instead. Force the value to the closest value that will work?

@@ -37,8 +38,8 @@ export default class GlobeView extends View<GlobeViewState, GlobeViewProps> {
super(props);
}

get ViewportType() {
return GlobeViewport;
getViewportType(viewState: GlobeViewState) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Nit: It just seems a bit weird that one of these takes an argument and the others do not. Should we allow it to be omitted?
  • Not sure if making the types less restrictive could be useful? - i.e. only ask for what we need to answer the question
Suggested change
getViewportType(viewState: GlobeViewState) {
getViewportType(viewState: {zoom: number}) {

@@ -275,7 +275,7 @@ const TEST_CASES = [
viewState: {
longitude: -6,
latitude: 58,
zoom: 1.5
zoom: 1.5 + 0.7353406094252244 // Math.log2(1 / Math.PI / Math.cos(58 / 180 * Math.PI))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice if comment explained what the formula is doing in a few words.


height = height || 1;
altitude = Math.max(0.75, altitude);
if (fovy) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This aligns us more with other views, right?
We always support fovy and altitude is a backup for geospatial views?

fovy = altitudeToFovy(altitude);
}
// Used to match globe and web mercator projection at high zoom
const scaleAdjust = 1 / Math.PI / Math.cos((latitude * Math.PI) / 180);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the new math logic? Almost missed it. Not sure we can put this in a separate method or something to make it stand out mode?
Commenting generously here would be appreciated.

Copy link
Collaborator

@felixpalmer felixpalmer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Pessimistress I believe the page freeze is unrelated to this PR #9265

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 this pull request may close these issues.

4 participants