How to project coordinates with a custom projection (ECEF for example)?

[J-Rojas]

Is it possible to project Geodetic coordinates for tile geometry with something other than planar and spherical projects? Can I write a custom projection and apply it to the MapView?

[nzjony]

hi @J-Rojas , yeah you can. I once did a planar cylindrical projection for a custom baton I made in a relay race, or take a look at https://github.com/heremaps/harp.gl/blob/master/@here/harp-geoutils/lib/projection/TransverseMercatorProjection.ts for a non convential projection.

What do you mean by:

with something other than planar and spherical projects?

Do you have some other 3d shape (other than planar / spherical) in mind?

We use the type of the projection to compute for example the correct far plane, which is different depending on the type, so if you wanted to project to a cube for example, some internal parts may not work.

[J-Rojas]

Okay that's great @nzjony - I did notice that a custom projection class can be provided but also noticed there are hard coded projection tests internally in various places so I was wondering how flexible this system would be. So my results might vary depending on how different the projection is from one of the two core projection types (planar, spherical).

[J-Rojas]

@nzjony Is there any plan to refactor the internal projection logic to allow for completely customized projections?

[nzjony]

Okay that's great @nzjony - I did notice that a custom projection class can be provided but also noticed there are hard coded projection tests internally in various places so I was wondering how flexible this system would be. So my results might vary depending on how different the projection is from one of the two core projection types (planar, spherical).

Are you referring to: https://github.com/heremaps/harp.gl/blob/master/@here/harp-geoutils/test/ProjectionTest.ts ? This tests specific concrete implementations, mercator / webMercator, so if you create a new projection subclass, it won't break anything.

@nzjony Is there any plan to refactor the internal projection logic to allow for completely customized projections?

I don't follow sorry, you can extend Projection and customize the projection as you like. Apart from the type, the MapView doesn't care about which implementation you use. Or did I miss something?

[J-Rojas]

@nzjony I'm referring to the use of the ProjectionType.Planar or ProjectionType.Spherical throughout the code base. Certain functionality like MapControls depend on the projection being one of these two types. So if my new projection is Elliptical, I could write a new Projection class however it would most likely need to assign it the Spherical projection type to make sure it compatible with these hardcoded paths in the code base.

[nzjony]

@J-Rojas , thanks for clarifying.

Yes, that could work, but we would need to see what issues we get.

You would get an issue at least with the far plane calculation, because it uses a sphere to compute the visible tiles, and maybe with an Elliptical projection, there are some cases where there are missing tiles at the horizon because the far plane is too aggressive. I didn't write the MapControls, but maybe there would be some issues there too.

I will create an internal ticket that we should remove some of the logic depending on the type into either the projection itself or at least document what assumptions we are making.

TheProjectionType.Spherical type is actually misleading, because we internally assume it is a sphere, maybe we can rename this to make it clearer for others.

[nzjony]

@J-Rojas, I went through the code and looked at places where we would need to make some modifications to support an Ellipsoid projection:

Have been looking through the code, and I have the following comments:

Fixes required:

• VectorTileDataEmitter.ts, needs to know the type to subdivide the geometry to fit on the globe. Should be easy to do this also for Ellipsoid, just the projection would need to be passed to EdgeLengthGeometrySubdivisionModifier class.
• SphericalGeometrySubdivisionModifier.ts should accept either the Ellipsoid or Sphere projection. Maybe change the base class SubdivisionModifier.
• Placement.ts needs to know the projection type for checkViewDistance to filter labels near the horizon. Maybe the spherical type is acceptable?
• TileGeometryCreator::createGroundPlane needs to be subdivided for spherical types. Should be just a matter of providing the Ellipsoid projection into the SphericalGeometrySubdivisionModifier class.
• VisibleTileSet::skipOverlappedTiles would need to also check for Ellipsoid
• Utils::extractCameraTilt should also work and need minimal tweaks, the function extractTiltAngleFromLocation already uses the local tangent space, so this should just work.
• Utils::rotate needs to be tweaked to calculate the correct maxPitch.
• Utils::getFitBoundsLookAtParams, Utils::getCameraPositionFromTargetCoordinates needs to also work with Ellipsoid.
• Utils::zoomOnTargetPosition needs to have a method to pan on Ellipsoid (maybe the sphere implementation is satisfactory)
• SkyGradientTexture.ts would need to look for Ellipsoid, to construct the CubeTexture correctly. Should just be a matter of providing the correct scale to squash the sphere.
• MapView::getWorldPositionAt needs Ray <-> Ellipsoid intersection for computing the correct world position.
• MapView::setCameraGeolocationAndZoom limits tilt based on sphere.
• MapView::updatePolarDataSource also need to accept Ellipsoid type. The PolarDataSource also needs to be tested.
• MapView::createVisibleTileSet should set this.enableMixedLod to true if type is Ellipsoid. This would also need to be tested to make sure it works as well.
• MapView::tileWrappingEnabled would need to disable it for Ellipsoid also.
• MapView::updateLights, would need to return when projection is Ellipsoid, until shadows on globe are implemented.
• MapViewAtmosphere would also need to be updated to accept an Ellipsoid, for example, it creates a new THREE.SphereGeometry which would need to be correctly squashed using a scale matrix.
• MapViewUtils.rotate has to consider the max rotation allowed, this would be different for Ellipsoid.
• FrustumIntersections::compute has to use OBB for Ellipsoid also.
• ClipPlanesEvaluator.ts has many functions that work with just Sphere, these would need to be ported for Ellipsoid.
• BoundsGenerator.ts needs to work for Sphere.
• MapControls.ts needs to implement panning for Ellipsoid.

Ideas:

• Move the clip plane evaluators to some example, but not in the code, keep however the fixed one. These have multiple checks

So yes, there would be quite a bit of work to do to support such a projection. I would say it would be, as a very rough estimate 3 - 4 person months of work.

[J-Rojas]

That's good to know. I figured it would be a difficult task. I'm relying on workarounds at the moment to minimize error in my underlying data and the visualized results.

On Thu, Oct 15, 2020, 5:49 AM Jonathan Stichbury notifications@github.com wrote:

@J-Rojas https://github.com/J-Rojas, I went through the code and looked at places where we would need to make some modifications to support an Ellipsoid projection:

Have been looking through the code, and I have the following comments:

Fixes required:

• VectorTileDataEmitter.ts, needs to know the type to subdivide the geometry to fit on the globe. Should be easy to do this also for Ellipsoid, just the projection would need to be passed to EdgeLengthGeometrySubdivisionModifier class.
• SphericalGeometrySubdivisionModifier.ts should accept either the Ellipsoid or Sphere projection. Maybe change the base class SubdivisionModifier.
• Placement.ts needs to know the projection type for checkViewDistance to filter labels near the horizon. Maybe the spherical type is acceptable?
• TileGeometryCreator::createGroundPlane needs to be subdivided for spherical types. Should be just a matter of providing the Ellipsoid projection into the SphericalGeometrySubdivisionModifier class.
• VisibleTileSet::skipOverlappedTiles would need to also check for Ellipsoid
• Utils::extractCameraTilt should also work and need minimal tweaks, the function extractTiltAngleFromLocation already uses the local tangent space, so this should just work.
• Utils::rotate needs to be tweaked to calculate the correct maxPitch.
• Utils::getFitBoundsLookAtParams, Utils::getCameraPositionFromTargetCoordinates needs to also work with Ellipsoid.
• Utils::zoomOnTargetPosition needs to have a method to pan on Ellipsoid (maybe the sphere implementation is satisfactory)
• SkyGradientTexture.ts would need to look for Ellipsoid, to construct the CubeTexture correctly. Should just be a matter of providing the correct scale to squash the sphere.
• MapView::getWorldPositionAt needs Ray <-> Ellipsoid intersection for computing the correct world position.
• MapView::setCameraGeolocationAndZoom limits tilt based on sphere.
• MapView::updatePolarDataSource also need to accept Ellipsoid type. The PolarDataSource also needs to be tested.
• MapView::createVisibleTileSet should set this.enableMixedLod to true if type is Ellipsoid. This would also need to be tested to make sure it works as well.
• MapView::tileWrappingEnabled would need to disable it for Ellipsoid also.
• MapView::updateLights, would need to return when projection is Ellipsoid, until shadows on globe are implemented.
• MapViewAtmosphere would also need to be updated to accept an Ellipsoid, for example, it creates a new THREE.SphereGeometry which would need to be correctly squashed using a scale matrix.
• MapViewUtils.rotate has to consider the max rotation allowed, this would be different for Ellipsoid.
• FrustumIntersections::compute has to use OBB for Ellipsoid also.
• ClipPlanesEvaluator.ts has many functions that work with just Sphere, these would need to be ported for Ellipsoid.
• BoundsGenerator.ts needs to work for Sphere.
• MapControls.ts needs to implement panning for Ellipsoid.

Ideas:

• Rename ProjectionType.Spherical -> ProjectionType.Sphere, clear that this works only for a given sphere. "Spherical" is inaccurate, because
• Move the clip plane evaluators to some example, but not in the code, keep however the fixed one. These have multiple checks

So yes, there would be quite a bit of work to do to support such a projection. I would say it would be, as a very rough estimate 3 - 4 person months of work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/heremaps/harp.gl/issues/1872#issuecomment-709300180, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANFYNEV63XRTGVAVZKRGL3SK3VXHANCNFSM4RYN3JXQ .

[nzjony]

@J-Rojas , ok, good to know, if you get stuck or want some more help reach out.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.