You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that the OpenStudio gbXML ForwardTranslator does not include schedules (and, more specifically, ScheduleRulesets) in its gbXML export and it would be very helpful if we could translate these schedules into gbXML so that we can send them to other platforms.
Detailed Description
At present, the gbXML schema supports schedules in the ScheduleDay, ScheduleWeek and ScheduleYear format. But the OpenStudio App represents schedules through the ScheduleRuleset and I think many of us agree that ScheduleRulset has a ton of advantages over the day/week/year format.
ScheduleRuleset is not natively supported by the gbXML schema but all ScheduleRuleset can be mapped to ScheduleDay/ScheduleWeek/ScheduleYear format and OpenStudio SDK clearly contains this map already since it is used in the IDF ForwardTranslator. So this map could hypothetically be used to ensure ScheduleRulesets are included in the exported gbXML.
Possible Implementation
The fastest and most user-friendly way that I could think to implement this would be to use the map that must already exist in OpenStudio SDK's IDF ForwardTranslator within the gbXML ForwardTranslator. So we would get ScheduleRulesets in the exported gbXML automatically.
If, for whatever reason, we wouldn't want to have the ScheduleRuleset automatically translated to gbXML another option would be to just expose the ability in the OpenStudio SDK to translate a ScheduleRuleset into corresponding ScheduleWeek and ScheduleYear objects. Then, we could add support to have these Schedule day/week/year objects translated to the gbXML. This way, if I wanted to include schedules in a gbXML, I could just do this translation with a measure before exporting the gbXML.
Thanks for the suggestion of adding this to the SDK. This sounds doable, especially since you pointed out that the map for ScheduleRulesets already exists in the code and it would be adding a parsing routine in the translator to output from ScheduleRulesets to Day, Week, Year. We can take a look at this and try and get this in the queue for v3.3.0 milestone release.
Enhancement Request
I noticed that the OpenStudio gbXML
ForwardTranslator
does not include schedules (and, more specifically, ScheduleRulesets) in its gbXML export and it would be very helpful if we could translate these schedules into gbXML so that we can send them to other platforms.Detailed Description
At present, the gbXML schema supports schedules in the
ScheduleDay
,ScheduleWeek
andScheduleYear
format. But the OpenStudio App represents schedules through the ScheduleRuleset and I think many of us agree thatScheduleRulset
has a ton of advantages over the day/week/year format.ScheduleRuleset is not natively supported by the gbXML schema but all
ScheduleRuleset
can be mapped toScheduleDay
/ScheduleWeek
/ScheduleYear
format and OpenStudio SDK clearly contains this map already since it is used in the IDF ForwardTranslator. So this map could hypothetically be used to ensureScheduleRulesets
are included in the exported gbXML.Possible Implementation
The fastest and most user-friendly way that I could think to implement this would be to use the map that must already exist in OpenStudio SDK's IDF ForwardTranslator within the gbXML ForwardTranslator. So we would get ScheduleRulesets in the exported gbXML automatically.
If, for whatever reason, we wouldn't want to have the ScheduleRuleset automatically translated to gbXML another option would be to just expose the ability in the OpenStudio SDK to translate a
ScheduleRuleset
into correspondingScheduleWeek
andScheduleYear
objects. Then, we could add support to have these Schedule day/week/year objects translated to the gbXML. This way, if I wanted to include schedules in a gbXML, I could just do this translation with a measure before exporting the gbXML.CC: @tanushree04
The text was updated successfully, but these errors were encountered: