CityJSON and its usability at a national scale

Presentation at the "3D city modelling workshop", an event organized by 3D building production -ad hoc group working under the Nordic cooperation in the fields of spatial data and land administration (https://norden.lmi.is/).

Transcript

1. Hugo Ledoux TU Delft CityJSON and its usability at a national scale 3D city modelling workshop Nordic mapping agencies 2021-09-29
2. 2 Data model a GML encoding 3 encodings 3D City DB
3. CityJSON v1.0 3 1. "Building" 2. "BuildingPart" 3. "BuildingInstallation" 4. "Road" 5. "Railway" 6. "TransportSquare" 7. "TINRelief" 8. "WaterBody" 9. "PlantCover" 10. "SolitaryVegetationObject" 11. "LandUse" 12. "CityFurniture" 13. "GenericCityObject" 14. "Bridge" 15. "BridgePart" 16. "BridgeInstallation" 17. "BridgeConstructionElement" 18. "Tunnel" 19. "TunnelPart" 20. “TunnelInstallation” 21. “CityObjectGroup” • OGC community standard • all modules of CityGML v2.0 are mapped 💪 • software for full conversion CityGML <-> CityJSON • several software support it • Extensions (ADEs) are possible, and simplified
4. Same information as CityGML, but in JSON format 4 { "type": “CityJSON", "version": “1.0”, "metadata": { "referenceSystem": "urn:ogc:def:crs:EPSG::7415", }, "CityObjects": { "id-1": { "type": "Building", "attributes": { "measuredHeight": 22.3, "roofType": "gable", "owner": “Elvis Presley" }, "geometry": [ { "type": "MultiSurface", "boundaries": [ [[0, 3, 2, 1]], [[4, 5, 6, 7]], [[0, 1, 5, 4]] ] } ] } }, "vertices": [ [23.1, 2321.2, 11.0], [111.1, 321.1, 12.0], ... ], "appearance": { "materials": [], "textures":[], "vertices-texture": [] } } human-readable file computers prefer this over XML ~6X compacter than CityGML
5. Why an alternative encoding? 5 TL;DR • developers don’t like nor want to use XML • the OGC is moving away from XML at a surprisingly quick pace • CityGML XML-encoding is very complex and not web-friendly
6. “But my CityGML dataset is on the web!?” 6
7. 7 Usable for who? 1. for developers 2. for GIS specialists 3. for laypersons
8. National scale = huge datasets CityJSON is 6X compacter than XML-files
9. One example: Zürich LoD2 buildings 9 CityGML = 3.0GB (but 1GB of spaces/CRs/tabs!) CityJSON = 292MB Compression == 7.1X
10. Compression factor == ~6X 10 Compression (v0.6) file CityGML size (original) CityGML size (w/o spaces) textures? CityJSON CityJSON compressed compression factor CityGML demo "GeoRes" 4.3MB 4.1MB yes 582KB 524KB 8.0 CityGML v2 demo "Railway" 45MB 34MB yes 4.5MB 4.3MB 8.1 Den Haag "tile 01" 23MB 18MB no, material 3.1MB 2.9MB 6.2 Montréal VM05 56MB 42MB yes 5.7MB 5.4MB 7.8 New York LoD2 (DA13) 590MB 574MB no 110MB 105MB 5.5 Rotterdam Delfshaven 16MB 15MB yes 2.8MB 2.6MB 5.4 Vienna 37MB 36MB no 5.6MB 5.3MB 6.8 5
11. 3D BAG: all 10M+ buildings in the Netherlands 11 https://3dbag.nl
12. LoD 2.2 
 reconstruction 3D BAG is based on open datasets 12 Point cloud (AHN3) Footprint (BAG) + X 10,000,000 100% automatic
13. 3 different LoDs 13
14. 3D BAG is tiled into *small* and *manageable* datasets 14 BAG polygons Quadtree Max 3500 buildings per tile
15. Whole Netherlands in 3D is available in CityJSON 15 ~1000 tiles of 5km X 6.25km 10M buildings (in LoD1) Average tile size was 2.5GB #FAIL
16. Download is simple and fast 16 Stats last 2 weeks (~32000 downloads) CityJSON 56% OBJ 23% GPKG 21%
17. We were very careful about geometric validity 17 soon 98% valid
18. Amsterdam put our data in their Unity online platform within days 18
19. We reached non-geo people 19
20. People outside our field used the data 20 Historical cadastre Shadow analysis
21. Several wrote guides to convert the data to BIM 21
22. GIS specialists do not all use/have FME: Python parsing is very easy 22 CityJSON makes developers happy (and thus productive)
23. CityJSON is ready for machine learning 23 new!
24. What about CityGML v3? 24 Ready in a few weeks
25. thank you. h.ledoux@tudelft.nl 3d.bk.tudelft.nl/hledoux Hugo Ledoux https://cityjson.org