Would a third-party plugin example (SGP4 satellite catalog) be welcome in the Sandcastle gallery?

CesiumJS
1

## Proposal

I would like to add a Sandcastle gallery example showing a large satellite catalog (about 16,000 objects from CelesTrak) propagated with SGP4 and rendered on the globe, with orbit paths, regime filtering (LEO, MEO, GEO, HEO), search by name or NORAD ID, hover labels and picking.

The example uses [cesium-sgp4-viewer]( GitHub - dsanchez31/cesium-sgp4-viewer: Show a whole satellite catalog on a CesiumJS globe, from a list of TLEs: every object at its SGP4 position, its orbit, its name, following the scene's clock. · GitHub ), an Apache-2.0 library I maintain. Live demo in Sandcastle today: <SANDCASTLE_SHARE_LINK>

## How it works

- The library ships an IIFE build on npm, loaded from jsDelivr at a pinned version. It reads the global `Cesium`, so it shares the instance Sandcastle already loaded.

- SGP4 propagation runs in web workers created from `blob:` URLs. Nothing else is served.

- Satellites are drawn with a point primitive collection; orbits use a custom vertex and fragment shader.

- The TLE snapshot is fetched from the library repository through jsDelivr, pinned to a release tag.

## Open questions for maintainers

1. **Third-party code in the gallery.** No current gallery example loads an external library. `CONTRIBUTING.md` asks to discuss this first. Is a plugin showcase acceptable in the gallery, or would you prefer another place (forum showcase, a community plugins page)?

2. **Undocumented API.** The orbit rendering relies on renderer classes that are exported but not documented (`DrawCommand`, `VertexArray`, `ShaderProgram`, …). If a CesiumJS release changes them, the library disables orbits with a console warning while points, labels and picking keep working. Is that acceptable for a gallery entry?

3. **External hosting.** Both the script and the TLE file come from jsDelivr. Would you rather host the TLE file with the other Sandcastle assets?

If the answer is yes, I will open a PR adding `packages/sandcastle/gallery/` (`index.html`, `main.js`, `sandcastle.yaml`, `thumbnail.jpg`) plus the `CHANGES.md` and `CONTRIBUTORS.md` entries.

3

Hey @dsanchez31,

This is a really cool project, and thanks for writing it up so clearly. Rendering 16,000 satellites live in Sandcastle is awesome!

My gut feeling is that the Sandcastle examples are mostly meant to show off raw CesiumJS capability on their own, and I’m not aware of any gallery entry that pulls in an external library from a CDN. So I suspect a plugin showcase that depends on jsDelivr for both the script and the TLE data isn’t likely to be a fit for the gallery itself, and the same gut feeling applies to leaning on the undocumented renderer classes for a maintained example.

That said, the gallery lives in the CesiumJS repo and the maintainers own that call, so the best next step is to open a GitHub issue or discussion on CesiumGS/cesium and lay out exactly what you have here, including the external hosting question for the TLE snapshot. That lines up with CONTRIBUTING.md asking to discuss things first, and it’ll get you a definitive answer rather than my guess.

Either way, I’d love for this to get some visibility, you could post it in General or CesiumJS as a showcase/look at this cool thing I did?

Cheers!

5

Thanks a lot @darcyvdd for the kind words and the clear guidance!

Following your suggestion, I’ve posted it as a showcase in General (waiting for moderator approval).

Cheers!

6

Disclaimer: All this is not my call, I’m not making any decisions here, the following is purely subjective brainstorming.

My gut feeling is that this is “too much of an application” to be included in the core sandcastle. But I have not yet looked at the details of the project. Maybe there is a clean way to handle external dependencies.

It might be that when (longer-term!) the sandcastle is moved into its own repository (at GitHub - CesiumGS/cesium-sandcastle · GitHub ), it may be possible to have “larger” sandcastles (i.e. actual applications) integrated with that somehow. (Again, no promises, just a thought).

Then, still, the fact that it uses some internal API may be a reason to not include it: Clients should generally not uses these classes, because they might change unpredictably between two releases, and we don’t want to encourage users to access this private API. But (also longer term): I think that for it can be useful to access this (private API) for first demos and experiments. This is a good way to inform developers about what the public API should be. For example, when many clients need to create some specific form of a DrawCommand or Shader, then it could make sense to offer some way of creating these as part of the public API.

An aside: I increased your ‘Trust Level’ in the forum. Future posts won’t need moderator approval.