Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • C citygml-energy
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 29
    • Issues 29
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • energyade
  • citygml-energy
  • Issues
  • #114
Closed
Open
Issue created May 10, 2016 by Moritz Robert Lauster@mlausterMaintainer

Restrict Construction / ConstructionOrientation to relevant ADE features

Created by: JoachimBenner

In ADE version 0.6.0, we defined the new classes Construction and ConstructionOrientation, and simultaneously introduced the extension attribute construction of _CityObject. This allows that every CityGML feature of the base standard as well as of the Energy ADE can refer to layered material information.

This is problematic due to two different reasons:

  • It is not the task of the Energy ADE to define general extensions of the base standard, especially in cases where a corresponding change request for CityGML 3.0 already exists.
  • Concerning the specific features of the EnergyADE, there are many of them where the construction relation does not make sense (e.g. ThermalZone, UsageZone, ..) or where the specification of material information is even forbidden (ThermalBoundary).

I therefore propose to delete the general construction relation from _CityObject to Construction / ConstructionOrientation, and to introduce specific relations for those classes of the base standard and the extension where the concept is really needed: _BoundarySurface and ThermalComponent.

For simplifying the schema, I furthermore propose to introduce a new, abstract super class AbstractConstruction of Construction and ConstructionOrientation, which can be used as relation target.

Assignee
Assign to
Time tracking