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

Basic FeatureLayerStyle and FeatureLayerRenderer #4

Closed
l-laura opened this issue May 2, 2023 · 1 comment · Fixed by #14
Closed

Basic FeatureLayerStyle and FeatureLayerRenderer #4

l-laura opened this issue May 2, 2023 · 1 comment · Fixed by #14
Assignees
Milestone

Comments

@l-laura
Copy link
Contributor

l-laura commented May 2, 2023

As the mapget-model library is now ready to be used, we can write basic implementations of FeatureLayerStyle and FeatureLayerRenderer classes.

FeatureLayerStyle should use yaml-cpp to parse some style file content. The file should be fetched by JS, and the contents should then be passed into the FeatureLayerStyle constructor. Inside, the initial implementation shall support the following YAML style rule fields:

rules:
- type: [<string>]   # (Mandatory, list of feature-type-names)
  filter: string     # (Optional, Additional simfil filter expression)
  color: string      # (Optional [r:float,g:float,b:float] list or color name. Can adopt impl. from AfwColor)
  geometry: ["line", "point", "mesh"] # (Mandatory, describes which geometry to take from a matching feature)
  opacity: float     # (Optional, defaults to 1.0)

The FeatureLayerStyle class should have a rules(): vector<FeatureStyleRule> const& function, which returns the style-sheet's rules. A rule could then have a match(mapget::Feature const&): bool function, and accessors for color(): Color, opacity(): float, geometryTypes(): GeometryTypeBitmask.

To convert a feature to GLTF, the FeatureLayerRenderer::render-function takes a FeatureLayerStyle const& and a mapget::TileFeatureLayerPtr argument. All features in the layer are aggregated into a single GLB scene. To facilitate the conversion, render tries to match every feature to every rule. For a successful rule-feature match, the renderer should make sure of three things for every geometry type supported by the rule:

  1. A material must already exist or be created for each geometry-type supported by the rule.
  2. A mesh must already exist or be created for each geometry-type supported by the rule.
  3. The feature's vertices for each geometry-type supported by the rule must be added to the mesh.

The mesh should be positioned around the TileFeatureLayer's center, so coordinates in each mesh can be offset to preserve precision. The WGS84 geometry will be converted to euclidian space with a earth surface radius of 6371 km. For 3d vector/matrix math, the glm library shall be used. To emit the GLB data structure, the tinygltf library shall be used.

For initial visualisation, we call FeatureLayerRenderer::render on startup with a fixed style and an on-the-fly-generated TileFeatureLayer. We can simply point the camera at a specific point on the earth's surface where we render the static dummy TileFeatureLayer.

@l-laura l-laura self-assigned this May 2, 2023
@josephbirkner josephbirkner changed the title Basic rendering of a static TileFeatureLayer in FeatureLayerRenderer Basic FeatureLayerStyle and FeatureLayerRenderer May 23, 2023
@josephbirkner
Copy link
Collaborator

Note: The filter and type fields are not yet implemented.

@josephbirkner josephbirkner added this to the Toolchain Setup milestone Jul 20, 2023
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 a pull request may close this issue.

2 participants