Proposal: Interactive extruded GeoJSON map as a Community component

MagicWAYNE

## Summary Would you be open to an interactive extruded GeoJSON map as a ThreeUI Community component? The proposed component would render GeoJSON `Polygon` and `MultiPolygon` features as an interactive Three.js scene, with configurable extrusion, data columns, hover feedback, glow, camera behavior, and colors. This proposal is informed by an existing working project, but I am **not** proposing to merge or embed the entire application into ThreeUI. Existing reference: - Live demo: https://geojson-map-studio.vercel.app/ - Source project: https://github.com/MagicWAYNE/geojson-map-studio - Preview: https://raw.githubusercontent.com/MagicWAYNE/geojson-map-studio/main/preview.gif  ## Proposed Community component Working name: `ExtrudedGeoJsonMap` The component would accept GeoJSON and optional regional metrics through props rather than including an authoring application or upload workflow. Possible API direction: - `geojson`: a GeoJSON `FeatureCollection` - `values`: optional values keyed by feature identifier - `extrusionDepth` and `elevationScale` - `topColor`, `sideColor`, and `glowColor` - `showDataBars` - `autoRotate` - `enableHover` - camera and interaction options Possible variants: 1. **Neon Regions** — extruded regions with cyan edge glow and hover elevation. 2. **Data Bars** — regional values represented as animated vertical columns. 3. **Wireframe Atlas** — a restrained monochrome/wireframe treatment suitable for hero sections and technical dashboards. ## Implementation boundaries I would extract only the reusable renderer and adapt it to ThreeUI conventions: - A framework-independent TypeScript/Three.js renderer. - A small React lifecycle wrapper compatible with the public ThreeUI package. - One WebGL context with complete resource cleanup. - Responsive sizing through `ResizeObserver`. - Visibility-aware animation and document visibility handling. - Reduced-motion support. - No runtime network requests. - No Vue, router, ECharts, IndexedDB, authoring panels, regional catalog, or upload workflow. - No third-party fonts, satellite imagery, administrative datasets, or inherited dashboard assets. - A small synthetic GeoJSON fixture for the default preview. - Only code and assets that can be contributed under the repository's MIT license. ## Why it may fit ThreeUI The reusable part is a visual Three.js component rather than a domain-specific map application. It could work as an interactive hero, dashboard background, or lightweight geographic data visualization while keeping the consumer-facing API focused and customizable. ## Contribution-path questions Before implementing the extraction, I would appreciate guidance on: 1. Does ThreeUI currently accept third-party Community component proposals? 2. Since the public Community repository is synchronized from a separate main project, should a component contribution target this public repository, or should the source first be reviewed for inclusion in the main catalog? 3. Would you prefer a small standalone React proof of concept before the package export, catalog metadata, controls, and variants are implemented? I am happy to keep the first version narrowly scoped and follow the repository's preferred component structure and review process.

MengTo

Thanks for the thoughtful proposal. Before you invest time in a proof of concept, could you clarify two things? 1. Would you require credit or attribution if the component is included in ThreeUI? If so, what form and placement would you expect? 2. Are you comfortable with ThreeUI editing and maintaining the contribution as needed—including changing the implementation language or framework boundaries, component API and naming, code structure, controls and variants, motion, visual design, and overall polish—to fit the library’s conventions? We would preserve any required license notices and agreed attribution, but we need enough freedom to adapt the component over time. Your answers will help us decide the right contribution path.

MagicWAYNE

Thanks for clarifying these points. I’m comfortable with both: 1. Attribution: I don’t require personal credit or acknowledgment beyond any notices required by the applicable license. A mention would be appreciated, but it’s entirely optional—I have no requirements regarding its form or placement. 2. Editing and maintenance: Yes, I’m comfortable with ThreeUI editing and maintaining the contribution as needed, including all the changes you outlined. You’re welcome to adapt the implementation, API, naming, structure, controls, variants, motion, and visual design to fit the library’s conventions and evolving needs. My priority is for the component to be useful and feel at home in ThreeUI. I’m happy to follow whichever contribution path you think is the best fit.