JGISE  Vol. 6 No. 1 (2022), pp. 11 - 23     |     https://doi.org/10.22146/jgise.78590

## JGISE

## Journal of Geospatial Information Science and Engineering
ISSN: 2623-1182    |    https://jurnal.ugm.ac.id/jgise
Evaluasi Format Data CityGML dan CityJSON untuk Kadaster 3D di Indonesia (Evaluation CityGML and CityJSON Data Format for 3D Cadastre in Indonesia)
Romanza Wiradinata Putra 1 , Trias Aditya 2
1 Mahasiswa Departemen Teknik Geodesi FT-UGM, Indonesia 2 Dosen Departemen Teknik Geodesi FT-UGM, Indonesia
Penulis Korespondensi: Romanza Wiradinata Putra | Email: romanza.w@mail.ugm.ac.id Diterima ( Received ): 24/Oct/2022     Direvisi ( Revised ): 14/Dec/2022    Diterima untuk Publikasi ( Accepted ): 27/Jun/2023

## ABSTRAK
Infrastruktur,  prosedur  serta  rangkaian  kebijakan  perlu  disiapkan  oleh  pemerintah  dalam  rangka  implementasi  kadaster  3D  di Indonesia.  Untuk  mendukung  upaya  pengembangan  sistem  kadaster  3D  di  Indonesia,  terlebih  dahulu  perlu  menyusun  dan mempersiapkan beberapa kebutuhan. Salah satu kebutuhan yang paling mendukung implementasi kadaster 3D di Indonesia adalah terkait dengan penggunaan format data. Oleh karena itu, penelitian ini bertujuan untuk mengevaluasi model CityGML dan CityJSON melalui proses konversi IFC menjadi CityGML dan CityGML ke CityJSON berdasarkan hasil pengecekan dan validasi terhadap setiap fitur dan elemen model CityGML dan CityJSON sehingga dapat memberikan rekomendasi kepada pemerintah dalam menentukan format data yang tepat untuk menyimpan dan memvisualisasikan model kadaster 3D. Data yang digunakan adalah elemen IfcSpace dan IfcWallStandardCase pada  model  IFC  stasiun  MRT  Bundaran  HI  dan  Blok  M  Jakarta.  Konversi  IFC  ke  CityGML  dilakukan  di perangkat eveBIM, FME, dan FZK. Pada masing-masing software dilakukan percobaan untuk membandingkan representasi geometri fitur  dari  model  CityGML  berdasarkan  ada  tidaknya  kesalahan  berupa  penambahan  atau  pengurangan  geometri  fitur.  Dengan demikian dapat dievaluasi model CityGML manakah yang memiliki representasi model 3D paling baik dan software yang paling tepat digunakan untuk  konversi IFC ke CityGML. Dari evaluasi tersebut dapat diketahui pula apakah model CityGML dapat dikonversi menjadi model CityJSON serta apakah model 3D tersebut memiliki kesalahan. Dari hasil penelitian diketahui bahwa model CityGML yang dikonversi  pada perangkat  FME  dan  FZK  memiliki  representasi  geometri fitur  yang  baik  dan  sesuai dengan  geometri  fitur asalnya yaitu model IFC, sedangkan model CityGML hasil konversi eveBIM tidak representatif karena banyak ditemukan kesalahan. Selanjutnya,  hasil  penelitian  menunjukkan  bahwa  visualisasi  model  CityJSON  tidak  dapat  dilakukan  pada  elemen  CityGML  yang direpresentasikan dalam LoD-4. Sampai dengan penelitian ini dilakukan, skema encoding CityGML versi 3 belum ditetapkan sebagai standar resmi sehingga perangkat lunak yang menangani konversi IFC ke CityGML masih menggunakan CityGML versi 2.
Kata kunci : Kadaster 3D, Konversi, IFC, CityGML, CityJSON, Kesalahan, Evaluasi

## ABSTRACT
Infrastructure, procedures and policies need to be prepared by government in context of implementation 3D cadastral in Indonesia. To support development 3D cadastral system in Indonesia, it is first to prepare and organize several requirements. One of them that most support implementation of 3D cadastral in Indonesia is the use of data format. Therefore, this research aims to evaluate process of converting IFC into CityGML and CityGML to CityJSON. Evaluation conducted by checking and validating each feature and element of CityGML and CityJSON model. Based on evaluation, it can provide an overview to relevant agencies to determine appropriate data format to store and visualize 3D cadastre model. This research was conducted using IfcSpace and IfcWallStandardCase elements on the IFC model of the Bundaran HI and Blok M MRT Jakarta station. IFC to CityGML conversion is done with eveBIM, FME, and FZK software. In each software, experiment was conducted to compare the representation of geometry features of the CityGML model based on errors such as addition or subtraction of feature geometry. Thus it can be evaluated which CityGML model has best representation of 3D model and the most appropriate software to convert IFC to CityGML. From the evaluation, it can also be seen whether CityGML model can be converted into a CityJSON model and 3D model has errors. CityGML model converted in FME and FZK has a complete feature geometry representation  and  according  to  original  feature  geometry  in  IFC  model  element,  while  CityGML  model  converted  in  eveBIM  is  not representative because many errors are found. CityJSON model visualization cannot be performed on CityGML elements represented in LoD-4, as adopted by CityGML 2 nd version. Until this research was conducted, the encoding scheme of CityGML 3 rd version has not been established as an official standard so software that handles IFC to CityGML conversion is still using CityGML 2 nd version.
Keywords : 3D Cadastre, Conversion, IFC, CityGML, CityJSON, Error, Evaluation
© Author(s) 2023.  This is an open access article under the Creative Commons Attribution-ShareAlike 4.0 International License ( CC BY-SA 4.0) .

## 1. Pendahuluan
Riset  yang  dilakukan  oleh  Tim  Kajian  Basisdata Kadaster 3D UGM, (2021) menyatakan bahwa salah satu hal yang menjadi kebutuhan untuk mendukung pengembangan  kadaster  3D  adalah  terkait  penggunaan format data objek kadaster 3D. Hal tersebut perlu disiapkan guna  menghindari  permasalahan  yang  berkaitan  dengan interoperabilitas  (berbagi  pakai)  data.  Selain  itu,    format data  menjadi  hal  penting  karena  turut  mendukung kesiapan pengembangan sistem informasi yang mendukung implementasi kadaster 3D. Di Indonesia, saat ini  masing-masing  instansi  masih  menggunakan  data  3D dengan  kepentingan  dan  formatnya  sendiri-sendiri sehingga belum diterapkan  prinsip pertukaran data antar instansi.  Akibatnya,  format  data  3D  seringkali  hanya berlaku  untuk  instansi  tersebut.  Dengan  demikian,  satu objek  3D  dapat  memiliki  lebih  dari  satu  representasi berbeda  yang  tidak  saling interoperable .  Kedepannya, kebutuhan  pertukaran  data  dari  berbagai  instansi  yang terkait  dengan  data  kadaster  3D  sangat  mungkin  terjadi. Oleh karena itu, kajian mengenai kesepakatan penggunaan format  data  model  kadaster  3D  perlu  dilakukan  guna mewujudkan interoperabilitas data antar instansi.
Untuk keperluan kadaster 3D, perlu dipilih format data 3D  yang  memenuhi  beberapa  persyaratan,  seperti kemampuan  untuk  menyimpan  geometri,  atribut  dan topologi  3D,  dapat  menyajikan  model  pada  tingkat kedetilan  yang  berbeda-beda,  terhubung  pada  basisdata untuk  keperluan query serta  dapat  diimplementasikan pada  skema Land  Administration  Domain  Model (LADM) (Atunggal et al., 2020; Sulistyawati dkk, 2019; Sulistyawati dkk,  2018).  Dari  hasil  studi  literatur,  diketahui  bahwa bangunan  dapat  direpresentasikan  menggunakan  model Industry  Foundation  Classes (IFC)  dan City  Geographic Markup Language (CityGML). Kedua format data tersebut sudah  menjadi  standar  internasional  untuk  lingkup  BIM dan GIS, sehingga penggunaan kedua format data tersebut untuk kadaster 3D akan sangat mendukung upaya berbagi pakai data (Noardo et al., 2021).
IFC merupakan format standar penyimpanan data yang dikembangkan  oleh  BuildingSMART  dalam  lingkup  BIM. BIM didefinisikan sebagai sistem, manajemen, metode, atau runutan  pengerjaan  suatu  proyek  yang  diterapkan berdasarkan  informasi  terkait  dari  keseluruhan  aspek bangunan  yang  dikelola  dan  kemudian  diproyeksikan  ke dalam model 3D. Data BIM merupakan sebuah basis  data yang berisikan informasi geometri dan semantik mengenai desain  dan  konstruksi  bangunan  (Solihin  et  al.,  2017). Sementara  itu,  CityGML  merupakan  format  standar penyimpanan  data  yang  dikembangkan  oleh Open Geospatial  Consortium (OGC)  dalam  menyimpan model digital  3D  perkotaan  (Gröger  et  al.,  2012).  CityGML memungkinkan  penggunanya  untuk  menyimpan  dan bertukar  data  spasial  3D  secara  efektif  untuk  berbagai
aplikasi seperti perencanaan kota, kadaster 3D, manajemen fasilitas,  dan  simulasi  lingkungan  (Gröger  and  Plümer, 2012).
Model  IFC  dan  CityGML  dapat  digunakan  untuk identifikasi  unit  properti  yang  akurat,  representasi  batas kadaster  yang  lebih  baik,  dan  visualisasi  bangunan kompleks  yang  terperinci  (Sun  et  al.,  2019). Akan  tetapi, perlu  digaris  bawahi  bahwa  format  data  IFC  tidak  cocok apabila  digunakan  untuk  merepresentasikan  model kadaster  3D.  Ketidaksesuaian  tersebut  terkait  dengan adanya beberapa objek (fitur) pada elemen bangunan yang tidak diperlukan pada model 3D yang disajikan di lingkup GIS terlebih jika terkait dengan kadaster 3D. Atazadeh dkk., (2021) dan Daum  &  Borrmann,  (2014) juga  mengatakan bahwa BIM memiliki keterbatasan dalam hal manajemen, visualisasi  data,  serta  analisis  spasial  di  dalam  sebuah bangunan.  Pada  akhirnya  konversi  IFC  ke  CityGML  perlu dilakukan  guna  menyederhanakan  dan  menghilangkan informasi  dari  model  BIM,  dalam  hal  ini  adalah  IFC, sehingga  lebih  sesuai  dengan  format  CityGML  dalam konteks kadaster 3D (El-Mekawy dkk., 2011).
Berdasarkan  beberapa  uraian  tersebut,  diperlukan kajian lebih lanjut terkait dengan konversi format data dari model  IFC  ke  dalam  CityGML.  Akan  tetapi,  format  data CityGML  memiliki  kelemahan  dalam  hal  visualisasi  dan manajemen  model  data  3D  pada  sebuah website sebab memiliki skema encoding yang kompleks dan tidak efektif serta  memiliki  ukuran  data  yang  besar.  Dalam  model CityGML,  hirarki  untuk  satu  bangunan  sederhana  dapat menjadi  agak  dalam  ( nested )  karena  diterjemahkan  ke dalam  banyak  kelas  yang  bersarang  dan  hirarkis  dalam format XML (Ledoux et al., 2019). Dengan demikian, perlu dilakukan pula konversi model CityGML menjadi CityJSON. Secara  keseluruhan,  penelitian  ini  bertujuan  untuk mengevaluasi model CityGML dan CityJSON melalui proses konversi  berdasarkan  hasil  pengecekan  dan  validasi terhadap  setiap  fitur  dan  elemen  sehingga  dapat memberikan  rekomendasi  kepada  pemerintah  dalam menentukan format data yang tepat untuk menyimpan dan memvisualisasikan model kadaster 3D.

## 2. Data dan Metodologi

## 2.1. Data dan Lokasi
Dalam  penelitian  ini,  data  IFC  yang  digunakan  adalah model 3D stasiun MRT Bundaran HI (BHI) dan stasiun Blok M  (BLM)  yang  sebelumnya  telah  dibuat  pada penelitian yang  dilakukan  oleh  Atunggal  dkk.,  (2020).  Model  IFC tersebut  dalam  format  2x3  dan  dibuat  dari  data as  built drawing (ABD) yang diperoleh dari PT. MRT Jakarta. 2.2. Metodologi
Berikut  ini  merupakan  diagram  alir  pelaksanaan penelitian.

## Gambar 1 Diagram alir penelitian

## Persiapan Data dan Perangkat
Tabel 1 Daftar perangkat lunak
Data dalam format IFC secara umum dapat memodelkan aspek  semantik  hingga  level  yang  sangat  detail,  namun pada  penelitian  ini  semantik  yang  digunakan  sudah disesuaikan dengan kebutuhan kadaster 3D, yaitu elemen IfcSpace dan IfcWallStandardCase. Pemilihan kedua elemen tersebut  mengacu  pada  penelitian  yang  telah  dilakukan
oleh  Hajji  dkk.,  (2021),  Atazadeh  dkk.,  (2019),  Rashidan dkk., (2021), Sun, (2019), serta Oldfield dkk., (2017).
Konversi IFC ke CityGML Model  CityGML  dihasilkan  dari  proses konversi  yang dilakukan  di  perangkat  lunak  eveBIM,  FME,  dan  FZK. Penulis  menggunakan  ketiga  perangkat  tersebut  untuk proses  konversi  sebab  terbukti  mampu  menangani konversi  IFC  menjadi  CityGML.  Hal  tersebut  dibuktikan dengan banyaknya literatur yang menggunakan perangkat lunak FME dan FZK Viewer untuk proses konversi IFC ke CityGML  atau  bahkan  sebaliknya.  Akan  tetapi,  untuk eveBIM sampai saat ini memang masih  jarang ditemukan publikasi yang melibatkan perangkat eveBIM untuk proses konversi.  Alasan  lain  yang  mendasari  pemilihan  ketiga perangkat  lunak  tersebut  adalah  pengguna  dapat  dengan mudah  memperolehnya  di website resmi  masing-masing
perangkat lunak dengan disertai beberapa publikasi yang menjelaskan  metode  konversi  IFC  ke  CityGML  yang digunakan oleh masing-masing perangkat tersebut. Selain itu,  perangkat  lunak  yang  berbasis Generic  User  Interface (GUI)  sehingga  lebih  memudahkan  penggunanya  dalam memahami perintah-perintah untuk konversi data beserta dengan model 3D hasil konversinya.
Adapun tujuan konversi IFC ke CityGML yang dilakukan dengan  menggunakan  3  (tiga)  perangkat  lunak  adalah untuk  mengetahui  perangkat  lunak  manakah  yang  paling cocok  digunakan  untuk  proses  konversi  jika  ditinjau  dari kesalahan  yang  dihasilkan  sehingga  dapat  ditentukan perangkat  lunak  dengan  model  CityGML  yang  memiliki representasi  yang  baik  dan  sedikit  kesalahan.  Selain  itu, penulis  dalam  penelitian  ini  juga  ingin  membuktikan apakah  jenis  perangkat  yang  digunakan  berpengaruh terhadap  ada  tidaknya  kesalahan  yang  dihasilkan  dari proses konversi format data yang ditujukan untuk kadaster 3D. Pada  setiap  perangkat  lunak  dilakukan  beberapa percobaan konversi terhadap salah satu atau kedua elemen IfcSpace dan IfcWallStandardCase .  Hal  ini  dilakukan  agar diperoleh  model  CityGML  dengan  representasi  fitur  yang baik  sehingga  meminimalisir  beberapa  kesalahan. Kesalahan  tersebut  dapat  berupa  fitur  yang  tidak terkonversi  dengan  benar  sebagaimana  sesuai  dengan geometri pada elemen IFC, data atribut yang tidak lengkap, format penamaan ID fitur yang salah, serta adanya elemen CityGML  hasil  konversi  yang  tidak  memiliki  hubungan semantik  dengan  elemen  IFC.  Akan  tetapi  apabila  model CityGML yang dikonversi telah memiliki representasi fitur yang cukup baik, maka tidak perlu dilakukan beberapa kali percobaan.  Pada  penelitian  ini,  representasi  model CityGML  dievaluasi  dari  ada  tidaknya  fitur  yang  tidak lengkap,  berkurang,  atau  bertambah  pada  setiap  elemen CityGML  serta  terhadap  data  atribut  yang  memuat informasi semantik setiap fitur.
1. Konversi model IFC ke CityGML menggunakan eveBIM Konversi  menggunakan  perangkat  lunak  eveBIM dilakukan  dengan  sangat  mudah  karena  pengguna cukup memilih elemen IFC yang hendak dikonversi dan pada akhirnya model CityGML yang dikehendaki sudah dapat  terbentuk.  eveBIM  tidak  menggunakan  skema konversi  dalam  memetakan  elemen  IFC  menjadi CityGML.
Gambar 2 Tampilan saat akan mengkonversi elemen IfcSpace dan IfcWallStandardCase pada software eveBIM
2. Konversi model IFC ke CityGML menggunakan FME Pada  penelitian  ini,  skema  konversi  diperoleh  dari workbench yang  disediakan  secara  terbuka  oleh FME Community ,  (2020)  dan  penelitian  yang  dilaksanakan oleh GeoBIM  benchmark ,  (2019).  Akan  tetapi,  penulis tidak  sepenuhnya  langsung  menggunakan workbench tersebut  untuk  proses  konversi  karena  masih  harus dimodifikasi terlebih dahulu agar skema konversi yang dibangun  dapat  sesuai  dengan  kebutuhan  model  yang hendak dihasilkan dari proses konversi.
Gambar 3 Tampilan skema konversi elemen IFC menjadi elemen CityGML pada FME Workbench
3. Konversi model IFC ke CityGML menggunakan FZK Sebelum  melakukan  konversi  IFC  ke  CityGML menggunakan perangkat lunak FZK, perlu diperhatikan bahwa pada struktur data CityGML terdapat pembagian tingkat kedetilan objek mulai dari LoD-1 sampai LoD-4. Masing-masing  LoD  memiliki  jenis  elemen  IFC  yang dapat dikonversi disertai dengan tipe geometrinya.
Gambar 4 Elemen IfcSpace dan IfcWallStandardCase dikonversi menjadi elemen CityGML pada LoD4

## Konversi CityGML ke CityJSON
Dari ketiga model CityGML yang dikonversi di perangkat lunak  eveBIM,  FME,  dan  FZK,  proses  konversi  kemudian dilanjutkan  dengan  tahapan  konversi  ke  dalam  model CityJSON.  Proses  tersebut  masih  belum  dapat  dipastikan keberhasilannya  mengingat  format  data  CityGML  yang digunakan  masih  menggunakan  versi  2.  Versi  tersebut masih  mengadopsi  konsep  LoD  yang  berbeda  dengan konsep  LoD  yang  diadopsi  oleh  model  CityJSON  sehingga dalam penelitian ini konversi model CityGML ke CityJSON masih  terbatas  pada  percobaan  konversi  saja  dan  bukan ditujukan untuk visualisasi pada sebuah sistem informasi kadaster 3D. Model CityJSON yang telah berhasil dikonversi selanjutnya dilakukan  pengecekan untuk mengetahui ada tidaknya  kesalahan  pada  model  CityJSON  hasil  konversi. Pengecekan  tersebut  berupa  cek  kelengkapan  fitur  dan semantik model CityJSON hasil konversi.

## Validasi Model CityGML dan CityJSON
Model CityGML dan CityJSON hasil konversi selanjutnya divalidasi  terhadap  skema  XML  dan  JSON  serta  terhadap geometri  primitif  penyusun  model  3D  tersebut.  Validasi hanya  dilakukan terhadap  elemen  ruangan  pada  masing- masing  model  CityGML  dan  CityJSON  mengingat  elemen tersebut  memiliki  susunan  geometri  yang  teratur  untuk setiap  fitur-fiturnya.  Sementara  itu,  elemen  dinding  tidak divalidasi  karena  memiliki  bentuk  geometri  yang  tidak teratur.  Selain  itu,  dicek  pula  terkait  ada  tidaknya perbedaan volume elemen ruangan yang terdapat di model
IFC dan CityGML, serta terkait dengan penggunaan sistem koordinat  dan  sistem  tinggi  pada  model  CityGML.  Pada model  CityJSON  tidak  dilakukan  pengecekan  terhadap volume, sistem koordinat, dan sistem tinggi karena model CityJSON  hanya  digunakan  untuk  keperluan  visualisasi model  3D  pada website saja  berbeda  dengan  model CityGML  yang  dilengkapi  dengan  data  atribut  dan perangkat lunak yang mendukung analisis untuk berbagai kebutuhan.

## 3. Hasil dan Pembahasan
3.1. Hasil Konversi Elemen IFC Stasiun Bundaran HI dan Blok M Menggunakan Perangkat Lunak eveBIM Proses  konversi  model  IFC  menjadi  model  CityGML dilakukan  pada  perangkat  lunak  eveBIM  dengan  3  (tiga) kali  percobaan.  Langkah  ini  dilakukan  karena  penulis mendapati adanya perbedaan representasi model CityGML walaupun  jenis  elemen  IFC  yang  dikonversi  sama.  Pada percobaan pertama dan kedua hanya elemen IfcSpace saja yang  dikonversi,  sedangkan  untuk  percobaan  ketiga elemen IfcSpace dan IfcWallStandardCase dikonversi secara bersama-sama. Kedua elemen tersebut dipetakan menjadi elemen  CityGML  secara  berturut-turut  menjadi  elemen ClosureSurface dan WallSurface serta  direpresentasikan pada LoD3MultiSurface sebagaimana terlihat pada Tabel 2 Sementara  itu,  Gambar  5  menyajikan  jumlah  elemen CityGML yang berhasil dikonversi dari model IFC.
Tabel 2 Komponen hasil konversi dari IFC ke CityGML pada objek stasiun BHI dan BLM
Gambar 5 Elemen ClosureSurfaces (kiri) dan elemen WallSurface (kanan)
Pada  percobaan  pertama  dan  kedua,  terlihat  adanya perbedaan  jumlah  elemen  yang  berhasil  dikonversi menjadi elemen CityGML. Perbedaan tersebut terjadi pada
kedua  model  stasiun  BHI  dan  BLM.  Pada  model  CityGML stasiun BHI, elemen ClosureSurface yang mewakili sebuah ruangan  memiliki  jumlah  fitur  yang  berbeda  walaupun telah  dilakukan  dua  kali  percobaan  konversi  terhadap elemen  yang  sama.  Perbedaan  jumlah  fitur  pada  model hasil  konversi  adalah  terkait  dengan  adanya  fitur  yang bertambah  pada  model  CityGML  yang  dikonversi  pada percobaan pertama dan kedua sebagaimana terlihat pada Tabel  3.  Penambahan  fitur  terjadi  karena  kesalahan semantik yaitu adanya elemen daun pintu dan elemen lain yang  bukan  termasuk  elemen IfcSpace yang  ikut terkonversi  menjadi  elemen ClosureSurface .  Pada percobaan  pertama  dan  kedua,  ditemukan  pula  beberapa fitur  pada  elemen ClosureSurface yang  memiliki  bentuk geometri  tidak  sempurna  dan  ada  beberapa  fitur  yang hilang. Akan tetapi seperti yang terlihat pada Tabel 3, kedua model 3D yang dihasilkan dari percobaan 1 dan percobaan 2  masih  tergolong cukup  representatif dalam menyajikan elemen  ruangan. Sementara  itu,  pada  percobaan  yang ketiga,  terjadi  penambahan  dan  pengurangan  fitur  pada model  CityGML.  Fitur  yang  bertambah  ada  pada  elemen ClosureSurface , sedangkan fitur yang berkurang ada  pada elemen WallSurface .  Penambahan  fitur  terjadi  karena terdapat beberapa fitur selain
IfcSpace dan IfcWallStandardCase yang  ikut  terkonversi.  Pada  Tabel  3, terlihat  adanya  elemen  tiang  dan  daun  pintu  yang  ikut terkonversi dengan elemen ClosureSurface dan WallSurface . Sementara  itu,  pengurangan  fitur  terjadi  karena  hampir seluruh fitur dinding memiliki bentuk geometri yang tidak sempurna dan bahkan banyak yang hilang (tidak lengkap). Berikut  merupakan  gambar-gambar  yang  menunjukkan ketiga model CityGML  stasiun BHI  yang dihasilkan dalam percobaan konversi menggunakan perangkat eveBIM.
Tabel 3 Model CityGML Stasiun BHI
Pada  percobaan  menggunakan  model  3D  stasiun  BLM sebagaimana  tersaji  pada  Tabel  4,  model  CityGML  yang diperoleh  dari  hasil  percobaan  pertama  hasilnya  cukup representatif  dalam  mewakili  bentuk  geometri  sebuah ruangan, sedangkan model CityGML yang dihasilkan pada percobaan kedua hasilnya juga cukup representatif hanya saja terdapat kesalahan yaitu adanya fitur daun pintu yang ikut terkonversi menjadi elemen ruangan ( ClosureSurface ). Namun,  model  CityGML  yang  dihasilkan  pada  percobaan ketiga  hasilnya  sangat  tidak  representatif  dalam menyajikan  ruangan  beserta  dengan  batasnya  karena banyak  ditemukan  kesalahan  seperti  elemen  ruang  dan dinding yang memiliki bentuk dan geometri tidak lengkap. Oleh  sebab  itu,  penulis  menyarankan  dalam  hal  konversi model  IFC  ke  CityGML  menggunakan  perangkat  eveBIM, agar  tidak  mengkonversi  beberapa  elemen  IFC  atau CityGML  secara  bersamaan  karena  model  3D  yang dihasilkan akan memiliki lebih banyak kesalahan yang pada gilirannya tidak representatif dalam menyajikan ruang dan batas legal.
Kesalahan  lain  yang  ditemukan  adalah  berkaitan dengan informasi atribut dari model 3D hasil konversi yang juga  tidak  dapat  dipertahankan.  Hal  tersebut  dibuktikan dengan hilangnya informasi yang mendeskripsikan atribut pada  masing-masing  elemen  CityGML.  Adanya  beberapa kesalahan  tersebut  bisa  jadi  disebabkan  karena  adanya keterbatasan  perangkat  lunak  eveBIM  dalam  menyimpan dan  menangani  model  IFC  yang  kaya  akan  informasi semantik untuk objek bangunan sehingga perangkat lunak
kesulitan dalam menerjemahkan (memetakan) setiap fitur dan elemen IFC ke dalam elemen CityGML secara lengkap.
Tabel 4 Model CityGML Stasiun BLM
3.2. Hasil Konversi Elemen IFC Stasiun Bundaran HI dan Blok M Menggunakan Perangkat Lunak FME
Berdasarkan percobaan yang dilakukan, model CityGML yang  dikonversi  menggunakan  FME  lebih  representatif daripada  model  CityGML  yang  dikonversi  menggunakan eveBIM. Hal tersebut  dapat  dilihat  dari kelengkapan fitur pada  masing-masing  elemen  model  3D  hasil  konversi. Setiap  fitur  dan  elemen  IFC  dapat  secara  lengkap  dan sempurna  dikonversi  menjadi  elemen  CityGML.  Penulis juga tidak menemukan adanya fitur yang berkurang, hilang atau  bahkan  memiliki  bentuk  yang  tidak  lengkap (terdegradasi) dari model hasil konversi.
Tabel 5 berikut memperlihatkan bahwa  jumlah elemen bldg:Room dan bldg:WallSurface pada  model  CityGML stasiun BHI dan BLM hasil konversi memiliki jumlah fitur yang sama dengan jumlah fitur asalnya yaitu IfcSpace dan IfcWallStandardCase .  Gambar  6  merupakan  elemen Room dan WallSurface dari model CityGML yang dikonversi pada perangkat FME.
Tabel 5 Komponen Komponen model CityGML stasiun BHI dan BLM
Gambar 6 Elemen Room (kiri) dan elemen WallSurface(kanan)
Akan  tetapi,  penulis  mendapati  adanya  fitur  tidak dikenal  yang  ikut  terkonversi  dan  dipetakan  sebagai elemen dinding ( WallSurface ), padahal jika mengacu pada elemen  aslinya  yaitu IfcWallStandardCase ,  tidak  ada  fitur dinding  yang  memiliki  bentuk  geometri  seperti  pada Gambar  7b.  Beberapa  hal  tersebut  menunjukkan  bahwa model CityGML yang dikonversi pada perangkat lunak FME masih  mengandung  kesalahan  tetapi  tidak  sebanyak sebagaimana  yang  terdapat  pada  model  CityGML  yang dikonversi menggunakan eveBIM.
Gambar 7 (a). Model IFC. (b) model CityGML stasiun BLM
Gambar  8  berikut  ini  menunjukkan  data  atribut  dari elemen Room .  Akan  tetapi,  data  atribut  yang  ditampilkan tidak selengkap sebagaimana yang termuat pada model IFC.
Gambar 8 Data atribut dari elemen Room
3.3. Hasil Konversi Elemen IFC Stasiun Bundaran HI dan Blok M Menggunakan Perangkat Lunak FZK Viewer Berdasarkan  percobaan  yang  telah  dilakukan,  model CityGML  yang  dikonversi  dari  model  IFC  menggunakan perangkat  lunak  FZK  Viewer  lebih  representatif  jika
dibandingkan dengan model CityGML yang dikonversi pada perangkat  eveBIM  dan  FME.  Hal  tersebut  dibuktikan dengan tidak ditemukannya fitur yang hilang atau memiliki geometri  yang  tidak  lengkap  (terdegradasi)  dari  model hasil  konversi.  Sebagaimana  yang  termuat  pada  Tabel  6, jumlah  elemen bdlg:Room dan bldg:WallSurface yang dikonversi  memiliki  jumlah  fitur  yang  sama  dengan  fitur asalnya  yaitu IfcSpace dan IfcWallStandardCase .  Elemen bldg:Room dan bldg:WallSurface yang  dikonversi  pada perangkat lunak FZK dapat dilihat pada Gambar 9.
Tabel 6 Komponen model CityGML stasiun BHI dan stasiun BLM
Gambar 9 Elemen bldg:Room (kiri) dan bldg:WallSurface (kanan)
Hal lain yang mendukung model CityGML hasil konversi FZK Viewer memiliki representasi model paling baik adalah data  atribut  yang  memuat  informasi  semantik  dan geometrik  dari  masing-masing  fitur  masih  dapat  dimuat dengan  lengkap.  Gambar  10  menunjukkan  data  atribut yang termuat di dalam elemen Room . Data atribut tersebut merupakan  informasi  semantik  yang  mendeskripsikan atribut  dari  masing-masing  fitur  pada  elemen  CityGML. Seluruh  data  atribut  tersebut  diperoleh  dari  atribut  data masukan  yaitu  model  IFC,  sedangkan  informasi  terkait besaran  volume  dan  luasan  diperoleh  dari  hasil perhitungan yang dilakukan oleh perangkat lunak.
Gambar 10 Informasi semantik berupa data atribut dari setiap fitur pada elemen CityGML
3.4. Hasil Konversi IFC ke CityGML Terkait Aplikasinya Dalam Kadaster 3D Dalam penelitian ini, ruang  legal diwakili oleh  elemen IfcSpace sehingga tidak memerlukan elemen IfcWallStandardCase dan IfcSlab sebagai  elemen  yang digunakan  untuk  membentuk  ruang  legal.  Kedua  elemen tersebut digunakan apabila tidak tersedia elemen IfcSpace pada  model  3D  bangunan.  Namun,  pada  penelitian  ini model  ruangan  sudah  diwakili  oleh  elemen IfcSpace sehingga  penulis  merekomendasikan  agar  menggunakan elemen IfcSpace sebagai  elemen  utama  yang  mewakili ruang  legal  dan IfcWallStandardCase sebagai  elemen pendukung dalam memvisualisasikan batas antar ruangan. Elemen IfcSlab tidak digunakan sebagai elemen penyusun ruang  legal  yang  membatasi  ruangan  dari  sisi  vertikal sebab  ketinggian  ruangan  pada  masing-masing  lantai stasiun  BLM  menggunakan  tinggi  sebenarnya  yang mengacu  pada  data  potongan  melintang  ABD.  Sementara itu,  tinggi  ruangan  pada  model  3D  stasiun  BHI  masih diestimasi dari tinggi masing-masing lantai sehingga wajar apabila  seluruh  ruangan  yang  terdapat  pada  model  3D stasiun  BHI  terlihat  memiliki  ketinggian  yang  seragam, sedangkan ruangan yang terdapat di model 3D stasiun BLM terlihat  memiliki  tinggi  yang  berbeda-beda.  Berdasarkan Peraturan  Pemerintah  No.  4  Tahun  1988  tentang  Rumah Susun  dan  penelitian  yang  telah  dilakukan  oleh  Tekavec dkk.,  (2021),  batasan  kepemilikan  sebuah  unit  ruangan ditentukan  oleh  permukaan  dinding  bagian  dalam, permukaan  bawah  langit-langit  struktur,  dan  permukaan atas lantai struktur. Dalam penelitian ini, batas kepemilikan sebuah  ruangan  ditentukan  pada  permukaan  dinding bagian dalam sebagaimana terlihat pada Gambar 11 berikut ini.
Gambar 11 Elemen ruangan yang dibatasi oleh dinding bagian dalam
Gambar 12 (a). Elemen ruangan pada model IFC stasiun BHI (b). Elemen ruangan pada model IFC stasiun BLM

## 3.5. Hasil Konversi Model CityGML ke CityJSON
Model CityJSON diperoleh dari model CityGML melalui proses  konversi.  Dari  percobaan  yang  telah  dilakukan, hanya  model  CityGML  hasil  konversi  perangkat  eveBIM yang berhasil dikonversi menjadi model CityJSON. Hal ini disebabkan  karena  elemen  ruangan  dimodelkan  sebagai elemen ClosureSurface pada LoD3MultiSurface . Sementara itu,  model  CityGML  yang  dikonversi  di  perangkat  lunak FME  dan  FZK  tidak  dapat  dikonversi  menjadi  model CityJSON karena seluruh elemen dimoldelkan dalam LoD-4. Perangkat lunak FME merepresentasikan elemen Room dan WallSurface pada LoD4MultiSurface, sedangkan  FZK memodelkan  elemen Room dan WallSurface pada LoD4Solid dan LoD4MultiSurface . Namun demikian model CityGML yang dikonversi dari perangkat  lunak  eveBIM  memiliki  kesalahan  yang  cukup banyak sebagaimana yang telah dijelaskan pada subbab  3 sehingga  model  CityJSON  yang  dikonversi  dari  model CityGML juga akan memiliki banyak kesalahan. Hal tersebut dapat terlihat pada Tabel 7 dan Tabel 8 yang menyajikan perbandingan  model  CityGML  dengan  model  CityJSON. Terlihat bahwa model CityJSON memiliki representasi fitur yang sama dengan representasi fitur pada model CityGML yang  dihasilkan  dari  percobaan  konversi  pada  perangkat eveBIM sehingga pada model CityJSON banyak ditemukan fitur  ruangan  yang  bertambah,  berkurang,  dan  memiliki
geometri  yang  tidak  lengkap.  Model  CityGML  hasil percobaan 2 dipilih karena memiliki representasi fitur yang lebih baik (jelas) jika dibandingkan dengan model CityGML hasil percobaan 3 baik pada model 3D stasiun BHI maupun stasiun BLM. Hal lain yang menunjukkan adanya kesalahan semantik  adalah  seluruh  elemen  ruang  pada  model CityJSON  hanya  memiliki  1  (satu)  ID,  yaitu  pada  elemen Building saja.  Hal  tersebut  jelas sebuah  kesalahan  karena seluruh  fitur  ruangan  dianggap  sebagai  satu  kesatuan elemen  dan  didefinisikan  ke  dalam  satu  objek  bangunan ( Building ). Kesalahan tersebut dapat dilihat pada Gambar 13.
Tabel 7 Model CityGML dan CityJSON stasiun BHI
Tabel 8 Model CityGML dan CityJSON stasiun BLM
Gambar 13 Seluruh elemen Room didefinisikan sebagai satu elemen Building
Perlu  diketahui  bahwa  ruangan yang  menjadi  elemen utama  untuk  merepresentasikan  ruang  legal  pada  model kadaster  3D,  hanya  dapat  dimodelkan  pada  LoD-4  pada format data CityGML versi 2. Sementara itu, CityJSON tidak mendukung representasi elemen CityGML yang dimodelkan  dalam  LoD-4  seperti  halnya  interior  ruangan yang  dimodelkan  sebagai  elemen Room pada LoD4Solid . CityJSON  menggunakan  konsep  LoD  sebagaimana  yang diadopsi  oleh  format  data  CityGML  versi  3.  Format  data CityGML  versi  3  menggunakan  konsep  LoD-0  sampai dengan LoD-3. Elemen interior ruangan pada CityGML versi 3  dapat  dimodelkan  mulai  dari  LoD-1  hingga  LoD-3 sehingga dapat dengan mudah dikonversi dan ditampilkan menjadi  model  CityJSON.  Namun  demikian  sampai penelitian  ini  dilakukan,  skema  ( encoding )  XML  untuk
CityGML  versi  3  masih  belum  ditetapkan  sebagai  standar resmi, sehingga perangkat yang menangani seluruh proses konversi masih menggunakan CityGML versi 2.
3.6. Validasi Model CityGML dan CityJSON
Tabel  9  memuat  hasil  validasi  XML  dan  geometri primitif  terhadap  elemen  ruangan  model  CityGML  yang dikonversi pada perangkat eveBIM, FME, dan FZK Viewer. Secara umum, seluruh skema XML di dalam struktur data CityGML  stasiun  BHI  dan  BLM  hasil  konversi  perangkat FME dan FZK telah sesuai (valid) dengan skema CityGML versi 2. Sementara itu, skema XML yang terdapat di struktur data  CityGML  stasiun  BHI  dan  BLM  hasil  konversi perangkat  eveBIM  masih  ditemukan  kesalahan.  Hal tersebut dapat dibuktikan pada skema XML model CityGML stasiun BHI ditemukan adanya 580 kesalahan, sedangkan pada skema XML model CityGML stasiun BLM terdapat 688 kesalahan.  Kesalahan  tersebut  disebabkan  karena perangkat  eveBIM  masih  menggunakan  cara  yang  salah dalam  mendefinisikan  ID  untuk  setiap  fitur  pada  elemen CityGML sehingga seluruh ID langsung diperoleh dari IFC GUID  yang  mana  susunan  ID  tidak  diawali  oleh  abjad melainkan dengan angka.
Ditinjau  dari  hasil  validasi  terhadap  geometri  primitif model 3D, dapat dilihat pada Tabel 9 bahwa seluruh elemen ruangan yang terdapat di model CityGML yang dikonversi di software eveBIM memiliki geometri primitif MultiSurface yang  benar,  sedangkan  hasil  validasi  terhadap  model CityGML  hasil  konversi software FME  masih  ditemukan beberapa elemen ruang pada model 3D stasiun BHI dengan geometri primitif yang tidak valid. Hal serupa terjadi pula pada  model  CityGML  stasiun  BHI  yang  dikonversi  di software FZK.  Pada  model  CityJSON  yang  diperoleh  dari model CityGML hasil konversi eveBIM, seluruh skema JSON yang  termuat  di  dalam  model  3D  stasiun  BHI  dan  BLM memiliki  skema  CityJSON  yang  benar. Sementara  itu, seluruh  elemen  ruang  pada  model  CityJSON  memiliki geometri primitif yang tidak valid.
Tabel 9 Hasil validasi skema dan geometri primitif model CityGML dan CityJSON
3.7. Pengecekan dan Analisis Hasil Konversi IFC ke CityGML
1. Cek Sistem Koordinat dan Sistem Tinggi Model 3D Setiap fitur pada elemen IFC, yang mana menjadi format  data  masukan  dalam  proses  konversi, didefinisikan  dalam  sistem  koordinat  TM  3 .  Hal tersebut tentu berdampak pada model CityGML yang dikonversi  dari  model  IFC  tersebut,  sehingga  setiap fitur pada elemen CityGML juga akan terdefinisi pada sistem koordinat TM 3 . Perangkat lunak eveBIM, FME, dan  FZK  tidak  mengenali  sistem  koordinat  tersebut. Hal  tersebut  dibuktikan  pada  Gambar  14  yang menyajikan struktur data CityGML yang dikonversi di perangkat eveBIM. Terlihat bahwa koordinat X dan Y pada  masing-masing  fitur  elemen  CityGML  tidak mengacu pada sistem koordinat TM 3  dan koordinat Z  juga  tidak  mengadopsi  tinggi  geometrik  ataupun tinggi ortometrik. Sementara itu, pada model CityGML yang dikonversi pada perangkat lunak FME dan FZK sebagaimana tersaji pada Gambar 15 dan Gambar 16, masih  terikat  pada  sistem  koordinat  TM  3  untuk koordinat  X  dan  Y  serta  menggunakan  tinggi geometrik  untuk  koordinat  Z  sekalipun  perangkat lunak tidak dapat mengenali sistem koordinat TM 3 .
Gambar 14 Geometri pada struktur data CityGML stasiun BHI hasil konversi software eveBIM
Gambar 15 Koordinat X, Y, Z salah satu fitur pada elemen Room hasil konversi software FZK Viewer
Gambar 16 Koordinat X, Y, Z pada model CityGML stasiun BHI dan BLM hasil konversi software FME
2. Cek Volume Model CityGML Ruang  pada  model  IFC  maupun  CityGML  sama- sama  direpresentasikan  oleh  geometri Solid yang mana merupakan geometri tertutup. Oleh karena itu, kedua  elemen  tersebut  dapat  digunakan  untuk mendefinisikan  volume  sebuah  ruang.  Hal  tersebut menunjukkan  bahwa  konversi  format  data  IFC menjadi  CityGML  seharusnya  tidak  mengurangi besaran  volume  dari  model  yang  dihasilkan.  Akan tetapi hal tersebut tidak dapat dianggap sepenuhnya benar, karena penulis menemukan beberapa ruangan pada  model  CityGML  stasiun  BHI  dan  BLM  yang dikonversi dari  model IFC ternyata memiliki volume yang  sedikit  berbeda  dengan  besaran  nilai  volume pada model IFC. Akan tetapi, nilai perbedaan (selisih) volume  tersebut  masih  tergolong  sangat  kecil.  Hal tersebut  dapat  dibuktikan  dengan  rata-rata  selisih volume  antara  model  IFC  dan  CityGML  stasiun  BHI sebesar 0,008 m 3 , sedangkan rata-rata selisih volume pada  model  IFC  dan  CityGML  stasiun  BLM  sebesar 0,589  m 3 .  Pada  model  CityGML  stasiun  BHI  tidak ditemukan elemen ruang yang memiliki selisih volume dengan elemen ruang pada model IFC yang besarnya melebihi 1 m 3 , sedangkan pada model CityGML stasiun BLM  ditemukan  satu  ruangan  yang  memiliki  selisih volume  sebesar  28,257  m 3 dengan  volume  elemen ruang pada model IFC.
3. Analisis Proses Konversi
Perbedaan metode konversi  antara eveBIM, FME, dan  FZK  menyebabkan  perbedaan  representasi  dan muatan  informasi  semantik  dari  model  yang dikonversi.  Konversi  menggunakan  FME  cenderung lebih  sulit  dilakukan  karena  pengguna  harus membangun skema konversi antar kedua format data. Pengguna perlu memahami cara kerja perangkat FME dalam  mengkonversi  format  data  melalui  skema konversi. Hal ini penting agar skema dapat dijalankan dan  pada  akhirnya  menghasilkan  model  3D  yang dikehendaki. Sementara itu, untuk perangkat eveBIM dan  FZK,  proses  konversi  IFC  ke  CityGML  tidak menggunakan  skema  konversi.  Akan  tetapi  hal tersebut  justru  cenderung  membatasi  pengguna (tidak fleksibel) sebab seluruh proses konversi format
data dilakukan secara otomatis oleh perangkat lunak dan pengguna tidak dapat mengatur skema pemetaan elemen format data  sehingga model 3D yang berhasil dikonversi  dapat  saja  memiliki  semantik  yang  tidak sesuai dengan semantik format data masukan.
4. Analisis Model CityGML
Penulis tidak menemukan adanya kesalahan pada model CityGML yang dikonversi pada perangkat FME dan  FZK  Viewer.  Penulis  menilai  bahwa  kesalahan tidak selalu terjadi saat proses konversi berlangsung. Kesalahan  dapat  dihindari  jika  pengguna  mencoba berbagai  perangkat  lunak  yang  mampu  menangani proses  konversi  format  data  BIM  dan  GIS.  Namun, anggapan  tersebut  juga  masih  belum  dapat dipertanggungjawabkan  sebab  dalam  penelitian  ini hanya  sebagian  kecil  dari  elemen  IFC  saja  yang dikonversi  yaitu IfcSpace dan IfcWallStandardCase . Hal  ini  dilakukan  mengingat  penelitian  ini  berfokus pada kadaster 3D, sedangkan jika seluruh elemen IFC dikonversi  menjadi  CityGML  maka  akan  banyak elemen yang tidak digunakan karena tidak berkaitan dengan kadaster  3D atau  dengan kata lain tidak lagi menjadi  fokus  dalam  penelitian  ini.  Akan  tetapi  jika seluruh  elemen  IFC  dikonversi,  akan  lebih  mudah untuk  mengetahui  dan  membuktikan  secara  jelas apakah perangkat lunak yang digunakan untuk proses konversi format data IFC mempengaruhi representasi model  CityGML  yang  dihasilkan.  Selain  itu,  semakin banyak  elemen  IFC  yang  dikonversi  menjadi  elemen CityGML, akan semakin mudah pula untuk mengetahui ada tidaknya elemen IFC yang tidak terpetakan sesuai dengan semantik elemen CityGML (Putra 2022).

## 4. Kesimpulan
Model  CityGML  yang  dikonversi  pada  perangkat  FME dan FZK memiliki representasi geometri fitur yang jelas dan sesuai  dengan  geometri  fitur  asalnya  yaitu  pada  elemen model  IFC,  sedangkan  model  CityGML  hasil  konversi eveBIM  tidak  representatif  karena  banyak  ditemukan kesalahan.  Hal  tersebut  dibuktikan  dengan  banyaknya kesalahan  seperti  adanya  penambahan  dan  pengurangan fitur  serta  adanya  beberapa  fitur  yang  memiliki  bentuk geometri  tidak  representatif  pada  model  CityGML  hasil konversi  eveBIM.  Ditinjau  dari  hasil  validasi,  skema  XML model  CityGML  hasil  konversi  eveBIM  masih  ditemukan kesalahan  dalam  hal  penamaan  ID,  sedangkan  model CityGML hasil konversi FME dan FZK memiliki skema XML yang  benar.  Geometri  primitif  model  CityGML  hasil konversi eveBIM, FME, dan FZK juga tergolong sudah benar. Dalam penelitian ini, seluruh elemen IFC dapat terpetakan menjadi elemen CityGML dengan tetap menjaga hubungan semantik  antara  elemen  ruangan  dan  dinding  yang terdapat  di  model  IFC  dan  CityGML.  Hubungan  semantik yang  dimaksud  adalah  elemen  ruangan  ( IfcSpace )  dan dinding  ( IfcWallStandardCase )  dapat  dipetakan  dengan
benar menjadi elemen pada model CityGML yang memiliki semantik  serupa  dengan  elemen IfcSpace dan IfcWallStandardCase .
Visualisasi model 3D masih belum dapat dilakukan pada format  data  CityJSON  karena  tidak  mendukung  elemen yang  direpresentasikan  dalam  LoD-4  seperti  halnya  yang diadopsi  pada  format  data  CityGML  versi  2.  Selain  itu, visualisasi  model  3D  dalam  format  data  CityJSON  yang diperoleh dari proses konversi model IFC menjadi CityGML belum dapat dilakukan karena sampai dengan penelitian ini dilakukan,  skema encoding CityGML  versi  3  masih  belum ditetapkan sebagai standar resmi sehingga perangkat lunak yang  menangani  proses  konversi  IFC  ke  CityGML  masih menggunakan CityGML versi 2. Dalam penelitian ini, hanya model  CityGML  hasil  konversi  perangkat  eveBIM  yang dapat  dikonversi  menjadi  model  CityJSON  sebab  elemen ruang  dimodelkan  dalam  LoD-3.  Akan  tetapi,  model  3D tersebut  tidak  representatif  jika  digunakan  untuk visualisasi di dalam sebuah sistem informasi karena banyak ditemukan kesalahan.

## 5. Pernyataan Konflik Kepentingan
Penulis  menyatakan  tidak  ada  konflik  kepentingan dalam  artikel  ini  ( The  authors  declare  no  competing interest ).

## 6. Ucapan Terimakasih
Penulis mengucapkan terimakasih kepada Kementerian Agraria dan Tata Ruang/Badan Pertanahan Nasional serta Tim  Kajian  Basisdata  Kadaster  3D  UGM  yang  telah mendukung dan membantu dalam memberikan data, yaitu berupa model 3D IFC stasiun MRT Bundaran HI dan Blok M, maupun informasi untuk tujuan penelitian ini. Penulis juga tak lupa mengucapkan terimakasih kepada PT. MRT Jakarta (Perseroda) yang telah memberikan izin penggunaan data berupa as-built  drawing stasiun Bundaran  HI dan Blok M BCA  sebagai  sumber  data  dalam  model  3D  IFC  yang digunakan di dalam penelitian ini.

## 7. Referensi
Asghari, A., Kalantari, M., Rajabifard, A., 2021. Formative and Summative Validation of Building Information Model-Based Cadastral Data. Land 10, 822. https://doi.org/10.3390/land10080822 Atazadeh, B., Halalkhor Mirkalaei, L., Olfat, H., Rajabifard, A., Shojaei, D., 2021. Integration of cadastral survey data into building information models. Geo-spatial Information Science 24 , 387 – 402. https://doi.org/10.1080/10095020.2021.193733 6
Atazadeh, B., Rajabifard, A., Zhang, Y., Barzegar, M., 2019.
Querying 3D Cadastral Information from BIM
Models. IJGI 8, 329. https://doi.org/10.3390/ijgi8080329 Atunggal, D., Widjajanti, N., Laksono, D., Susanta, F.F., Aditya, T., 2020. Laporan Akhir Pilot Project Kadaster 3D (Lokasi : MRT Jakarta). Fakultas Teknik Universitas Gadjah Mada.
Daum, S., Borrmann, A., 2014. Processing of Topological BIM Queries using Boundary Representation Based Methods. Advanced Engineering Informatics 28, 272 – 286. https://doi.org/10.1016/j.aei.2014.06.001
El-Mekawy, M., Östman, A., Hijazi, I., 2012. An Evaluation of IFC-CityGML Unidirectional Conversion. IJACSA 3. https://doi.org/10.14569/IJACSA.2012.030525 El-Mekawy, M., Östman, A., Shahzad, K., 2011. Towards Interoperating CityGML and IFC Building Models: A Unified Model Based Approach, in: Kolbe, T.H., König, G., Nagel, C. (Eds.), Advances in 3D Geo- Information Sciences, Lecture Notes in Geoinformation and Cartography. Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 73 – 93. https://doi.org/10.1007/978-3-642-12670-3_5 FME Community, 2020. GeoBIM benchmark, 2019. Gröger, G., Kolbe, T.H., Nagel, C., Häfele, K.-H., 2012. OGC City Geography Markup Language (CityGML) Encoding Standard 344. Gröger, G., Plümer, L., 2012. CityGML – Interoperable semantic 3D city models. ISPRS Journal of Photogrammetry and Remote Sensing 71, 12 – 33. https://doi.org/10.1016/j.isprsjprs.2012.04.004 Hajji, R., Yaagoubi, R., Meliana, I., Laafou, I., Gholabzouri, A.E., 2021. Development of an Integrated BIM-3D GIS Approach for 3D Cadastre in Morocco. IJGI 10, 351. https://doi.org/10.3390/ijgi10050351 Ledoux, H., Arroyo Ohori, K., Kumar, K., Dukai, B., Labetski, A., Vitalis, S., 2019. CityJSON: a compact and easy- to-use encoding of the CityGML data model. Open geospatial data, softw. stand. 4, 4. https://doi.org/10.1186/s40965-019-0064-0 Noardo, F., Krijnen, T., Arroyo Ohori, K., Biljecki, F., Ellul, C., Harrie, L., Eriksson, H., Polia, L., Salheb, N., Tauscher, H., Liempt, J., Goerne, H., Hintz, D., Kaiser, T., Leoni, C., Warchol, A., Stoter, J., 2021. Reference study of IFC software support: The
GeoBIM benchmark 2019 — Part I. Transactions in
GIS 25, 805 – 841. https://doi.org/10.1111/tgis.12709 Oldfield, J., van Oosterom, P., Beetz, J., Krijnen, T., 2017. Working with Open BIM Standards to Source Legal Spaces for a 3D Cadastre. IJGI 6, 351. https://doi.org/10.3390/ijgi6110351 Putra, R. W.,  2022. Evaluasi Format Data CityGML dan CityJSON untuk Kadaster 3D di Indonesia. Skripsi Program Sarjana Program Studi Teknik Geodesi UGM , Yogyakarta.
Rashidan, H., Abdul Rahman, A., Sani, M.J., 2021. Converting BIM Data to CityGML for 3D Cadastre Purposes. https://doi.org/10.4233/UUID:443360B5-9333- 43D2-AA14-955903C37A14
Solihin, W., Eastman, C., Lee, Y.-C., Yang, D.-H., 2017. A simplified relational database schema for transformation of BIM data into a query-efficient and spatially enabled database. Automation in Construction 84, 367 – 383. https://doi.org/10.1016/j.autcon.2017.10.002 Sulistyawati, M. N., Aditya, T., & Santosa, P. B. 2018.
Development of Spatio-Temporal Database Prototype For Management of 4-Dimensional Cadastre Object In Indonesia. Journal of Geospatial Information Science and Engineering, 1(2) , 94-103. https://doi.org/10.22146/jgise.41680
Sulistyawati, M. N., Aditya, T., & Santosa, P. B. 2019. The Implementation Of Ladm Versionedobject Class For Representing Spatio-Temporal Of Cadastre 4d Objects. BHUMI: Jurnal Agraria Dan Pertanahan , 4 (2), 249 – 265. https://doi.org/10.31292/jb.v4i2.281 Sun, J., 2019. The Integration of 3D Geodata and BIM Data in 3D City Models and 3D Cadastre.
Sun, Mi, Olsson, Paulsson, Harrie, 2019. Utilizing BIM and GIS for Representation and Visualization of 3D Cadastre. IJGI 8, 503. https://doi.org/10.3390/ijgi8110503 Tekavec, J., Čeh, M., Lisec, A., 2021. Indoor spac e as the basis for modelling of buildings in a 3D Cadastre.
Survey Review 53, 464 – 475.
https://doi.org/10.1080/00396265.2020.183876 1
Tim Kajian Basisdata Kadaster 3D UGM, 2021. Pemodelan 3D Untuk Kadaster 3D.