-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
WebMercator Tiling for CesiumTerrainProvider #8563
WebMercator Tiling for CesiumTerrainProvider #8563
Conversation
…heme based on key in layer.json
Thank you so much for the pull request @jtfell! I noticed this is your first pull request and I wanted to say welcome to the Cesium community! The Pull Request Guidelines is a handy reference for making sure your PR gets accepted quickly, so make sure to skim that.
Reviewers, don't forget to make sure that:
|
Issue on quantized-mesh spec: CesiumGS/quantized-mesh#10 |
Signed CLA. |
Thanks for the contribution @jtfell ! I can confirm we have your CLA. |
@kring can you review this? |
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.
Thanks for the PR @jtfell! This looks good to me, I'd just like to see a couple of minor changes for consistency. Would you mind merging in master while you're at it as well?
Source/Core/CesiumTerrainProvider.js
Outdated
@@ -198,6 +192,31 @@ import TileProviderError from './TileProviderError.js'; | |||
var maxZoom = data.maxzoom; | |||
overallMaxZoom = Math.max(overallMaxZoom, maxZoom); | |||
// Keeps track of which of the availablity containing tiles have been loaded | |||
|
|||
if (!data.tilingScheme || data.tilingScheme === 'GlobalGeodetic') { |
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.
Rather than add a new property, we should use the projection
property already found in the layer.json. WebMercatorTilingScheme
should be specified with "EPSG:3857"
.
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.
Ok that sounds good, should it default to the existing behaviour in all other cases?
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.
I think the general logic you have here is good. If it's EPSG:3857, do web mercator. If it's undefined or EPSG:4326, do geographic. If it's something else, complain.
Source/Core/CesiumTerrainProvider.js
Outdated
var yTiles = provider._tilingScheme.getNumberOfYTilesAtLevel(level); | ||
|
||
var tmsY = (yTiles - y - 1); | ||
if (provider._tilingScheme instanceof GeographicTilingScheme) { |
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.
Quantized mesh tile URL Y coordinates should always be numbered from the South and increasing toward the North, TMS-style. It's confusing for this to change based on the projection.
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.
While we're at it, we can make this configurable separately right? Maybe when the scheme
key is set to tms
it counts from the south, and counts from the north otherwise. Or to avoid breaking existing uses, a new slippy
value for scheme triggers counting from the north.
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.
That's ok with me if you have a use case and as long as it doesn't add too much complexity to the URL generation (it shouldn't be too bad).
Also, I do think this is a useful addition to the spec, so I'd be happy to merge a PR there, too. Thanks! |
Thanks for the feedback @kring! I will create a PR for the spec after we have decided on what to do with the |
…l/cesium into web-mercator-terrain-tiling-scheme
@jtfell your changes look good, but there seems to be a problem when using Cesium World Terrain and zooming in slightly: It's not immediately obvious to me how your changes caused this, but I can't reproduce it in master so I think it must be a new problem in this PR. Any ideas? |
Oh I think the problem is that Don't ask me why CesiumJS and Cesium World Terrain use different tile numbering, even though it's totally my fault that they do. 😆 |
The behaviour for |
Source/Core/CesiumTerrainProvider.js
Outdated
// The TileMapService scheme counts from the bottom left | ||
if (!provider._scheme || provider._scheme === 'tms') { | ||
var yTiles = provider._tilingScheme.getNumberOfYTilesAtLevel(level); | ||
y = (yTiles - y - 1); |
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.
This is the cause of the bug. Previously the y coordinate as left unchanged in the TMS case, so createQuantizedMeshTerrainData
was given Cesium coordinates (0=North) rather than TMS coordinates (0=South). After your change, createQuantizedMeshTerrainData
is given TMS coordinates for TMS terrain, causing things to break.
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.
Ah I see, that makes sense. I've pushed a fix to the branch.
…es (not TMS coordinates)
…l/cesium into web-mercator-terrain-tiling-scheme
Have you had a chance to look at this again @kring? |
…ain-tiling-scheme In-repo version of jtfell's #8563
Thanks for following up, @jtfell. And thanks for the pull request! |
I've integrated the
WebMercatorTilingScheme
as an option for theCesiumTerrainProvider
. I'm not 100% happy with the API yet, and realise that the QM Spec explicitly states it isI can confirm that this very small change works correctly for a terrain layer that I generated, so I can't see any reason it shouldn't be an option somehow. I am opening an issue on that repo to discuss adding this option to the spec, although the
layer.json
is a Cesium-specific manifest file.I'm happy to discuss any pathways for enabling Cesium to consume terrain in alternative tiling schemes if this approach is not viable. Cheers!