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

WebMercator Tiling for CesiumTerrainProvider #8563

Merged
merged 11 commits into from
Feb 18, 2020
Merged

WebMercator Tiling for CesiumTerrainProvider #8563

merged 11 commits into from
Feb 18, 2020

Conversation

jtfell
Copy link
Contributor

@jtfell jtfell commented Jan 22, 2020

I've integrated the WebMercatorTilingScheme as an option for the CesiumTerrainProvider. I'm not 100% happy with the API yet, and realise that the QM Spec explicitly states it is

a simple multi-resolution quadtree pyramid of heightmaps according to the Tile Map Service (TMS) layout and global-geodetic profile

I 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!

@cesium-concierge
Copy link

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.

  • ❌ Missing CONTRIBUTORS.md entry.
  • ❌ Missing CLA.
  • CHANGES.md was not updated.
    • If this change updates the public API in any way, please add a bullet point to CHANGES.md.
  • ❔ Unit tests were not updated.
    • Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

  • Cesium Viewer works.
  • Works in 2D/CV.
  • Works (or fails gracefully) in IE11.

@jtfell
Copy link
Contributor Author

jtfell commented Jan 22, 2020

Issue on quantized-mesh spec: CesiumGS/quantized-mesh#10

@jtfell
Copy link
Contributor Author

jtfell commented Jan 22, 2020

Signed CLA.

@OmarShehata
Copy link
Contributor

Thanks for the contribution @jtfell ! I can confirm we have your CLA.

@hpinkos
Copy link
Contributor

hpinkos commented Jan 29, 2020

@kring can you review this?

Copy link
Member

@kring kring left a 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?

@@ -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') {
Copy link
Member

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".

Copy link
Contributor Author

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?

Copy link
Member

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.

var yTiles = provider._tilingScheme.getNumberOfYTilesAtLevel(level);

var tmsY = (yTiles - y - 1);
if (provider._tilingScheme instanceof GeographicTilingScheme) {
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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).

@kring
Copy link
Member

kring commented Jan 30, 2020

Also, I do think this is a useful addition to the spec, so I'd be happy to merge a PR there, too. Thanks!

@jtfell
Copy link
Contributor Author

jtfell commented Jan 30, 2020

Thanks for the feedback @kring! I will create a PR for the spec after we have decided on what to do with the projection and scheme options here.

@jtfell jtfell requested a review from kring January 30, 2020 04:57
@kring
Copy link
Member

kring commented Jan 30, 2020

@jtfell your changes look good, but there seems to be a problem when using Cesium World Terrain and zooming in slightly:
image

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?

@kring
Copy link
Member

kring commented Jan 30, 2020

Oh I think the problem is that createQuantizedMeshTerrainData was previously given a proper Cesium Y-coordinate numbered from the North, and now for "scheme": "tms" terrain like Cesium World Terrain, it's being given a TMS Y-coordinate numbered from the South.

Don't ask me why CesiumJS and Cesium World Terrain use different tile numbering, even though it's totally my fault that they do. 😆

@jtfell
Copy link
Contributor Author

jtfell commented Jan 30, 2020

The behaviour for "scheme": "tms" should be unchanged though? Maybe I'm misunderstanding the problem. Do you know how to fix it?

// The TileMapService scheme counts from the bottom left
if (!provider._scheme || provider._scheme === 'tms') {
var yTiles = provider._tilingScheme.getNumberOfYTilesAtLevel(level);
y = (yTiles - y - 1);
Copy link
Member

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.

Copy link
Contributor Author

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.

@jtfell jtfell requested a review from kring February 4, 2020 06:42
@jtfell
Copy link
Contributor Author

jtfell commented Feb 17, 2020

Have you had a chance to look at this again @kring?

kring added a commit that referenced this pull request Feb 18, 2020
…ain-tiling-scheme

In-repo version of jtfell's #8563
@kring kring merged commit 7279ca8 into CesiumGS:master Feb 18, 2020
@kring
Copy link
Member

kring commented Feb 18, 2020

Thanks for following up, @jtfell. And thanks for the pull request!

@jtfell
Copy link
Contributor Author

jtfell commented Apr 9, 2020

Hey @kring not sure if you're the right person but it would be great to get this change formalised in the quantized-mesh spec. I've drafted up a PR here

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.

5 participants