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

iTwin Reality Data - add GeoJSON/KML support #12344

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

jjspace
Copy link
Contributor

@jjspace jjspace commented Nov 27, 2024

Description

This is a follow up to #12334 to add support for GeoJSON and KML data types from the Reality Management API.

The implementation should be good to go but the Sandcastle will need updated to the iTwin and data we actually want to use.

  • Updated Sandcastle data

Issue number and link

No issue

Testing plan

  • Check the new iTwin Feature Service sandcastle and make sure all data is loading as expected

Author checklist

  • I have submitted a Contributor License Agreement
  • I have added my name to CONTRIBUTORS.md
  • I have updated CHANGES.md with a short summary of my change
  • I have added or updated unit tests to ensure consistent code coverage
  • I have updated the inline documentation, and included code examples where relevant
  • I have performed a self-review of my code

@jjspace jjspace requested a review from jjhembd November 27, 2024 19:39
Copy link

Thank you for the pull request, @jjspace!

✅ We can confirm we have a CLA on file for you.

Copy link
Contributor

@jjhembd jjhembd left a comment

Choose a reason for hiding this comment

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

Thanks @jjspace, this looks good overall. I put 2 minor comments.

I guess we want to wait for the final data before merging?

@@ -38,54 +38,19 @@ ITwinPlatform.ExportType = Object.freeze({
});

/**
* Types of Reality data
* Types of Reality data. This is a partial list of types we know we can support
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are we dropping the unsupported types here?
In the loading functions, we already create a local supportedRealityDataTypes array, so it seems like this enum could still retain all valid types, including unsupported ones.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was requested by the iTwin team. The types are potentially changing and/or not a complete list so I trimmed this down to only those types we really care about. I still wanted to keep it in the enum instead of only in the array of supportedRealityTypes to make it centrally located and easy to change later.

// Create tileset of the reality data mesh
// TODO: swap this out with a different mesh
const realityMeshId = "85897090-3bcc-470b-bec7-20bb639cc1b9";
const realityMesh = await Cesium.ITwinData.createTilesetForRealityDataId(
Copy link
Contributor

Choose a reason for hiding this comment

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

This tileset is really blurry for me, unless I force the maximumScreenSpaceError smaller.

Current maximumScreenSpaceError: 4:
image

With maximumScreenSpaceError: 1:
image

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was a problem in the other sandcastle as well. 4 seemed to be a decent value overall but maybe not that far zoomed out. This is not the final mesh going to be used for this Sandcastle so I can re-evaluate that when I update to the other data.

@jjspace
Copy link
Contributor Author

jjspace commented Nov 27, 2024

Thanks for the review @jjhembd!

I guess we want to wait for the final data before merging?

That is correct. The code shouldn't change but I will change the iTwin and specific reality data assets the sandcastle is pointing at before this is ready to merge

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.

2 participants