I scope noisemodel

Noise Domain Model:
Measurements, Modelling and Mapping
Debbie Wilson – Snowflake Software
(on behalf Ordnance Survey)

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:

UC: NoiseTube – Citizen Participation
Noise Measurements
http://www.noisetube.net

UC: NoiseTube – Citizen Participation
http://www.noisetube.net

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
Requirements
How was it
measured?
Noise Exposure
Measurement

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
Requirements
How was it
measured?
Noise Exposure
Measurement
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 Observations
Profiling 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
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
OGC Coverages 2.0
TrajectoryObservation TimeSeries OGC WaterML 2.0
GridObservation RectifiedGridCoverage or
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
«featureType»
Process
«voidable»
+ documentation :DocumentCitation [0..*]
+ inspireld :Identifier
+ name :CharacterString [0..1]
+ processParameter :ProcessParameter [0..*]
+ responsibleParty :RelatedParty [1..*]
+ type :CharacterString
«FeatureType»
observation::OM_Process
«dataType»
ProcessParameter
+ description :CharacterString [0..1]
+ name :ProcessParameterNameValue
s
+generatedObservation
0..*
ProcessUsed +procedure
1
class Process
«voidable
+ docum
+ inspire
+ name
+ proce
+ respon
+ type
«FeatureType»
observation::OM_Observation
+ phenomenonTime :TM_Object
+ resultTime :TM_Instant
+ validTime :TM_Period [0..1]
+ resultQuality :DQ_Element [0..*]
+ parameter :NamedValue [0..*]
Base Types 2::DocumentCitation
+ name :CharacterString
«voidable»
+ shortName :CharacterString [0..1]
+ date :CI_Date
+ link :URL [1..*]
+ specificReference :CharacterString [0..*]
+ d
+ n
«codeList»
ProcessParameterNameValue
tags
asDictionary = true
extensibility = any
vocabulary =
xsdEncodingRule = iso19136_2007_INSPIRE_Extensions
0..*
+relatedObservation 0..*
0..*
ProcessUsed +proced

Procedures: SensorML and INSPIRE Process
INSPIRE Observation – Process is intended to provide an alternative
lightweight model for describing the procedure compared to
SensorML
«featureType»
Process
«voidable»
+ documentation :DocumentCitation [0..*]
+ inspireld :Identifier
+ name :CharacterString [0..1]
+ processParameter :ProcessParameter [0..*]
+ responsibleParty :RelatedParty [1..*]
+ type :CharacterString
«FeatureType»
observation::OM_Process
«dataType»
ProcessParameter
+ description :CharacterString [0..1]
+ name :ProcessParameterNameValue
s
0..*
ProcessUsed +procedure
1
class Process
«voidable
+ docum
+ inspire
+ name
+ proce
+ respon
+ type
«FeatureType»
+ phenomenonTime :TM_Object
+ resultTime :TM_Instant
+ validTime :TM_Period [0..1]
+ resultQuality :DQ_Element [0..*]
+ parameter :NamedValue [0..*]
Base Types 2::DocumentCitation
+ name :CharacterString
«voidable»
+ shortName :CharacterString [0..1]
+ date :CI_Date
+ link :URL [1..*]
+ specificReference :CharacterString [0..*]
+ d
+ n
«codeList»
ProcessParameterNameValue
tags
asDictionary = true
extensibility = any
vocabulary =
xsdEncodingRule = iso19136_2007_INSPIRE_Extensions
0..*
+relatedObservation 0..*
0..*
ProcessUsed +proced
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: NoiseTrajectoryObservation
TimeSeries Result for Trajectory
Observation
TimeSeries Result for Trajectory
Observation
SamplingCoverageObservation
«featureType»
Trajectory and Profile Observations::
TrajectoryObservation
«featureType»
NoiseTrajectoryObservation
«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
Observations::
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
Observation - Trajectory Observation
1. result must be a TimeSeries
2. each point in the result must be a
TimeLocationValueTriple
3. phenomenonTime must be a TM_Period
4. featureOfInterest must be a
SF_SamplingCurve
NOTE: A Specialised NoiseTrajectoryObservation has been
developed to support the requirements of the NoiseTube
+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 Observation
Grid Observation Result - INSPIRE RectifiedGridCoverage
«featureType»
Gridded Observations::
GridObservation
«FeatureType»
Sampling Coverage Observation::
SamplingCoverageObservation
«FeatureType»
coverageObservation::
OM_DiscreteCoverageObservation
«FeatureType»
Constraints for INSPIRE Grid Observation:
1. The Result shall be a RectifiedGridCoverage
2. phenomenonTime must be a TM_Instant
3. featureOfInterest must be a SF_SamplingSolid or
SF_SamplingSurface
«featureType»
Coverages (Domain and Range)::
RectifiedGridCoverage
constraints
{domainIsRectifiedGrid}
{grid points shall coincide with grid cell centres}
«featureType»
CoverageByDomainAndRange
+ coverageFunction :CoverageFunction [0..1]
+ domainSet :Any
+ rangeSet :Any [0..*] {ordered}
«union»
CoverageFunction
+ ruleDefinition :CharacterString
+ ruleReference :URI
+ gridFunction :GridFunction
«featureType»
Coverages (Base)::Coverage
+ metadata :Any [0..*]
+ rangeType :RecordType
«dataType»
Coverages (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

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 ADE
Candidate Application Schema
• Noise ADE developed as an example ADE in CityGML 2.0
specification

Buildings
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]
+ lod2MultiCurve :GM_MultiCurve [0..1]
+ lod4MultiSurface :GM_Surface [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 mistake
4. Attributes such as buildingReflection should use a codelist rather than
CharacterString to ensure consistency.

Transport
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]
+ lineage :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..*]
Issues identified with the existing Noise ADE:
1. Change the type boolean to Boolean
2. 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 Furniture
CityGML 2.0 Noise ADEclass 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]
+ lod1ImplicitRepresentation :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
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
tags
codeList = http://www.iscopeproject.net/codeList/ContourPropertyType
extensibility = any
xsdEncodingRule = 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
+metadata
0..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
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 Mapclass Context Diagram: Heat Maps
«FeatureType»
SurfaceHeatMap
+ loD0_Surface :GM_MultiSurface
«type»
Records and Class Metadata::
Any
{root}
«FeatureType»
CityGML ADE: Time Varying
Properties::
«metaclass»
GF_PropertyType
{root}
«FeatureType»
GriddedHeatMap
constraints
{/* result must be a RectifiedGridCoverage */
inv: self.result.oclIsKindOf(RectifiedGridCoverage)}
CoverageByDomainAndRange
«featureType»
RectifiedGridCoverage
+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
«FeatureType»
Properties::
«metaclass»
GF_PropertyType
{root}
«type»
Any
{root}
AbstractBuilding
«featureType»
Building::Building
+noiseExposure 0..*
+phenomenon 1 +result 1
City Object – Noise Exposure
Example: Building Noise Exposure

class Buildings
«ADEEleme...
Building
«FeatureType»
Properties::
«metaclass»
GF_PropertyType
{root}
«type»
Any
{root}
AbstractBuilding
«featureType»
Building::Building
+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
«ADEEleme...
Building
«FeatureType»
Properties::
«metaclass»
GF_PropertyType
{root}
«type»
Any
{root}
AbstractBuilding
«featureType»
Building::Building
«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

I scope noisemodel

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a I scope noisemodel

Semelhante a I scope noisemodel (20)

Último

Último (20)

I scope noisemodel

Notas do Editor