Raster layers: call for integration or upstream collaboration

[charlieforward9]

A raster-layers module existed in this repo, originally forked from @kylebarron's deck.gl-raster by @ibgreen in #171. It provided GPU-accelerated raster visualization layers (RasterLayer, RasterMeshLayer) with WebGL modules for spectral indices, pansharpening, and colormaps.

The upstream project has since been adopted by Development Seed and continues to be actively maintained. The copy in this repo was stale and was removed during cleanup.

@kylebarron — would there be interest in tighter integration with the deck.gl-community ecosystem? Some questions worth discussing:

• Discoverability: How can we make raster-layers more visible to the deck.gl community? (e.g. documentation links, example galleries, cross-references)
• Integration: Would it make sense to publish raster-layers under the @deck.gl-community scope, or is the current standalone package the right home?
• Maintenance: Is there anything the community repo could do to support the project (CI, docs hosting, example integration)?

If there is interest in a community integration, this issue can track that effort. Otherwise we can close this out and just add a pointer in the docs.

Source available in git history. See also the Roadmap (#82) where raster-layers is listed as a candidate module.

[kylebarron]

I think for the near-term future we would prefer having it live in the existing home in the Development Seed repo. I think for as long as we're "driving development", we probably prefer having our name obviously attached to the project in the way that it currently exists. But we could have more discussions in the future; I haven't asked others in the company.

We're definitely open to contributions there.

[charlieforward9]

@kylebarron thanks for getting back so quick. Makes sense - especially as its actively being developed.

@ibgreen I wonder if the best idea here would be to maintain a list of external community modules on the deck.gl-community website for layers built by developers who prefer to keep the code attached to their respective brands. The preference would be to graduate projects into the community, but while under external development, the list could be updated per-minor version bump?

[chrisgervang]

I think that makes a lot of sense, and also makes sense to add community highlights to this repos webpage. People have been open to us hosting an "Awesome deck.gl" list of sorts, we just haven't had a maintainer willing to keep it up to date.

Not suggesting we need to do a formal awesome list.. I just agree that there's benefit to increasing discoverability of these great projects extending deck

[charlieforward9]

AWESOME.md otw

[ibgreen]

My 2 cents, whatever we do should be low maintenance.

• Tacking on the burden of tracking minor versions of packages out there is a bit much.
• Just a line explaining what these packages are, maybe including a screenshot, and linking to them might be sufficient, big increase in discoverability.