I scope noisemodel

i-SCOPE - interoperable Smart City services through an Open Platform for urban Ecosystems

Noise Domain Model: Measurements, Modelling and Mapping

Debbie Wilson – Snowflake Software (on behalf Ordnance Survey)

interoperable Smart City services through an Open Platform for urban Ecosystems


Overview

• Following slides provide a detailed summary description of the Noise Domain Model

• Measurements• Modelling• Mapping

• Plus proposed generic CityGML ADE for:• Adding time-varying properties to City Objects • New City Objects: ‘Heat Map’ for visualising thematic

properties that vary over space and time


Noise Domain Model

• Develop a model that meets the requirements for:– Open Data Exchange– 2D and 3D Visualisation

• Applications:– Citizen participation in measuring noise exposure (NoiseTube)– Monitoring /Assessment of noise exposure

• Noise simulation modelling (END Directive)

– Noise Exposure Mapping for citizen engagement and decision-making

• Strategic Noise Maps (END Directive)• 2D/3D visualisation of noise exposure (NoiseTube)


Noise Domain Model

Measurement Modelling Mapping

Ancillary data: needed as input to

noise simulation modelling

3 Viewpoints:


Noise Measurements


UC: NoiseTube – Citizen ParticipationNoise Measurements

http://www.noisetube.net

http://www.noisetube.net/


UC: NoiseTube – Citizen Participation




UC: NoiseTube – Citizen Participation




Individual Measurement Sessions Post-Processed Aggregated Model Noise Exposure

UC: NoiseTube – Visualising Noise Exposure


Result

Location

Time

Ancillary Info

Feature of Interest

Post-processing

Error removal

Noise values

Parameter

Summary Stats/ Aggregation

Model

What was measured?

User SensorInformation

RequirementsHow was it measured?

Noise ExposureMeasurement


Noise Measurements Model

Objective: Extend existing models where possible

Candidate Application Schema:Observations and Measurements

ISO 19156: Observations and Measurements

INSPIRE Observations – Specialised Observations:Point, Trajectory and Gridded Observations

Procedures OGC SensorML 2.0

INSPIRE Observations - Process

Results OGC Coverages 2.0

OGC WaterML 2.0 - TimeSeries

OGC SWE Common


12

OM_Observation: an EVENT whose RESULT is an estimate of a value of some PROPERTY of some THING obtained using a specified

PROCEDURE …

ISO19156 Observations and Measurements


Result

Location

Time

Ancillary Info

Feature of Interest

Post-processing

Error removal

Noise values

Parameter

Summary Stats/ Aggregation

Model

What was measured?

User SensorInformation

RequirementsHow was it measured?

Noise ExposureMeasurement

result

featureOfInterest

observedProperty

procedureprocedure

result


Profiling ISO19156 Observations and Measurements

14

ISO 19156 ‘Observations and measurements’ provides a generic framework for describing both the observing event and the results of the observation. It is applicable

to a wide range of scientific and technical domains.

The generic nature of this standard means that it requires further specialisation to constrain aspects of the model …


INSPIRE Specialised ObservationsProfiling ISO19156 Observations and Measurements

Defines 3 types of Specialised Observation based on the Result Type. These extend the example ISO 19156 specialised observations:

• Gridded Observation

• Trajectory or Profile Observations

• Point Observations

INSPIRE Specialised Observations constrain

the result, featureOfInterest and

phenomenonTime


• Result is an Any type – so...it can be anything!

Encoding the Observation Result

Not easy to implement or ensure

consistency

....Need to define what type to use in your Application Schema

INSPIRE Specialised Observation

Result Type Implementation Schema

PointObservation DiscretePointCoverage OGC Coverages 2.0

PointTimeSeriesObservation TimeSeries OGC WaterML 2.0

MultiPointObservation MultiPointCoverage OGC Coverages 2.0

ProfileObservation RectifiedGridCoverage or ReferencableGridCoverage

OGC Coverages 2.0

TrajectoryObservation TimeSeries OGC WaterML 2.0

GridObservation RectifiedGridCoverage or ReferencableGridCoverage

OGC Coverages 2.0


• Result is an Any type – so...it can be anything!

Encoding the Observation Result

Not easy to implement or ensure

consistency

....Need to define what type to use in your Application Schema

INSPIRE Specialised Observation

Result Type Implementation Schema

PointObservation DiscretePointCoverage OGC Coverages 2.0

PointTimeSeriesObservation TimeSeries OGC WaterML 2.0

MultiPointObservation MultiPointCoverage OGC Coverages 2.0

ProfileObservation RectifiedGridCoverage or ReferencableGridCoverage

OGC Coverages 2.0

TrajectoryObservation TimeSeries OGC WaterML 2.0

GridObservation RectifiedGridCoverage or ReferencableGridCoverage

OGC Coverages 2.0

Question: Should Noise Measurements re-use/extend INSPIRE Specialised Observations?

Recommendation - YES


Procedures: OGC SensorML and INSPIRE Process

SensorML is a comprehensive, generic model for describing the processes used to estimate the value

of a phenomenon using a sensor

• A measurement process can be described within an external resource and referenced to in the Observation


Procedures: OGC SensorML and INSPIRE Process

INSPIRE Observation – Process is intended to provide an alternative lightweight model for describing the procedure compared to SensorML

class Process

«featureType»Process

«voidable»+ documentation :DocumentCitation [0..*]+ inspireld :Identifier+ name :CharacterString [0..1]+ processParameter :ProcessParameter [0..*]+ responsibleParty :RelatedParty [1..*]+ type :CharacterString

«FeatureType»observation::OM_Process

observ ation::OM_Observ ation

+ phenomenonTime :TM_Object+ resultTime :TM_Instant+ validTime :TM_Period [0..1]+ resultQuality :DQ_Element [0..*]+ parameter :NamedValue [0..*]

Base Types 2::DocumentCitation

+ name :CharacterString

+ shortName :CharacterString [0..1]+ date :CI_Date+ link :URL [1..*]+ specificReference :CharacterString [0..*]

«dataType»ProcessParameter

+ description :CharacterString [0..1]+ name :ProcessParameterNameValue

ProcessParameterNameValue

tagsasDictionary = trueextensibility = anyvocabulary = xsdEncodingRule = iso19136_2007_INSPIRE_Extensions

0..*

+relatedObservation 0..*

+generatedObservation

0..*

ProcessUsed +procedure

1

class Process

Process

+ documentation :DocumentCitation [0..*]+ inspireld :Identifier+ name :CharacterString [0..1]+ processParameter :ProcessParameter [0..*]+ responsibleParty :RelatedParty [1..*]+ type :CharacterString

observation::OM_Process





«voidable»+ shortName :CharacterString [0..1]+ date :CI_Date+ link :URL [1..*]+ specificReference :CharacterString [0..*]

ProcessParameter


«codeList»ProcessParameterNameValue


0..*



0..*


1


Procedures: SensorML and INSPIRE Process

INSPIRE Observation – Process is intended to provide an alternative lightweight model for describing the procedure compared to SensorML

class Process

«featureType»Process

«voidable»+ documentation :DocumentCitation [0..*]+ inspireld :Identifier+ name :CharacterString [0..1]+ processParameter :ProcessParameter [0..*]+ responsibleParty :RelatedParty [1..*]+ type :CharacterString

«FeatureType»observation::OM_Process





+ shortName :CharacterString [0..1]+ date :CI_Date+ link :URL [1..*]+ specificReference :CharacterString [0..*]

«dataType»ProcessParameter


ProcessParameterNameValue


0..*



0..*


1

class Process

Process

+ documentation :DocumentCitation [0..*]+ inspireld :Identifier+ name :CharacterString [0..1]+ processParameter :ProcessParameter [0..*]+ responsibleParty :RelatedParty [1..*]+ type :CharacterString

observation::OM_Process





«voidable»+ shortName :CharacterString [0..1]+ date :CI_Date+ link :URL [1..*]+ specificReference :CharacterString [0..*]

ProcessParameter


«codeList»ProcessParameterNameValue


0..*



0..*


1

Recommendation 1 – Use SensorML for describing Sensor Systems:

• It is more mature and comprehensive• Provides flexibility in the depth of info you can provide


Proposed Noise Measurements Model

• Two data exchange requirements: – Source noise exposure measurements– Aggregated/modelled noise exposure measurements

1. Source noise exposure measurements:– Time series collected at mobile locations (NoiseTube)

– Need to extend to include summary statistics

Recommendation 1 – Use INSPIRE Specialised Observation – Trajectory Observation


NoiseTrajectoryObservation class Context Diagram: NoiseTrajectoryObserv ation

TimeSeries Result for TrajectoryObservation

TimeSeries Result for TrajectoryObservation

SamplingCoverageObservation

«featureType»Trajectory and Profile Observ ations::

TrajectoryObserv ation

«featureType»NoiseTrajectoryObserv ation

«DataType»NoiseTubeStatistics

+ count :Integer+ lengthOfTrack :Length+ maxLAeq :Measure+ meanLAeq :Measure+ minLAeq :Measure

constraints{UoM of maxLAeq shall be given in dBA}{UoM of minLAeq shall be given in dBA}{UoM of meanLAeq shall be given in dBA}

«dataType»Trajectory and Profile

Observ ations::TimeLocationValueTriple

+ location :GM_Position

«DataType»SummaryStatistics

CVT_TimeInstantValuePair

«DataType»Timeseries::

AnnotatedTimeValuePair

+ geometry :TM_Position+ value :Record

CVT_DiscreteTimeInstantCoverage

«Type»Timeseries::Timeseries

+ temporalExtent :TM_Period

Constraints for INSPIRE Specialised Observ ation - Trajectory Observ ation

1. result must be a TimeSeries2. each point in the result must be a

TimeLocationValueTriple3. phenomenonTime must be a TM_Period4. featureOfInterest must be a

SF_SamplingCurve

NOTE: A Specialised NoiseTrajectoryObservation has been developed to support the requirements of the NoiseTube application to include the summary statistics that are automatically calculated from the measurement set.

+summaryStatistics 0..1

+collection 0..*

+point 0..*

NOTE: a SF_SamplingCurve feature must also be generated representing the trajectory

For an aggregated/modelled trajectory observation the INSPIRE TrajectoryObservation should be

used


2. Aggregated/modelled noise exposure measurements• Post-processing modelling may generate generalised noise exposure

measurements for an area of interest:– Regular gridded data – overlay over terrain model or city model

– Around Road, Rail, Airport, Industry (see Noise Mapping Model)

Proposed Noise Measurements Model

Recommendation 1 – Use INSPIRE Specialised Observation – Grid Observation


class Context Diagram: Gridded Noise Observ ation

Grid Observation Result - INSPIRE RectifiedGridCoverage

«featureType»Gridded Observ ations::

GridObserv ation

«FeatureType»Sampling Cov erage Observ ation::

SamplingCov erageObserv ation

«FeatureType»cov erageObserv ation::

OM_DiscreteCov erageObserv ation

«FeatureType»observ ation::OM_Observ ation

Constraints for INSPIRE Grid Observation:

1. The Result shall be a RectifiedGridCoverage2. phenomenonTime must be a TM_Instant3. featureOfInterest must be a SF_SamplingSolid or

SF_SamplingSurface

«featureType»Cov erages (Domain and Range)::

RectifiedGridCov erage

constraints{domainIsRectifiedGrid}{grid points shall coincide with grid cell centres}

«featureType»Coverages (Domain and Range)::

CoverageByDomainAndRange

+ coverageFunction :CoverageFunction [0..1]+ domainSet :Any+ rangeSet :Any [0..*] {ordered}

«union»Cov erages (Domain and Range)::

Cov erageFunction

+ ruleDefinition :CharacterString+ ruleReference :URI+ gridFunction :GridFunction

«featureType»Coverages (Base)::Coverage

+ metadata :Any [0..*]+ rangeType :RecordType

«dataType»Cov erages (Domain and Range)::GridFunction

+ sequenceRule :CV_SequenceRule [0..1]+ startPoint :Integer [0..*] {ordered}

NOTE: The GridObservation shall be directly imported from the INSPIRE Coverage Model without any addition extensions for Noise.

GridObservation


Noise Modelling


Strategic Noise Mapping (END Directive)

Noise Modelling

Inputs Modelling Process Output


• Inputs for modelling road noise exposure

– Digital Terrain Model (10m grid)– Population

Noise Modelling

Traffic Roads Buildings/Furniture Noise Exposure

Traffic flow surface Material Reflectivity facades Lden

% Heavy Vehicles gradient height Lday

Speed limits width Noise barriers Levening

Lnight


CityGML 2.0 Noise ADECandidate Application Schema• Noise ADE developed as an example ADE in CityGML 2.0

specification pkg Package Diagram: CityGML Noise ADE

«leaf»NoiseBuilding

+ Building

(from Noise_ADE)

«leaf»NoiseCityFurniture

+ CityFurniture

+ NoiseCityFurnitureSegment

+ NoiseCityFurnitureSegmentType

(from Noise_ADE)

«leaf»NoiseRoad

+ NoiseRailwaySegment

+ NoiseRoadSegment

+ Railway

+ Road

+ Train

(from Noise_ADE)

«applicationSchema»Noise_ADE

+ NoiseBuilding

+ NoiseCityFurniture

+ NoiseRoad

(from CityGML_ADE)


BuildingsCityGML 2.0 Noise ADE

class Context Diagram - Noise Simulation Inputs - Buildings

«ADEElement»NoiseBuilding::Building

+ buildingReflection :CharacterString [0..1]+ buildingReflectionCorrection :Measure [0..1]+ buildingLDenMax :Measure [0..1]+ buildingLDenMin :Measure [0..1]+ buildingLNightMax :Measure [0..1]+ buildingLNightMin :Measure [0..1]+ buildingLDenEq :Measure [0..1]+ buildingLNightEq :Measure [0..1]+ buildingHabitants :NonNegativeInteger [0..1]+ buildingAppartments :NonNegativeInteger [0..1]+ buildingImmissionPoints :IntegerList [0..1]+ remark :CharacterString [0..1]

AbstractSite

«featureType»Building::AbstractBuilding

+ class :BuildingClass [0..1]+ function :BuildingFunction [0..*]+ usage :BuildingUsage [0..*]+ yearOfConstruction :Year [0..1]+ yearOfDemolition :Year [0..1]+ roofType :RoofType [0..1]+ measuredHeight :Length [0..1]+ storeysAboveGround :int [0..1]+ storeysBelowGround :int [0..1]+ storeyHeightsAboveGround :MeasureList [0..1]+ storeyHeightsBelowGround :MeasureList [0..1]+ lod0FootPrint :GM_MultiSurface [0..1]+ lod0RoofEdge :GM_MultiSurface [0..1]+ lod1Solid :GM_Solid [0..1]+ lod1MultiSurface :GM_MultiSurface [0..1]+ lod1TerrainIntersection :GM_MultiCurve [0..1]+ lod2Solid :GM_Solid [0..1]+ lod2MultiSurface :GM_MultiSurface [0..1]+ lod2MultiCurve :GM_MultiCurve [0..1]+ lod2TerrainIntersection :GM_MultiCurve [0..1]+ lod3Solid :GM_Solid [0..1]+ lod3MultiSurface :GM_MultiSurface [0..1]+ lod3MultiCurve :GM_MultiCurve [0..1]+ lod3TerrainIntersection :GM_MultiCurve [0..1]+ lod4Solid :GM_Solid [0..1]+ lod4MultiSurface :GM_Surface [0..1]+ lod4MultiCurve :GM_MultiCurve [0..1]+ lod4TerrainIntersection :GM_MultiCurve [0..1]

Issues identified with the existing Noise ADE:

1. The Building ADEElement class should generalise the CityGML Building object not AbstractBuilding

2. The attribute names could be made more succinct by removing the 'building' prefixes

3. buildingAppartments contains a spelling mistake4. Attributes such as buildingReflection should use a codelist rather than

CharacterString to ensure consistency.


TransportCityGML 2.0 Noise ADE

class Context Diagram: Noise Simulation Input - Road and Railway

«ADEElement»NoiseRoad::Railway

«ADEElement»NoiseRoad::Road

AbstractTransportationObject

«featureType»NoiseRoad::NoiseRoadSegment

+ mDay :Measure [0..1]+ mEvening :Measure [0..1]+ mNight :Measure [0..1]+ mDay16 :Measure [0..1]+ pDay :Measure [0..1]+ pEvening :Measure [0..1]+ pNight :Measure [0..1]+ pDay16 :Measure [0..1]+ dtv :Measure [0..1]+ speedDayPkw :Speed [0..1]+ speedEveningPkw :Speed [0..1]+ speedNightPkw :Speed [0..1]+ speedDayLkw :Speed [0..1]+ speedEveningLkw :Speed [0..1]+ speedNightLkw :Speed [0..1]+ roadSurfaceMaterial :CharacterString [0..1]+ roadSurfaceCorrection :Measure [0..1]+ distanceCarriageway :Length [0..1]+ distanceD :Length [0..1]+ bridge :boolean [0..1]+ tunnel :boolean [0..1]+ roadGradientPercent :Measure [0..1]+ lod0BaseLine :GM_Curve [0..1]+ l ineage :CharacterString [0..1]


«featureType»NoiseRoad::NoiseRailwaySegment

+ railwaySurfaceMaterial :CharacterString [0..1]+ railwafSurfaceCorrection :Measure [0..1]+ bridge :boolean [0..1]+ crossing :boolean [0..1]+ curveRadius :Length [0..1]+ additionalCorrectionSegment :Measure [0..1]+ lod0BaseLine :GM_Curve [0..1]

«featureType»NoiseRoad::Train

+ trainType :CharacterString [0..1]+ trainTypeCorrection :Measure [0..1]+ brakePortionDay :Measure [0..1]+ brakePortionEvening :Measure [0..1]+ brakePortionNight :Measure [0..1]+ lengthDay :Length [0..1]+ lengthEvening :Length [0..1]+ lengthNight :Length [0..1]+ speedDay :Speed [0..1]+ speedEvening :Speed [0..1]+ speedNight :Speed [0..1]+ additionalCorrectionTrain :Measure [0..1]

«featureType»Transportation::Road

«featureType»Transportation::Railway


«featureType»Transportation::TransportationComplex

+ class :TransportationComplexClass [0..1]+ function :TransportationComplexFunction [0..*]+ usage :TransportationComplexUsage [0..*]+ lod0Network :GM_Complex [0..*]+ lod1MultiSurface :GM_Surface [0..1]+ lod2MultiSurface :GM_Surface [0..1]+ lod3MultiSurface :GM_Surface [0..1]+ lod4MultiSurface :GM_Surface [0..1]

Issues identified with the existing Noise ADE:

1. Change the type boolean to Boolean2. Codelists should be used where possible rather than

CharacterString (e.g. surfaceMaterial, train types)3. Is there are requirement for Segments or could the model

be simplified by using Road and Rail features only?

+noiseRailwaySegmentProperty 0..*

+noiseRoadSegmentProperty

0..*

+usedBy

0..*


City FurnitureCityGML 2.0 Noise ADE class Context Diagram: Noise Simulation Inputs - City Furniture

«ADEElement»NoiseCityFurniture::

CityFurniture

AbstractCityObject

«featureType»NoiseCityFurniture::NoiseCityFurnitureSegment

+ type :NoiseCityFurnitureSegmentType [0..1]+ reflection :CharacterString [0..1]+ reflectionCorrection :Measure [0..1]+ height :Length [0..1]+ distance :Length [0..1]+ lod0BaseLise :GM_Curve [0..1]

«codeList»NoiseCityFurniture::

NoiseCityFurnitureSegmentType

AbstractCityObject

«featureType»CityFurniture::CityFurniture

+ class :CityFurnitureClass [0..1]+ function :CityFurnitureFunction [0..*]+ usage :CityFurnitureUsage [0..*]+ lod1Geometry :GM_Object [0..1]+ lod2Geometry :GM_Object [0..1]+ lod3Geometry :GM_Object [0..1]+ lod4Geometry :GM_Object [0..1]+ lod1TerrainIntersection :GM_MultiCurve [0..1]+ lod2TerrainIntersection :GM_MultiCurve [0..1]+ lod3TerrainIntersection :GM_MultiCurve [0..1]+ lod4TerrainIntersection :GM_MultiCurve [0..1]+ lod1ImplicitRepresentation :core:ImplicitGeometry [0..1]+ lod2ImplicitRepresentation :core:ImplicitGeometry [0..1]+ lod3ImplicitRepresentation :core:ImplicitGeometry [0..1]+ lod4ImplicitRepresentation :core:ImplicitGeometry [0..1]

Issues identified with Noise ADE:

1. Is there a requirement to model CityFurniture using segments or can multiple CityFurniture objects represent a single real-world object (e.g. noise barrier)? This would simplify the model as only has one geometry.

+noiseCityFurnitureSegmentProperty 0..*


Noise Mapping


Noise Mapping

END Strategic Noise Mapping:• Enable assessment of exposure of populations to noise• Inform development of action plans to reduce noise exposure and

protect existing quiet areas• inform and engage the public in the development of noise action plans


END Strategic Noise Maps

• Environmental noise exposure has to be strategically mapped in the following areas: – Agglomerations - large, densely populated urban areas –

(UK: > 250,000 people with a population density of < 500 /km2 )

– Around roads with more than six million vehicle passages a year

– Around railways with more than 60,000 train passages a year

– Around airports with more than 50,000 movements a year


Noise Exposure Maps

• These are typically thematic maps “Heat Maps”, contours, grids or city objects whose values may be:– Noise Exposure: Laeq (dBA), Lden, Lnight– Statistics: Total or % population exposed


Candidate Application Schema• Basic overlaying of noise exposure information

– ISO 19156 – Observations and Measurements– OGC Coverages – e.g. RectifiedGridCoverage,

MultiPointCoverage

• Developed Noise Mapping Model:– Contours (Generic)– Generic Models for Time-Varying Properties

• TimeVaryingProperty Model• Heat Map ADE

– City Object – Noise Exposure

Noise Mapping


• Very simple, generic model consisting of a contour line, contour value and contour property type

Noise Contours

Question: Are any other properties required?

class Noise Contours

«FeatureType»ContourLine

+ geometry :GM_Curve+ contourValue :Measure+ contourPropertyType :ContourPropertyType

«CodeList»ContourPropertyType

tagscodeList = http://www.iscopeproject.net/codeList/ContourPropertyTypeextensibility = anyxsdEncodingRule = citygml-ade

Example values for ContourPropertyType:

Noise Exposure: minLAeq, maxLAeq, meanLAeq, Lden, Lnight etc.....


• Real-world phenomenon like noise expose vary both over time and space

• Starting point develop a generic model for time-varying properties

Modelling Time-Varying Property

Design Principles:• Needs to be simple• Can be used within for multiple purposes:

• Thematic Noise Mapping “Heat Maps”• City Object Noise Exposure Maps• Other thematic areas: Energy -Solar Potential

• Based on existing O&M Modelling pattern as has similar requirements


class CityGML ADE: Time Varying Properties

«FeatureType»TimeDependentVariable

+ referenceTime :TM_Object

«metaclass»General Feature Model::

GF_PropertyType{root}

«type»Records and Class

Metadata::Any{root}

Metadata entity set information::MD_Metadata

«FeatureTyp...observation::OM_Process

+phenomenon 1

Metadata

+metadata0..1

Process

+procedure 0..1

+result 1

TimeDependentVariable : has a RESULT which is an estimate of a value of some PROPERTY belonging to a feature obtained using a specified PROCEDURE

…

Modelling Time-Varying Property

NOTE: there is no featureOfInterest as the TimeDependentVariable

is intended to be a complex property of a

feature

NOTE: The multiplicity of procedure and metadata

has been relaxed


Thematic Heat Map• The Time-Varying Property can be used within a

Thematic Heat Map feature• A HeatMap feature has been developed as a new

CityGML City Object LOD0• 2 Specialised types:

– SurfaceHeatMap– GriddedHeatMap


Thematic Heat Map class Context Diagram: Heat Maps

«FeatureType»SurfaceHeatMap

+ loD0_Surface :GM_MultiSurface

«type»Records and Class Metadata::

Any{root}

«FeatureType»CityGML ADE: Time Varying

Properties::TimeDependentVariable




«FeatureType»GriddedHeatMap

constraints{/* result must be a RectifiedGridCoverage */inv: self.result.oclIsKindOf(RectifiedGridCoverage)}

CoverageByDomainAndRange

«featureType»Cov erages (Domain and Range)::

RectifiedGridCov erage

+result 1+phenomenon

1

+result 1


• Time-varying properties such as Noise Exposure/Solar Potential can be added as thematic attributes to City Objects

Adding Time-Varying Properties to City Objects

• Model should be flexible enough to allow objects to have multiple time-varying properties

• Time-varying properties such as Noise Exposure/Solar Potential can be added as thematic attributes to City Objects


class Buildings

«ADEEleme...Building







Any{root}

AbstractBuilding

«featureType»Building::Building

+noiseExposure 0..*

+phenomenon 1 +result 1

City Object – Noise ExposureExample: Building Noise Exposure


class Buildings








Any{root}

AbstractBuilding


+noiseExposure 0..*



Profiling the Result: • A business rule should be defined for

each time-varying property to constrain the result type

• Result type can be existing record/coverage type:

• SWE Common – Data Array• Coverage


class Buildings








Any{root}

AbstractBuilding


«Type»NoiseExposureDataRecord

+ minLAeq :Measure+ maxLAeq :Measure+ meanLAeq :Measure

result must be a NoiseExposureDataRecord/* result must be a NoiseExposureDataRecord*/inv: self.result.oclIsKindOf(NoiseExposureDataRecord)

+noiseExposure 0..*



Profiling the Result: • A business rule should be defined for

each time-varying property to constrain the result type

• Result type can be existing record/coverage type:

• SWE Common – Data Array• Coverage

• Or, can explicitly define a <<type>> class within the domain model


Conclusions

• Action 1: Need to share with modelling team to agree proposed generic CityGML ADE for time-varying properties and Heat Map

• Action 2: Noise Domain Expert Review to identify what noise exposure parameters would be published in a heat map or on a City Object– Needed to develop controlled vocabulary of phenomenon– Agree whether SWE Common Data Array would be suitable for

encoding result or define concrete result class

• Action 3: Identify which City Objects would form a Noise Exposure – City Objects ADE

Date post:	24-May-2015
Category:	Technology
Upload:	debbie-wilson
View:	175 times
Download:	0 times

I scope noisemodel

Technology