t3.2 application domain extention (ade)

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

Presented by: Carsten Rönsdorf

interoperable Smart City services through an Open Platform for urban Ecosystems


Planned extension in the context of i-SCOPE

interoperable Smart City services through an Open Platform for urban Ecosystems


What is CityGML?

CityGML is an open data model and XML-based format for

the storage and exchange of virtual 3D city models. It is an

application schema for the Geography Markup Language

version 3.1.1 (GML3), the extendible international

standard for spatial data exchange issued by the Open

Geospatial Consortium (OGC) and the ISO TC211.


Modularisation

...

CityGML Core

OGC GML 3.1.1

Appearance

Generics

Application Domain Extensions (ADE)

Bui

ldin

g

City

Fur

nitu

re

City

Obj

ectG

roup

Land

Use

Rel

ief

Tra

nspo

rtat

ion

Veg

etat

ion

Wat

erB

ody

Tun

nel

Brid

ge …

iSC

OP

E s

olar

iSC

OP

E m

obili

ty

City

Obj

ectG

roup


Features of CityGML

Geospatial information model (ontology) for

urban landscapes based on the ISO 191xx

family

GML3 representation of 3D geometries, based

on the ISO 19107 model

Representation of object surface characteristics

(e.g. textures, materials)


Spirit of Modularisation

• Keep it simple

• Reuse what‘s already there

• Guidance: Avoid nested ADEs at all cost

-> don‘t create an ADE that depends on existing one

(such as noise), but copy the content and change

the namespace


Generics or ADE

Suggested convention:

Create a separate ADE for a particular use case with

a joint requirements set from all partners. Don’t

allow generic attributes at this stage.

If a particular partner has a very specific

requirement, which other don‘t want to share for a

good reason or develop additional requirements as

the model is developed and tested, the use of

Generic attributes will be allowed.

Can we agree on this?


When does an ADE need to be finalised?

• Dependency on software development and other

project activities, milestones and deliveries

• Continuous improvement throughout project to

optimise ADE for wider dissemination

• lock-down ADE model for software

implemmentation


Customization

Need to create iSCOPE specific code-lists, i.e. For

classifications that all project partners are

mandated to utilise.

Examples

Building

- Class

- Function

- Usage

- RoofType


Customization

For every ADE it will be advisable to agree the

definition of CityGML object types in the spirit of a

high level ontology or a feature concept dictionary

and publish this alongside the ADE. The creation of

feature catalogues targeted at the different use

cases will also be benefical as it bundles the

information of the CityGML profile into an easy to

understand deliverable.


Use case: Noise

• Requirements document suggest modelling noise

measurements as points in overlay map

Recommendation: Model these measurements in

CityGML (very easy to do) instead

• additional attributes for computed results, such

as average noise levels needed


CityGML Noise ADE

The calculation of noise levels from a road requires information about the traffic flow, the heavy vehicle percentage, the speed limits, the road surface types and the road gradient.

The noise level depends on the distance between point of emission and reception, as well as on reflection (e.g. building facades) or shielding effects (e.g. noise barriers).

The noise level is calculated separately for the day (06.00-18.00), the evening (18.00-22.00) and the night (22.00-06.00).

As the noise level is calculated at a height of 4m and as the influence of vertical reflecting surfaces is considered (e.g. noise barriers and buildings), a multitude of geodata in the third dimension is necessary.

Specific thematic data are required, for example : • Digital Terrain Model with 10m grid, • 3D building models with their thematic attributes (e.g. reflection,

inhabitants), • 3D road data with their thematic attributes (e.g. traffic flow, heavy vehicle

percentage, speed limit, type of road surface, road gradient, width of a road),

• 3D noise barriers and their thematic attributes (e.g. reflection).


Is the noise ADE suitable?

Need to carry out detailed mapping of

requirements.

It is likely that we will need to create an iSCOPE

noise idea based on the existing one as a template.


Use case Energy (Solar)

• Need for additional building attributes (radiation,

CO2 savings, investment etc.)

• Visualise building heat loss: use of appeance

model (no need for ADE)

• Examine if more detailed interface to cost

models is necessary

• Use of appearance model, for instance for heat

loss data and visualisations


Use case Mobility

• Is CityGML Routing model sufficient? -> alterations for

pedestrian navigation and different mobility restrictions ->

inclusive routing

• Indoor / Outdoor navigation

• Points to change mode of transport (OS term of “ferry

terminals“)

• Additional objects such as Pedestrian crossing or Public

Transport Stations, Barriers, Stairs, PoIs

• Speed Limits and other general attribution for

transportation infrastructure

• Store buffers and other processing/analysis result?

• Examples for representation of transportation objects in

different LoDs are needed


Software clients

Profiles for different clients needed?

2D

3D

Mobile tablet

Mobile phone


Approach

Agree cut-off dates, milestones and

communicate/monitor dependencies

Split noise/solar from mobility and create 2

separate work streams

Different development and test teams


ADEs to be developed in i-SCOPE

Creation of two new ADEs (Application Domain Extension)

relevant to the domains subject of the pilots

• solar energy potential assessment

• inclusive routing

The ADEs will be made publicly available to the community.


Roadmap

Noise/Energy(Solar)

• Collate Detailed use case

requirements (i.e. exactly which

attributes are needed)

• Create small project team (GI, OS,

MO, …) to implement ADE

• Test ADE + appearance model

• Create feature catalogue

• Disseminate and train (also around

appearance model)

Mobility

• Discuss and describe core navigation

concepts required

• Map these to CityGML and engage in

discussion with OGC CityGML SWG

• Collate Detailed used case

requirements

• Create project team (GI, OS, MO, …)

to implement what can go into an

ADE

• Test ADE

• Create feature catalogue

• Disseminate and train

t3.2 application domain extention (ade)

Technology