EnergySystem Module: no _CityObjects?
Closed this issue · 8 comments
Hello,
I have noticed that none of the EnergySystem classes is derived from a _CityObject, but is "just" a Feature.
I my opinion, many of them (EnergyDistributionSystem, EnergyStorageSystem, Emitter, EnergyConversionSystem) should actually be derived from a _CityObject.
If so, I believe this change should be backported directly to the 0.8 version.
What do you think?
Greetings,
g
Hi,
I'm not very familiar with these kind of problems. But wouldn't this mean that every storage, emitter etc. MUST be derived from a _CityObject and thus be connected to a object with spatial information?
Hi all,
I believe, we should first understand the difference between a _Feature and a _CityObject.
Credit is due to T. Kolbe for providing the following definitions (between "") which help us in the discussion:
"The idea of a _CityObject class is to act as base classe for all urban objects (as well as their component parts). It is intended to represent all physical objects", so no matter whether they have an explicit geometry representation or not. "From this point of view, all Energy ADE objects such as PV panels, EnergyStorageSystems, etc. should be modelled accordingly".
"All remaining objects, which do not represent a physical entity, but might indeed have some spatial characteristics (i.e. Addresses), should be represented either as _Feature or as GMLObject.
One of the main differences between _Feature and GMLObject is the possibility to query the former by WFS not only through the gml:id, but also using other criteria in the GetFeature-queries".
So, according to these definitions, I believe the following classes in the v.0.8 (or from 0.9) should be derived from _CityObject and not from _Feature:
- EnergyStorageSystem
- EnergyDistribution System
- EnergyConversionsSystem
- Emitter
What do you think?
Interesting explanations. Ok for me. If everyone agrees, we change it in V0.8 or in V0.9?
A short question from my side:
Does CityGML make a difference between objects (physical identities) and systems (sets of interacting component and functions) ? If a PV panel is clearly an object, a PV system includes also inverter, connections, controls. In our case, these systems may be simplified to a simple gain coefficient (yearGlobalEfficiency) if no further information are available...
The central practical differemce between "ordinary" GML-features (derived from gml:_Feature) and specific CityGML City Objects (derived from base:_CityObject) is that City Objects inherit all base properties of _CityObject. There enable the specification of creation and termination dates, the specification of the object's position relative to terrain or water, the attachment of generic attributes, and the association of the object with external ressources like documents, WFS-queries, ...
Neither GML nor CityGML differentiate between objects and systems (sets of objects). Many CityGML objects (e.g. Buildings, Bridges, Tunnels) are composed of other objects (Boundary Sufraces, Rooms, ...) and thus could also be regaded as systems.
In summary, I agree with the proposal that the basic Feature Types of the Energy Module should be derived from _CityObject.
Request of change:
Derive all EnergySystem classes from _CityObject instead of _Feature.
I don't agree in this generality. There are still some FeatureTypes (e.g. FinalEnergy or EnergyDemand) which are no city objects. However, I propose to close this issue and continue the discussion unter the more general issue #137