-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
expose mercator projection for custom layers #7485
Comments
I listed way too many possibilities. I think it's worth reading through them but overall I'm leaning towards 3Gish combined with 1A and 2A: class MercatorCoordinate {
constructor(x: number, y: number, z: number) {
this.x = x;
this.y = y;
this.z = z;
}
// alternatively called project
static fromLngLat(lngLat: LngLat, altitudeMeters?: number) : MercatorCoordinate { ... }
// alternatively called unproject
toLngLat() : LngLat { ... }
// alternatively called unprojectAltitude
toAltitude() : number { ... }
} |
@ansis the For cases where the transform matrix and coordinates are begin fed to GL shaders directly, might it be faster to convert the LngLats to Mercator in the shader? Its probably not the answer for this ticket, but I thought I'd share a snippet that I have used with gl-native: vec2 p_pos;
p_pos.x = 180.0 + a_pos.x;
p_pos.y = 180.0 - degrees(log(tan(3.141592653589793/4.0 + 0.5 * radians(a_pos.y))));
float scale = pow(2.0, u_zoom) * 512.0 / 360.0;
vec2 x_pos = p_pos * scale;
gl_Position = u_matrix * vec4(x_pos, 0, 1); |
These helper methods would be great and make it much easier to build with CustomLayers 👍 I left a comment on the PR at #7488 (comment) about if we should be more explicit that this |
Motivation
The matrix we give custom layers expects "mercator coordinates" as input. We provide no way of converting LngLat to mercator coordinates. We have this projection implemented internally but we don't expose this to users. Exposing it is mainly a design question.
If we can settle on a design I think we could sneak this into the next release.
@mourner can you help pick a design for this?
Relevant comments and workarounds:
Design Alternatives
I'm splitting this into two parts: a type for mercator coordinates and the methods used to convert.
Coordinate type
projection method signature
Mercator coordinates are three dimensional. Should we support projecting and unprojecting features with altitude. How?
projection method location
Design
I'm not sure which is better. @mourner I need your design expertise.
I'm slightly leaning towards 1B over 1A because it makes the typing specific in user code but I could definitely be swayed towards 1A if someone has a strong preference for that.
I kind of like the design adding
altitude
toLngLat
but that might be a big change that we want to spend more time considering. For example, is the altitude the altitude above the surface? or above the wgs84 spheroid? how does this work for flat maps? how would this work if we added 3d terrain?2A
is nice because it sidesteps these questions but it is not as nice.For part 3, I think it's good to be able to use this without an instantiated map. I think I like
3G
because it provides separation and keeps the projection close to the type. I like3D
because it namespaces the methods, allows for future expansion to 3E-like things. I like 3A and 3B because they are simple.Concepts
Documentation for the mercator type will explain the coordinate space. Documentation for custom layers will reference these methods. Custom layer examples will be switched to use this projection.
Implementation
Factoring
worldSize
out of here and exposing it. And adding tests and documentation.The text was updated successfully, but these errors were encountered: