CityGML is an open data model for 3D city models that allows for extensions through Application Domain Extensions (ADEs). This presentation discusses plans to create two new ADEs for the i-SCOPE project to model solar energy potential and inclusive routing. Requirements for noise modeling and mobility will also be examined to determine if portions can be included in new or existing ADEs. A roadmap is proposed to collaboratively develop the new ADEs, test them, create documentation, and train stakeholders.

1. Presented by: Carsten Rönsdorf

2. Planned extension in the context of i-SCOPE

3. 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.

4. Modularisation
...
CityGML Core
OGC GML 3.1.1
Appearance
Generics
Application Domain Extensions (ADE)
Building
CityFurniture
CityObjectGroup
LandUse
Relief
Transportation
Vegetation
WaterBody
Tunnel
Bridge
…
iSCOPEsolar
iSCOPEmobility

5. 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)

6. 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

7. 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?

8. 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

9. 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

10. 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.

11. 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

12. 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).

13. 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.

14. 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

15. 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

16. Software clients
Profiles for different clients needed?
2D
3D
Mobile tablet
Mobile phone

17. 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

18. 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.

19. 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