cityjson / specs

Specifications for CityJSON, a JSON-based encoding for 3D city models
https://cityjson.org
Creative Commons Zero v1.0 Universal
107 stars 25 forks source link

Energy ADE #68

Closed GerfriedC closed 4 years ago

GerfriedC commented 4 years ago

Is there a need to use the energy ADE, or might thermal/optical characteristics of building elements embedded in Building ConstructiveElement? many thanks

hugoledoux commented 4 years ago

hmmm, this is surely the wrong repository, this is related to an ADE of CityGML, and this is not a CityGML repository

GerfriedC commented 4 years ago

Sorry this is the right repository, since cityJSON should incorporate the energy ADE functionality.

liberostelios commented 4 years ago

Hi @GerfriedC. Please, be aware that in CityJSON we have extensions and not ADEs.

Could you, please, give us a bit of a context here? What is that you want to do with the Energy extension?

GerfriedC commented 4 years ago

Many thanks for reopening. In the EPC4SES project, we are in need of an intermediary format for storing simulation relevant building data with a fast lane from data to simulation model which is focusing on thermal losses (R) and specific heat (C), and oriented transparent elements with solar gain. As a benefit, the buildings can be visualized, but this is not the main focus. The need for geometric rather than element-specific data also originates from the use of a simulation tool requiring coordinates. The actual scheme is differentiating between Building and Building elements and that should converge into a cityJSON scheme having coordinates. In the existing JSON, the Building is grouped into oriented walls, having names (A,A, B, B...) and information about the orientation of the wall named A, so other orientations may be derived quickly. Raytracing using LOD2-3 might be possible in the future, and a coupling to a javascript based representation of the building would be great.

many thanks

best regards

here is just random data for testing. As I understood Energy ADE defines characteristics of building materials in a list referencing that in the main scheme. Simular might be don in JSON. If possible the coordinates should be stored directly for the building without referencing in separate tables, this will avoid errors and is easier to understand. JSON should be human-readable. Daten Haus: { "Rsi": 0.09090909090909091, "Rse": 0.07692307692307693, "OrientierungKanteA": 0, "ort": "Weiz", "HGT_bez": 3182.8, "innentemp": "21", "seehoehe": "300", "seehoehe_bez": 500, "norm_aussen_temp_bez": -15, "norm_aussen_temp": -14.6, "HGT": 3182.7400000000002, "NGF": "151.2", "BGF": "180", "spezInnereWaerme": 2.5, "HT": 100, "HI": 321.29999999999995, "V_beh": "540", "LWZ": "0.4", "V_L": 216, "HV": 73.44000000000001, "Zonen": [ { "Name": "Zone 0", "Bauteile": "", "R": 0.01535598904019957, "fTemp": 0.8, "C": 28512 }, { "Name": "Zone 1", "Bauteile": "", "R": 0.037777500277500285, "fTemp": 0.8 }, { "Name": "Zone 2", "Bauteile": "", "R": 0.03380924630924631, "fTemp": 0.8 }, { "Name": "Zone 3", "Bauteile": "", "R": 0, "fTemp": 0.8 } ], "Gebauedetyp": "Freistehendes Einfamilienhaus", "Baujahr": "1990", "HB": 6851, "HWB": 21501312.5912, "HWB_BGF": 119451.73661777779 }

Daten Bauteile: { "opakeBauteile": { "Wände_Grenze zu": "Außenluft berührt", "Wände_Fläche": "228", "Wände_Konstruktion": "Hohlziegel", "Wände_Wandstärke ohne Dämmung": "0.3", "Wände_aktuelle Wärmedämmung": "0.1", "Wände_Art der Wärmedämmung": "Wärmedämmverbund", "Wände_U-Wert": "0.28561917443408785", "Wände_cp": "1.2", "oberste Decke_Grenze zu": "unbeheizter Dachboden", "oberste Decke_Fläche": "90", "oberste Decke_Konstruktion": "Einhängziegel mit Aufbeton", "oberste Decke_Wandstärke ohne Dämmung": "0.3", "oberste Decke_aktuelle Wärmedämmung": "0.1", "oberste Decke_Art der Wärmedämmung": "im Dachraum", "oberste Decke_U-Wert": "0.29411980754398204", "oberste Decke_cp": "1.8", "Kniestock_Grenze zu": "unbeheizter Dachboden", "Kniestock_Fläche": "", "Kniestock_Konstruktion": "Holzrahmenkonstruktion", "Kniestock_Wandstärke ohne Dämmung": "0.3", "Kniestock_aktuelle Wärmedämmung": "0.1", "Kniestock_Art der Wärmedämmung": "Außendämmung", "Kniestock_U-Wert": "0.40521394162652313", "Kniestock_cp": "0.15", "Dachschräge_Grenze zu": "Außenluft berührt", "Dachschräge_Fläche": "", "Dachschräge_Konstruktion": "Sparrenkonstruktion", "Dachschräge_Wandstärke ohne Dämmung": "0.3", "Dachschräge_aktuelle Wärmedämmung": "0.1", "Dachschräge_Art der Wärmedämmung": "Zwischensparrendämmung", "Dachschräge_U-Wert": "0.40521394162652313", "Dachschräge_cp": "0.15", "unterster Fussboden_Grenze zu": "unbeheizter Keller", "unterster Fussboden_Fläche": "90", "unterster Fussboden_Konstruktion": "Einhängziegel mit Aufbeton", "unterster Fussboden_Wandstärke ohne Dämmung": "0.3", "unterster Fussboden_aktuelle Wärmedämmung": "0.1", "unterster Fussboden_Art der Wärmedämmung": "Kellerdeckendämmung", "unterster Fussboden_U-Wert": "0.3286411950588911", "unterster Fussboden_cp": "1.8", "Kellerwand_Grenze zu": "Boden (Erdreich)", "Kellerwand_Fläche": "", "Kellerwand_Konstruktion": "Beton/Betonstein", "Kellerwand_Wandstärke ohne Dämmung": "0.3", "Kellerwand_aktuelle Wärmedämmung": "0.1", "Kellerwand_Art der Wärmedämmung": "Wärmedämmverbund", "Kellerwand_U-Wert": "0.35736404628673873", "Kellerwand_cp": "3.75", "sonst. Wände_Grenze zu": "Garage/Schuppen", "sonst. Wände_Fläche": "0", "sonst. Wände_Konstruktion": "Hohlziegel", "sonst. Wände_Wandstärke ohne Dämmung": "0.3", "sonst. Wände_aktuelle Wärmedämmung": "0.1", "sonst. Wände_Art der Wärmedämmung": "Wärmedämmverbund", "sonst. Wände_U-Wert": "0.28561917443408785", "sonst. Wände_cp": "1.2", "sonst. Kellerwand_Grenze zu": "Außenluft berührt", "sonst. Kellerwand_Fläche": "", "sonst. Kellerwand_Konstruktion": "Hohlziegel", "sonst. Kellerwand_Wandstärke ohne Dämmung": "0.3", "sonst. Kellerwand_aktuelle Wärmedämmung": "0.1", "sonst. Kellerwand_Art der Wärmedämmung": "Wärmedämmverbund", "sonst. Kellerwand_U-Wert": "0.28561917443408785", "sonst. Kellerwand_cp": "1.2" }, "transparenteBauteile": { "A_Flächenanteil": "20", "A_Anzahl": "", "A_Breite": "", "A_Höhe": "", "A_U-Wert/Typ": "1.8", "B_Flächenanteil": "20", "B_Anzahl": "", "B_Breite": "", "B_Höhe": "", "B_U-Wert/Typ": "1.8", "A*_Flächenanteil": "10", "A*_Anzahl": "", "A*_Breite": "", "A*_Höhe": "", "A*_U-Wert/Typ": "1.8", "B*_Flächenanteil": "20", "B*_Anzahl": "", "B*_Breite": "", "B*_Höhe": "", "B*_U-Wert/Typ": "1.8", "Pultdach_Flächenanteil": "0", "Pultdach_Anzahl": "", "Pultdach_Breite": "", "Pultdach_Höhe": "", "Pultdach_U-Wert/Typ": "1.8" } }

liberostelios commented 4 years ago

I am no expert regarding the Energy extension or the domain in general. But my suggestion is that you could simply use a Building to store all the information if the house (so things in Daten Haus would be in the Buidling's "attributes"). Then, what you call Building elements (in Daten Bauteile) could be stored as semantic surfaces in the Building's geometry.

If you don't want information to be stored in individual surfaces and repeated several times, you could create your own extension where you store those information once, for the whole CityJSON file, and then you just refer to them from every individual semantic surface.

As I understood Energy ADE defines characteristics of building materials in a list referencing that in the main scheme. Simular might be don in JSON. If possible the coordinates should be stored directly for the building without referencing in separate tables, this will avoid errors and is easier to understand. JSON should be human-readable.

Are you referring here to the indexing mechanism of CityJSON (i.e. having a table with "vertices" and pointing to the indexes for every city object)? If that's the case, unfortunately for now that's the only way we support geometries. There are discussions about whether we should have an option to directly store coordinates for every individual Building itself, especially for web APIs consumed through JavaScript (see here).