Dynamizers for CityGML

Transcription

1 Dynamizers for CityGML Kanishk Chaturvedi, Thomas H. Kolbe Chair of Geoinformatics

2 Time-varying properties Highly dynamic changes Variations of spatial properties: change of a feature s geometry, both in respect to shape and to location (moving objects) Variations of thematic attributes: changes of physical quantities like energy demands, mean temperature, solar irradiation; change of the real property value of a building; change of ownership over time Variations with respect to sensor or real-time data Source:C. García-Ascanio and C. Maté, Electric power demand forecasting using interval time series: A comparison between VAR and imlp, Energy Policy Source: MOREL M., GESQUIÈRE G., Managing Temporal Change of Cities with CityGML. In UDMV (2014) Dynamizers - CityGML 2

3 Dynamizers - Proposed approach To create a mechanism that allows storing dynamic values separately from original (static) attributes The proposed schema contains dynamic values in special types of features, which would be interpreted as modifiers to the static values of the CityGML feature attributes If an application does not support dynamic data, it simply does not allow/include these special types of features. Advantage: This approach would easily fit into the modularization concept of CityGML Dynamizers - CityGML 3

4 Buildings Transportation Objects Water Bodies Vegetation Geometry Semantics Appearance Dynamizers Dynamizers Sensors Databases External Files Dynamizers - CityGML 4

5 Dynamizers - Introduction Such special types of features are called Dynamizers. Dynamizers define two things: A data structure to represent time-variant values in different and generic ways A method to enhance static city model by time-variant/dynamic property values Dynamizers refer to a specific property of a static CityGML feature which value will then be overridden or replaced by the (dynamic) values specified in the Dynamizer feature. gml:abstractfeature AbstractCityObject Dynamizer + attributeref :URI + startpoint :TM_Position + endpoint :TM_Position Abstract Timeseries +dynamicdata Dynamizers - CityGML 5

6 Example CityGML object <cityobjectmember> <Building gml:id = "building1"> <gen:doubleattribute name = "HeatDemand"> <gen:value = /> </gen:doubleattribute> </Building> </cityobjectmember> Replacing dynamic attributes using XPath Source of dynamic data Estimated (in kwh) Heat Demand JAN FEB MAR DEC <cityobjectmember> <dyn:dynamizer> <dyn:attributeref> //Building [@gml:id = 'building1']/doubleattribute[@name = 'HeatDemand']/gen:value</dyn:attributeRef> <dyn:startpoint> T00:00:00Z </dyn:startpoint> <dyn:endpoint> T00:00:00Z </dyn:endpoint> <dyn:dynamicdata>.. </dyn:dynamicdata> </dyn:dynamizer> </cityobjectmember> Dynamizer Dynamizers - CityGML 6

7 How to specify dynamic values in Dynamizers? TimeseriesML 1.0 is a new OGC standard for the representation and exchange of timeseries Extension of the work initially undertaken within OGC WaterML 2.0:Part 1- Timeseries Aim at developing domain-neutral model for the representation and exchange of timeseries data Developments OGC r3: Timeseries Profile of Observations and Measurements OGC r3: XML encoding that implements the OGC Timeseries Profile of Observations and Measurements Dynamizers - CityGML 7

8 TimeseriesML1.0 Time-Value Pair Encoding Representation of a special case of the CV_DiscreteCoverage class from OGC Abstract Specification Topic 6 «FeatureType» TimeseriesTVP + defaultpointmetadata: PointMetadata [] «DataType» Timeseries Metadata::TimeseriesMetadata + temporalextent: TM_Period [] + basetime: TM_Position [] + intendedobservationspacing: TM_Period [] + cumulative: Boolean [] + accumulationanchortime: TM_Period [] + accumulationintervallength: TM_PeriodDuration [] + startanchorpoint: TM_Position [] + endanchorpoint: TM_Position [] + spacing: TM_PeriodDuration [] + status: StatusCode [] + sampledmedium: SampledMediumCode [] + maxgapperiod: TM_PeriodDuration [] + parameter: NamedValue [0..*] +commentblock 0..* Annotation +metadata +point 0..* «DataType» TimeValuePair {abstract} + time: TM_Position [] + value «DataType» Timeseries Metadata::PointMetadata + quality: DataQualityCode [] + uom: UnitOfMeasure [] + interpolationtype: InterpolationCode [] + nilreason: NilReason [] + censoredreason: CensoredReasonCode [] + comment: CharacterString [] + accuracy: Quantity [] + relatedobservation: OM_Observation [] + aggregationduration: TM_PeriodDuration [] + qualifier: Quantity [0..*] + processing: ProcessingCode [] + source: MD_DataIdentification [] +metadata «DataType» Timeseries Metadata:: CommentBlock + applicableperiod: TM_Period + comment: CharacterString «DataType» MeasurementTVP «nillable» + value: Measure «DataType» CategoricalTVP «nillable» + value: Category Source : [OGC r3 Timeseries Profile of Observations and Measurements] Dynamizers - CityGML 8

9 TimeseriesML 1.0 Domain-Range Encoding Extension of OGC Implementation Schema for Coverages (09-146r2) Ab stractcoverage «FeatureType» GMLCOV::DiscreteCoverage {abstract} «FeatureType» TimeseriesDomainRange «FeatureType» AnnotationCoverage + type: Reference [] +annotation 0..* +metadata 0..* «DataType» TimeseriesMetadataExtension + defaultpointmetadata: PointMetadata [] + timeseriesmetadata: TimeseriesMetadata [] Source : [OGC r3 Timeseries Profile of Observations and Measurements] Dynamizers - CityGML 9

10 Dynamizers (1st Stage) Timeseries gml:abstractfeature AbstractCityObject Dynamizer + attributeref :URI + startpoint :TM_Position + endpoint :TM_Position TimeseriesTVPMetadata + timeseriesmetadata :TimeseriesMetadata[] TimeseriesDRMetadata + defaultpointmetadata :PointMetadata[] + timeseriesmetadata :TimeseriesMetadata[] +metadata 0..* TimeseriesML:: TimeseriesDR +dynamicdatatdr Timeseries +dynamicdata +dynamicdatatvp +metadata 0..* TimeseriesML:: TimeseriesTVP + defaultpointmetadata :PointMetadata[] +point 0..* TimeValuePair + time:tm_position[] + value Dynamizers - CityGML 10

11 XML Structure Domain-Range Encoding <cityobjectmember> <Building gml:id = "building1"> <gen:doubleattribute name = "HeatDemand"> <gen:value>61578</gen:value> CityGML Building </gen:doubleattribute> </Building> </cityobjectmember> <cityobjectmember> <dyn:dynamizer gml:id = "HeatDemandTimeseries" > <dyn:attributeref>//building[@gml:id ='building1']/doubleattribute[@name = 'HeatDemand']/gen:value </dyn:attributeref> <dyn:startpoint> t00:00:00z</startpoint> <dyn:endpoint> t00:00:00z</endpoint> <dyn:dynamicdata> <dyn:timeseries> <dyn:dynamicdatadr> <tsml:timeseriesdomainrange gml:id="timeseries"> <gml:domainset> <tsml:timepositionlist gml:id="temporal_domain"> <tsml:timepositionlist> t00:00:00z T00:00:00Z T00:00:00Z T00:00:00Z T00:00:00Z T00:00:00Z T00:00:00Z T00:00:00Z T00:00:00Z T00:00:00Z T00:00:00Z T00:00:00Z</tsml:timePositionList> </tsml:timepositionlist> </gml:domainset> <gml:rangeset> Absolute Time Points <gml:quantitylist uom="kwh"> missing missing </gml:quantitylist> </gml:rangeset> </tsml:timeseriesdomainrange> </dyn:dynamicdatadr> </dyn:timeseries> </dyn:dynamicdata> </dyn:dynamizer> <cityobjectmember> Overriding using XPath Domain-Range Encoding (Absolute Time Points, can also be irregular time points) Dynamizers - CityGML 11

12 Alternative Representation: Time-Value Pair Encoding <cityobjectmember> <dyn:dynamizer gml:id = "HeatDemandTimeseries" > <dyn:attributeref>//building[@gml:id ='building1']/doubleattribute[@name = 'HeatDemand']/gen:value <dyn:startpoint> t00:00:00z</startpoint> <dyn:endpoint> t00:00:00z</endpoint> <dyn:dynamicdata> <dyn:timeseries> <dyn:dynamicdatatvp> <tsml:timeseriestvp gml:id="tsml.measurementimeseries.heatdemand"> <tsml:point> <tsml:measurementtvp> <tsml:time> t00:00:00z</tsml:time> <tsml:value>39.97</tsml:value> </tsml:measurementtvp> </tsml:point> <tsml:point> <tsml:measurementtvp> <tsml:time> t01:00:00z</tsml:time> <tsml:value>40.12</tsml:value> </tsml:measurementtvp> </tsml:point> <tsml:point> <tsml:measurementtvp> <tsml:time> t02:00:00z</tsml:time> <tsml:value>40.02</tsml:value> </tsml:measurementtvp> </tsml:point>... </tsml:timeseriestvp> <dyn:dynamicdatatvp> </dyn:timeseries> </dyn:dynamicdata> </dyn:dynamizer> </cityobjectmember> Time-Value Pair Encoding (Absolute Time Points, can also be irregular time points) </dyn:attributeref> Dynamizers - CityGML 12

13 Regular spacing of time Previous examples use absolute time points for each measurement within the timeseries However, TimeseriesML 1.0 allows to specify relative time points by providing proper metadata basetime absolute time points (considered as start points) spacing time duration, used for calculating regular spacing Only the first time point must be given in absolute time; the following timestamps are calculated with the help of spacing Dynamizers - CityGML 13

14 Metadata Handling regular spacing: TVP Encoding <cityobjectmember> <dyn:dynamizer gml:id = "HeatDemandTimeseries" > <dyn:attributeref>//building[@gml:id ='building1']/doubleattribute[@name = 'HeatDemand']/gen:value </dyn:attributeref> <dyn:startpoint> t00:00:00z</startpoint> <dyn:endpoint> t00:00:00z</endpoint> <dyn:dynamicdata> <dyn:timeseries> <dyn:dynamicdatatvp> <tsml:timeseriestvp gml:id="tsml.measurementimeseries.heatdemand"> <tsml:metadata> <tsml:timeseriesmetadata> <tsml:basetime> t00:30: :00</tsml:basetime> <tsml:spacing>pt30m</tsml:spacing> </tsml:timeseriesmetadata> </tsml:metadata> <tsml:point> <tsml:measurementtvp> <tsml:value>39.97</tsml:value> </tsml:measurementtvp> </tsml:point> <tsml:point> <tsml:measurementtvp> <tsml:value>40.12</tsml:value> </tsml:measurementtvp> </tsml:point> <tsml:point> <tsml:measurementtvp> <tsml:value>40.02</tsml:value> </tsml:measurementtvp> </tsml:point>... </tsml:timeseriestvp> <dyn:dynamicdatatvp> </dyn:timeseries> </dyn:dynamicdata> </dyn:dynamizer> </cityobjectmember> Spacing of 30 minutes Currently, it supports absolute time point. Mechanism required for the support of relative/local time reference system Time-Value Pair Encoding (Relative Time Points, equi-distant/ regular) Dynamizers - CityGML 14

15 Composite Timeseries - Supporting patterns Weekly Patterns Repeat 5 times 3,5 3 2,5 2 1,5 1 0,5 0 Energy Values Energy Values Energy Values 3 3 2,5 2, ,5 1, ,5 0, Energy Values Energy Values Energy Values (Working days) (Saturdays) (Sundays) A B C Dynamizers - CityGML 15

16 Complex Composite Timeseries Monthly Patterns Monthly Patterns A A A A A B C A A A A A B C A A A A A B C Week 1 Week 2 Week 3. Until Week Dynamizers - CityGML 16

17 Dynamizer (2nd Stage) Support of Patterns gml:abstractfeature AbstractCityObject Dynamizer + attributeref :URI + startpoint :TM_Position + endpoint :TM_Position +dynamicdata AbstractTimeseries 1 +timeseries TimeseriesComponent + repetitions:integer + additionalgap :TM_Duration[] 1..* +component {ordered} AtomicTimeseries CompositeTimeseries TimeseriesML:: TimeseriesDR +dynamicdatatdr +dynamicdatatvp TimeseriesML:: TimeseriesTVP Further classes of TimeseriesML have been omitted here for better readability Dynamizers - CityGML 17

18 Relative Time Dynamizers model each timestamp as TM_Position defined by ISO Each time position in ISO is referenced to a specific time reference system (e.g. Gregorian Calendar) However, in some scenarios, time cannot be described by absolute positions, but relative to absolute positions They may be defined for a non-specific year (e.g. averages over many years) but still classified by relative time of year E.g., January monthly summaries might be described as all- Januaries E.g. Seasons of the year (spring, summer, autumn, winter) In ISO 19108, they may be defined as TM_OrdinalEras within TM_OrdinalReferenceSystems Dynamizers - CityGML 18

19 Local Reference System <gml:timeordinalreferencesystems gml:id = localreference" > <gml:name>localreferencesystem </gml:name> <gml:component> <gml:timeordinalera gml:id = Weekdays" > <gml:start>00:00:00</gml:start> <gml:end> 23:59:59 </gml:end> </gml:timeordinalera> <gml:timeordinalera gml:id = Saturdays" > <gml:start>00:00:00</gml:start> <gml:end> 23:59:59 </gml:end> </gml:timeordinalera> <gml:timeordinalera gml:id = Sundays" > <gml:start>00:00:00</gml:start> <gml:end> 23:59:59 </gml:end> </gml:timeordinalera> </gml:component> </gml:timeordinalreferencesystems> Dynamizers - CityGML 19

20 <cityobjectmember> <dyn:dynamizer gml:id = "WeeklyPatterns" > <dyn:attributeref>.... </dyn:attributeref> <dyn:startpoint> t00:00:00z</startpoint> <dyn:endpoint> t00:00:00z</endpoint> <dyn:dynamicdata> <dyn:compositetimeseries gml:id="weekdays"> <dyn:component> <dyn:timeseriescomponent> <dyn:numberofrepetitions>5</dyn:numberofrepetitions> <dyn:timeseries> <dyn:atomictimeseries gml:id="weekday"> <tsml:timeseriestvp> <tsml:metadata> <tsml:timeseriesmetadata> <tsml:basetime frame = #localreference >00:00:00</tsml:baseTime> <tsml:spacing>pt1h</tsml:spacing> </tsml:timeseriesmetadata> </tsml:metadata> <tsml:point> <tsml:measurementtvp> <tsml:value>39.97</tsml:value> </tsml:measurementtvp> </tsml:point>... </tsml:timeseriestvp> </dyn:atomictimeseries> <dyn:timeseries> </dyn:timeseriescomponent> </dyn:component> <dyn:component> <dyn:timeseriescomponent> <dyn:numberofrepetitions>1</dyn:numberofrepetitions> <dyn:timeseries> <dyn:atomictimeseries gml:id="saturday"> <dyn:dynamicdatatvp> <tsml:timeseriestvp>... </tsml:timeseriestvp> </dyn:dynamicdatatvp> </dyn:atomictimeseries> </dyn:timeseriescomponent> </dyn:component> </dyn:compositetimeseries> </cityobjectmember> Dynamizers - CityGML Handling Relative Time in Patterns - TVP Encoding Timeseries for weekdays Timeseries for Saturdays Local Reference System 20

21 Dynamic Data from Sensors Another important source of dynamic data may also be sensor services. Two popular standards OGC Sensor Observation Services (SOS) Open standard, part of OGC Sensor Web Enablement (SWE) Allows querying real-time sensor data and sensor data timeseries. Observation responses are encoded in O&M standard OGC SensorThings API Very lightweight standard to interconnect the Internet of Things devices, data and applications over the web Built on OGC SWE and O&M standards Provides REST services and compact data encodings in JSON format Source : Source : Dynamizers - CityGML 21

22 Integrating Sensors and Observations By linking sensors with Dynamizers Such links basically mean that a specific dynamic value for a city object property is measured by a specific sensor (service) Dynamizers represent these direct links to sensors and observations utilizing different requests. in case of OGC SOS: DescribeSensor and GetObservation In order to get the dynamic data, requests to the sensor services must be performed By modeling sensor observations within Dynamizers Sensor observations are typically encoded in O&M format. Dynamizers provide explicit support of O&M, which allows representing sensor observation values Hence, the result of an SOS GetObservation request can directly be embedded (i.e. stored inline) within the Dynamizer Dynamizers - CityGML 22

23 Linking Sensors with Dynamizers Introducing new data type Sensor Connection Attributes <<datatype>> SensorConnection + servicetype :stringattribute + linktoobservation :URI[] + linktosensor: URI[] + sensorid :stringattribute servicetype e.g. SOS 2.0 or SensorThings API linktoobservation link to observation data (e.g. in case of SOS: GetObservation HTTP GET request, result encoded in O&M) linktosensor link to sensor description, (e.g. in case of SOS: DescribeSensor HTTP GET request, result encoded in SensorML) sensorid identifies the specific sensor device for the linked observation data within the sensor description for example, one SOS and its SensorML description can comprise multiple sensor devices producing individual streams of observations Dynamizers - CityGML 23

24 gml:abstractfeature +sensorlocation AbstractCityObject Dynamizer + attributeref :URI + startpoint :TM_Position + endpoint :TM_Position Dynamizer (3rd Stage) Sensor Connection +linktosensor 0..n SensorConnection + servicetype :stringattribute + linktoobservation :URI[] + linktosensor: URI[] + sensorid : stringattribute +dynamicdata AbstractTimeseries 1 TimeseriesComponent + repetitions:integer + additionalgap :TM_Duration[] 1..* +component {ordered} AtomicTimeseries CompositeTimeseries TimeseriesML:: TimeseriesDR +dynamicdatatdr +dynamicdatatvp TimeseriesML:: TimeseriesTVP Further classes of TimeseriesML have been omitted here for better readability Dynamizers - CityGML 24

25 Example for a Sensor Connection Sensor (PV Panel) building1_roofsurface1 building1 <cityobjectmember> <Building gml:id = "building1"> <gen:doubleattribute name = PV_generated_Power"> <gen:value>61578</gen:value> </gen:doubleattribute>... <RoofSurface gml:id = "building1_roofsurface1 > </RoofSurface>... </Building> </cityobjectmember> <cityobjectmember> <dyn:dynamizer gml:id = "HeatDemandTimeseries" > <dyn:attributeref>//roofsurface[@gml:id ='building1_roofsurface']/doubleattribute[@name = 'HeatDemand']/gen:value </dyn:attributeref> <dyn:startpoint> t00:00:00z</startpoint> <dyn:endpoint> t00:00:00z</endpoint> <dyn:linktosensor> <dyn:sensorconnection> <dyn:sensorid>... </dyn:sensorid> <dyn:servicetype>... </dyn:servicetype> <dyn:linktoobservation>... </dyn:linktoobservation> <dyn:sensorlocation xlink:href= #building1_roofsurface1 /> </dyn:sensorconnection> </dyn:linktosensor> </dyn:dynamizer> <cityobjectmember> Image source : Dynamizers - CityGML 25

26 Example GetObservation request of SOS Query: Get Observation for a sensor for a specific property (temperature in this example) between a given time period n&featureofinterest=dht22_sensor_munich&procedure=dht22_sen sor&observedproperty=temperature_dht22&temporalfilter=om:phen omenontime, t09:00:00z/ t12:00:00z Structure of the request is instance) REQUEST=GetObservation (SOS Request parameter) SERVICE=SOS&VERSION=2.0.0 (Service of the request) PROCEDURE=DHT22_Sensor (Procedure of the sensor) temporalfiler= T09:00:00Z/ T12:00:00Z Dynamizers - CityGML 26

27 Example DescribeSensor Request of SOS Query: Describe sensor according to SensorML standard ION=2.0.0&PROCEDURE=DHT22_Sensor&procedureDescriptionFor mat= Structure of the request is instance) REQUEST=DescribeSensor (SOS Request parameter) SERVICE=SOS&VERSION=2.0.0 (Service of the request) PROCEDURE=DHT22_Sensor (Procedure of the sensor) DescriptionFormat= SensorML (Description Format of the sensor) Dynamizers - CityGML 27

28 Dynamizer linking to Sensor Observation Service <cityobjectmember> <dyn:dynamizer gml:id = LinkingSensor" > <dyn:attributeref>.... </attributeref> <dyn:startpoint> t00:00:00z</startpoint> <dyn:endpoint> t00:00:00z</endpoint> <dyn:linktosensor> <dyn:sensorconnection> <dyn:sensorid = DHT22_Sensor <dyn:servicetype = SOS <dyn:linktoobservation xlink:href = " webapp/service?service=sos&version=2.0.0&request=getobservation&featureof Interest=Sensor_Munich&procedure=DHT22_Sensor&observedProperty=Temperature_DHT22 &temporalfilter=om:phenomenontime, t09:00:00z/ t12:00:00z"/> <dyn:linktosensor xlink:href = DHT22_Sensor&procedureDescriptionFormat= </dyn:sensorconnection> <dyn:linktosensor> </dyn:dynamizer> </cityobjectmember> Dynamizers - CityGML 28

29 Enriching Dynamizers with Sensor Observations Sensor responses are encoded in OGC Observations & Measurements (O&M) standard O&M Observation is modelled as a Feature within the context of General Feature Model [ISO 19101, ISO 19109] Observation feature binds a result to a feature of interest Observation uses a procedure to determine the value of the result, which may involve a sensor or an observer Analytical procedure Simulation, or Other numerical processes Dynamizers - CityGML 29

30 Enriching Dynamizers with Sensor Observations Example SOS Response Format <sos:getobservationresponse> feature collection contains multiple observations Each observation response is defined by sos:observationdata Response is encoded according to om:om_observation, which is a feature type <sos:getobservationresponse> <sos:observationdata> <om:om_observation gml:id="o_24581"> <om:type xlink:href=" <om:phenomenontime> <gml:timeinstant gml:id="phenomenontime_24581"> <gml:timeposition> t09:00:18.000z</gml:timeposition> </gml:timeinstant> </om:phenomenontime> <om:resulttime xlink:href="#phenomenontime_24581"/> <om:procedure xlink:href="dht22_sensor"/> <om:observedproperty xlink:href="temperature_dht22"/> <om:featureofinterest xlink:href="dht22_sensor_munich" xlink:title="dht22_sensor_munich"/> <om:result>27.7</om:result> </om:om_observation> </sos:observationdata> </sos:getobservationresponse> Key-Value Pair om_phenomenontime, om:result om_resulttime, om:result Dynamizers - CityGML 30

31 +sensorlocation gml:abstractfeature AbstractCityObject Dynamizer + attributeref :URI + startpoint :TM_Position + endpoint :TM_Position Dynamizer (4th Stage) O&M data as a further representation for AtomicTimeseries +linktosensor 0..n SensorConnection + servicetype :stringattribute + linktoobservation :URI[] + linktosensor: URI[] + sensorid : stringattribute +dynamicdata AbstractTimeseries 1 TimeseriesComponent + repetitions:integer + additionalgap :TM_Duration[] 1..* +component {ordered} TimeseriesML:: TimeseriesDR +dynamicdatatdr AtomicTimeseries +dynamicdatatvp +observation Data TimeseriesML:: TimeseriesTVP SOS::GetObservationResponse + observationdata :OM_Observation[1..*] CompositeTimeseries context AtomicTimeseries inv: dynamicdatadr xor dynamicdatatvp xor observationdata Dynamizers - CityGML 31

32 Ex.: Dynamizer with embedded SOS Response <cityobjectmember> <dyn:dynamizer gml:id = SOSResponse" > <dyn:attributeref>.... </attributeref> <dyn:startpoint> t00:00:00z</startpoint> <dyn:endpoint> t00:00:00z</endpoint> <dyn:dynamicdata> <dyn:atomictimeseries> <dyn:observationdata> <sos:getobservationresponse> <sos:observationdata> <om:om_observation gml:id="o_24581"> <om:type xlink:href=" <om:phenomenontime> <gml:timeinstant gml:id="phenomenontime_24581"> <gml:timeposition> t09:00:18.000z</gml:timeposition> </gml:timeinstant> </om:phenomenontime> <om:resulttime xlink:href="#phenomenontime_24581"/> <om:procedure xlink:href="dht22_sensor"/> <om:observedproperty xlink:href="temperature_dht22"/> <om:featureofinterest xlink:href="dht22_sensor_munich" xlink:title="dht22_sensor_munich"/> <om:result>27.7</om:result> </om:om_observation> </sos:observationdata> </sos:getobservationresponse> </dyn:observationdata> </dyn:atomictimeseries> </dyn:dynamicdata> </dyn:dynamizer> </cityobjectmember> Dynamizers - CityGML 32

33 Combining Dynamic Data from Different Sources CityGML feature attributes may comprise of dynamic data from different sources Possible scenario: the data for energy consumption of a building can be represented by tabulated data from an external file for time period A statistical pattern for time period B direct access to a smart meter/sensor reading for time period C Our approach allows defining multiple Dynamizers for the same CityGML feature attribute for non-overlapping time periods A B C Dynamizers - CityGML 33

34 Dynamic data from different sources CityGML Building Dynamizer 1 Dynamizer 2 <cityobjectmember> Dynamizer 3 <Building gml:id = "building1"> <gen:doubleattribute name = ElecDemand"> <gen:value = /> </gen:doubleattribute> </Building> </cityobjectmember> <cityobjectmember> <dyn:dynamizer gml:id = ElecDemandTimeseriesDR" > <dyn:attributeref>..... </dyn:attributeref> <dyn:startpoint> t00:00:00z</startpoint> <dyn:endpoint> t00:00:00z</endpoint> <dyn:dynamicdata> <dyn:atomictimeseries> <dyn:dynamicdatadr> </dyn:dynamicdatadr> </dyn:atomictimeseries> </dyn:dynamicdata> </dyn:dynamizer> </cityobjectmember> <cityobjectmember> <dyn:dynamizer gml:id = ElecDemandTimeseriesTVP" > <dyn:attributeref>..... </dyn:attributeref> <dyn:startpoint> t00:00:00z</startpoint> <dyn:endpoint> t00:00:00z</endpoint> <dyn:dynamicdata> <dyn:atomictimeseries> <dyn:dynamicdatadr> </dyn:dynamicdatadr> </dyn:atomictimeseries> </dyn:dynamicdata> </dyn:dynamizer> </cityobjectmember> CSV file Domain-Range Tabulated Data Sensor Observation Timeline Jan-15 Feb-15 Mar-15 Apr-15 May-15 Jun-15 Jul-15 Aug-15 Sep-15 Oct-15 Nov-15 Dec-15 <cityobjectmember> <dyn:dynamizer gml:id = SensorObservation" > <dyn:attributeref>..... </dyn:attributeref> <dyn:startpoint> t00:00:00z</startpoint> <dyn:endpoint> t00:00:00z</endpoint> <dyn:dynamicdata> <dyn:atomictimeseries> <dyn:observationdata> </dyn:observationdata> </dyn:atomictimeseries> </dyn:dynamicdata> </dyn:dynamizer> </cityobjectmember> 34

35 Implementation as CityGML 2.0 ADE Currently being implemented and tested as an Application Domain Extension (ADE) for CityGML 2.0 Allows Dynamizers to be used with current version 2.0 of CityGML any property of any CityGML feature can be assigned dynamic values including geometries and appearances Dynamizer is a subclass of AbstractCityObject and, thus, a feature type, which can be accessed over an OGC Web Feature Service. Dynamizers should be retrievable (e.g. from a WFS) together with the objects they are referring to hence, we need an additional association from the class AbstractCityObject to the Dynamizer class this way, CityObjects with dynamic contents can directly refer to their Dynamizers Dynamizers - CityGML 35

36 Dynamizer ADE for CityGML 2.0 +sensorlocation gml:abstractfeature AbstractCityObject <<ADE>> <<ADEElement>> AbstractCityObject Dynamizer + attributeref :URI + startpoint :TM_Position + endpoint :TM_Position +dynamizers 0..* +linktosensor 0..n SensorConnection + servicetype :stringattribute + linktoobservation :URI[] + linktosensor: URI[] + sensorid : stringattribute +dynamicdata AbstractTimeseries 1 TimeseriesComponent + repetitions:integer + additionalgap :TM_Duration[] 1..* +component {ordered} TimeseriesML:: TimeseriesDR +dynamicdatatdr AtomicTimeseries +dynamicdatatvp +observation Data TimeseriesML:: TimeseriesTVP SOS::GetObservationResponse + observationdata :OM_Observation[1..*] CompositeTimeseries context AtomicTimeseries inv: dynamicdatadr xor dynamicdatatvp xor observationdata Dynamizers - CityGML 36

37 Possible Scenarios for Implementation FME CityGML+Dynamizers may be generated using FME FME Workbench can be made a WFS using FME Server WFS can be provided to specific applications/use cases however we still need to check, whether an FME Server based WFS implementation could serve CityGML + ADE data 3DCityDB and Web Feature Service However, currently, 3DCityDB and its WFS do not support ADEs Work already in progress by TU Munich for ADE support in 3DCityDB Dynamizers - CityGML 37

38 Summary Dynamizers support multiple dynamic representations Timeseries encoded in Time-value Pair Timeseries encoded in Domain-Range OGC SOS response as Observations & Measurements Absolute and relative time Mappings of missing or multiple attribute values utilizing interpolation and aggregation methods Supporting complex patterns based on statistics and general rules Linking external sensors Linking sensor observations and descriptions Providing location of sensors as city objects Dynamizers - CityGML 38

39 Future Work Investigation of Timeseries encoded in external files such as CSV GMLCOV supports defining URLs to external files in the range set We assume that tabulation within CSV file is supported already by TimeseriesML, but examples are missing so far Modeling links to sensors that comply to other standards like OGC SensorThings, Hypercat/SenML, FIWARE Development of XML Schema for Dynamizer ADE for all the features See how Energy ADE Timeseries could directly be represented by using <AbstractTimeSeries> from Dynamizers as basic data type (which includes patterns) Dynamizers - CityGML 39