Our issues with CityGML v3

Presentation summarising the issues that TU Delft (https://3d.bk.tudelft.nl), Geonovum (https://www.geonovum.nl), NUS (https://www.arch.nus.edu.sg), and NL Kadaster (https://www.kadaster.nl) have with the current development with the version 3 of CityGML (https://www.citygml.org).

Presented at the 108th OGC Technical Committee meeting in Stuttgart, Germany

Transcript

1. Our issues with CityGML v3 2018-09-12
2. 2 • We collaborate a lot with practitioners inside and outside NL; and have lot of own implementation experiences with CityGML 2.0 • CityGML v2 is complete, but complex, and therefore not always easy to implement • community is looking at us to improve • our concerns for a simple, implementable 3D standard -> this presentation • raised issues in SWG and discussed with OGC staff, SGW chairs, SWG members, OGC members
3. Geonovum position on CityGML 3.0 development OGC TC meeting Stuttgart Friso Penninga Geonovum
4. Background: Geonovum & 3D ▪ 2010 – 2018: pilots, experiments, … ▪ 2019 / 2020: need for national 3D standards – 3D base data set of NL ~ 1:1.000 – 3D input models for noise analysis – local governments need alignment / interoperability – Hence: the need for 3D standardisation ▪ Geonovum has to advise the Ministry on these standards
5. Current position ▪ I want to advise CityGML 3.0 ▪ But, I need a standard that: – avoids complexity as much as possible – can be implemented easily and will be implemented widely – reduces file sizes as much as possible ▪ and – consensus that CityGML 3.0 has these characteristics.
6. My problem ▪ I cannot form my final opinion without: – discussion in the SWG on pros and cons of design choices (both IRL and on mailing list and Github) – implementation experiments to validate assumptions on characteristics – test data sets illustrating how certain concepts will work in practice.
7. The pudding analogy ▪ So, if CityGML 3.0 is the pudding, I see: – people working hard on the recipe for the pudding – virtually no discussion on the recipe, thus making it hard for others to contribute to the recipe – virtually no test samples of the pudding – the wish to decide on the recipe, before it is used to actually bake the pudding – the wish to decide on the recipe based on a timeline rather than on its taste
8. My position: let’s bake and taste (a lot)! ▪ E.g. Is CityGML 3.0 easy to implement? Let’s find out first!
9. summary of our issues 9 1. current process is not democratic/transparent 2. new features add complexity: worth it? 3. Software should be part of the process ! we thus fear usability and adoption by practitioners will diminish (and it is already an issue) This is a summary of an email thread on the CityGML-SWG list entitled ‘Reconsideration of the concept of “spaces” in CityGML v3?’ from June 2018
10. 1. process is not democratic & transparent
11. 1. process not transparent 11 • only ~final results presented at SWG meetings • UML and datasets online often weeks after meeting • presentations are directly followed by votes • no time for community to review and understand key concepts • GitHub “Issues” was just activated, but in our opinion this is not how it is meant to work
12. 9 relevant issues opened > 1mo ago still no answer
13. issues agenda point! ≠
14. –Steve Smyth, 20min ago “We begin with Change Request” 14
15. –Steve Smyth, 20min ago “We begin with Change Request” 15 • CR are a massive step: they mean highlighting what has been done is wrong. • Issues can be constructive suggestion • few CRs, 15+ Issues in last days
16. • GitHub == unique hub for all work-in-progress + discussions • not used to upload final results, it is the dev hub where *everything* is stored (yes also work-in-progress) • Questions? Bugs? Comments? —> Issue • SWG meetings can only discuss stuff that has been made available beforehand 16 Solution #1
17. 2. new features add complexity: worth it?
18. 2. new features add complexity: worth it? 18 • more features ≠ improvement • adding features == extra complexity for: • developers: need to update/change code • practitioners: need to understand the new features • “good design is as little as possible”
19. 2. “Spaces” add complexity: worth it? 19 • new concept “Spaces” adds complexity • it has not been explained nor tested yet • we do not know what problem they solve • seem focused on minor issues; most applications do not need them • before there can be a vote, there should be a debate based on facts see GitHub issue #13 for a nice example
20. 2. “Spaces” solving integration BIM-CityGML? 20
21. 2. “Spaces” solving integration BIM-CityGML? 21 • diff geometrical paradigms used (CSG vs b-rep) • outer walls/surfaces cannot be automatically identified • rooms, walls as surfaces (part of a building volume) do not exist as concept in IFC
22. 2. new Core Module is getting many new things 22 • “Spaces” • Dynamizers • Point clouds (which can be used to represent a building: LAS/LAZ reader now mandatory if one wants to support CityGML v3) Volker Coors opened issues related to these
23. • Not aiming at adding features, but stripping CityGML from features not used in practice • Presentation about Spaces’ (and other potential features) pros and cons, both from a modeller’s and developer’s point-of-view • We think CityGML should not model all aspects of our 3D reality, we are fine with subset if they mean a usable exchange format 23 Solution #2
24. 3. Software should be part of the development process
25. 3. Software should be part of the process (1/3) 25 • there are no (real) datasets and no software capable to read CityGML v3 • neither was planned before the vote for CityGML v3, because only the data model is up for vote • UML models are abstract beast, to know if they work in practice they need to be tested • W3C would never accepts a standard w/o data+software
26. i p.m FINE fib T9z n.tw y v3 EEN her UML released idea model standard i E i finite.no software data q 3. Software should be part of the process (2/3) 26
27. 3. Software should be part of the process (3/3) 27 • claims that v3 will simplify the life of developers are unfounded and unproven • there are no complete Python or Javascript or C++ parser known to us (also for CityGML v2!) • most developers do not want to replicate the whole CityGML data model, they use CityGML as an exchange format: they parse a file to extract only what they need Volker Coors mentioned this too in his email in German on Monday
28. Quiz: What software would allow me to do this? 28 Take a given CityGML v2 file and: 1. remove one building and replace it by a newer construction; 2. remove all textures (we want to use the model for visibility analysis and these not necessary); 3. save the file to a new CityGML file. • only citygml4j + 3dcitydb • perhaps FME (but need to build that complex workspace) • ArcGIS does not work for this
29. Rotterdam & CityGML 29
30. Rotterdam & CityGML 30 • central hub is all CityGML (3dcitydb used) • however, none of the departments have software supporting CityGML • spatial planning, pipelines, maintenance, etc. all use software they are used to • FME used for conversion -> if users want to modify or edit data, it can’t be written back to the CityGML database • employees think this is a problem CityGML is an exchange format that is used in different apps
31. • software+datasets are mandatory part of the process to develop CityGML v3 • allow “profiles” of CityGML to support the most important parts • thus: release of v3 must be postponed (since it’ll take some time to get there) 31 Solution #3
32. Summary 32 1. More transparency and democracy in the process -> GitHub used actively (not only every 3mo) 2. New features: explanation and are they really needed by community? 3. Software part of development process -> postpone the release of v3
33. CityJSON: TUDelft’s way to contribute 33
34. CityJSON: TUDelft’s way to contribute 34 • several NL companies, governments, and organisations already started investigating CityJSON • flat-schema, compact (~7X compacter), Python/javascript/etc parsers are easy • we already have many software support (visualisation, validation, manipulation, QGIS, web-parser, etc.)
36. thank you. Hugo Ledoux Jantien Stoter Linda van den Brink Friso Penninga Patrick Janssen Filip Biljecki