Presentamos cjdb: Un enfoque simplificado para modelos de ciudades en 3D

Almacenar modelos de ciudades en 3D en una base de datos puede ser un trabajo complicado. Una forma popular de hacerlo es usando un sistema llamado CityGML, que puede llevar a configuraciones complejas con muchas tablas. Por ejemplo, un sistema comúnmente usado, 3DCityDB, necesita 66 tablas para manejar sus datos.

En este artículo, te presentamos una solución alternativa de base de datos llamada 'cjdb', que permite almacenar modelos de CityGML de manera más simple en PostgreSQL. A diferencia de 3DCityDB, que requiere muchas tablas, cjdb solo necesita tres. Esta simplificación se logra manteniendo los detalles de los objetos de la ciudad en un formato llamado JSON.

Nuestra propuesta usa CityJSON, que está diseñado para almacenar información sobre modelos de ciudades en 3D. El objetivo de cjdb es facilitar a los usuarios trabajar con datos de ciudades en 3D sin perderse en un mar de estructuras complejas.

#Ventajas de cjdb

Cuando probamos cjdb contra 3DCityDB usando grandes modelos de ciudades en 3D del mundo real, encontramos algunas diferencias importantes. Primero, cjdb ocupa mucho menos espacio, alrededor de diez veces menos que 3DCityDB. Esto es importante porque significa que se necesita menos almacenamiento para la misma cantidad de datos.

En segundo lugar, cjdb ofrece opciones más rápidas para importar y exportar datos. Los usuarios pueden mover información dentro y fuera de la base de datos más rápidamente. Al recuperar datos, la velocidad es similar para ambos sistemas, pero algunas consultas en cjdb son más rápidas mientras que otras pueden tardar un poco más.

El software que permite a los usuarios importar y exportar datos está disponible gratuitamente en línea.

#¿Qué es CityGML?

CityGML es un estándar internacional usado para almacenar modelos digitales de ciudades. Permite a los usuarios definir y guardar objetos 3D comunes que se encuentran en áreas urbanas, como edificios, carreteras, árboles y puentes. También soporta diferentes niveles de detalle (LoDs) para estos objetos 3D, lo que es útil para varias aplicaciones.

CityGML tiene una estructura detallada pero puede generar desafíos, especialmente cuando los datos necesitan ser gestionados en bases de datos. Aquí es donde entra cjdb, ofreciendo una forma más simple de manejar los mismos datos.

#Sistemas de Gestión de Bases de Datos (DBMS)

Gestionar grandes conjuntos de datos es crucial, especialmente para modelos de ciudades. Las bases de datos ofrecen una forma efectiva de almacenar y manejar información extensa. Tienen varias ventajas sobre sistemas de archivos simples, como mejor seguridad, actualizaciones de versiones más fáciles y mejor escalabilidad.

3DCityDB es popular para manejar grandes cantidades de datos de ciudades y permitir que múltiples usuarios accedan a ella. Por lo general, requiere que los usuarios almacenen sus datos en un servidor remoto y accedan a través de una interfaz web, lo que puede ser complicado ya que divide la información en muchas tablas.

#El desafío con 3DCityDB

Aunque 3DCityDB es ampliamente utilizado, muchos usuarios lo encuentran complicado de manejar. El problema principal es que los datos están repartidos en 66 tablas, lo que crea consultas complicadas que requieren juntar mucha información.

Se han hecho intentos de facilitar esto, como crear vistas adicionales para acceso simplificado, pero estas pueden aumentar el tamaño de la base de datos.

#Pasar a cjdb

En respuesta a la complejidad de 3DCityDB, se desarrolló cjdb. Usa un esquema mucho más simple con solo tres tablas. Esto permite a los usuarios almacenar y recuperar modelos de ciudades en 3D de manera eficiente sin el estrés de numerosas tablas complejas y uniones en las consultas.

Una característica clave de cjdb es cómo maneja las geometrías y atributos directamente en formato JSON. Esto reduce la cantidad de espacio necesario y acelera el proceso de importar y exportar datos.

#Modelo de Datos de cjdb

El modelo de datos de cjdb se inspira en el enfoque de Simple Feature. Cada fila en la tabla de objetos de la ciudad contiene un objeto CityJSON, y las geometrías se almacenan en una columna. Esto permite a los usuarios gestionar y procesar fácilmente los datos de la ciudad.

Cada objeto de la ciudad contiene su identificador, tipo, atributos y geometría, todo guardado ordenadamente en una columna. Además, las relaciones entre objetos se rastrean en una tabla separada para ayudar con las consultas.

La base de datos también incluye metadatos sobre los archivos de CityJSON importados, asegurando que aspectos importantes como el sistema de referencia de coordenadas y la caja delimitadora estén documentados.

#Comparación de Rendimiento

Para probar qué tan bien funciona cjdb en comparación con 3DCityDB, creamos conjuntos de datos de referencia usando información de tres regiones diferentes. Importamos los datos en ambos sistemas y comparamos:

• Tiempos de Importación y Exportación: cjdb fue generalmente más rápido, por ejemplo, importar 100 tiles de un conjunto de datos tomó 21 segundos en cjdb pero 113 segundos en 3DCityDB.

• Tamaño de la Base de Datos: cjdb requirió mucho menos espacio que 3DCityDB. La diferencia de tamaño proviene de cómo los dos sistemas almacenan sus características. En 3DCityDB, superficies como paredes y techos se tratan como objetos separados, mientras que cjdb los mantiene juntos en un solo objeto.

• Velocidad de Recuperación de Datos: Medimos qué tan rápido cada sistema podía recuperar datos usando consultas SQL comunes. En general, cjdb tuvo un mejor rendimiento en muchas consultas 2D gracias a su estructura simple, que le permite evitar las uniones complejas necesarias en 3DCityDB.

#Consultas en Detalle

Examinamos ocho tipos de consultas para evaluar el rendimiento:

1. Consulta Basada en Atributos: cjdb fue más rápido que 3DCityDB para algunos atributos, mientras que para otros, los tiempos fueron similares.

2. Consultas Espaciales 2D: cjdb destacó en consultas espaciales 2D, recuperando datos fácilmente sin las uniones complejas de 3DCityDB.

3. Contar Partes: La velocidad varió más según el tamaño del conjunto de datos, pero cjdb tuvo algunas ventajas al usar consultas más simples.

4. Consultas de Nivel de Detalle (LoD): Aunque cjdb puede ser más lento para ciertas consultas de LoD, aún puede obtener datos más rápido cuando también se requiere geometría, debido a la necesidad de uniones en 3DCityDB.

5. Cambios en Atributos: Las adiciones a la base de datos mostraron velocidades más lentas en cjdb porque los cambios en formato JSON tardan más. Sin embargo, las actualizaciones y eliminaciones fueron más eficientes en cjdb.

#Conclusión y Trabajo Futuro

El proyecto cjdb tiene como objetivo proporcionar una forma más fácil para que los usuarios almacenen y manejen modelos de ciudades en 3D mientras reducen la complejidad. Usar solo tres tablas lo hace mucho más simple de operar que 3DCityDB, y almacenar datos en un formato como JSON acelera el proceso de importación y exportación.

Aunque cjdb funciona mejor para consultas espaciales 2D, enfrenta algunos desafíos cuando las columnas JSON se modifican o tienen muchos atributos. Como siguiente paso, el objetivo es desarrollar funciones para extraer geometría de superficies semánticas y mejorar la experiencia del usuario con mejores herramientas para consultas y visualización.

También planeamos extender el soporte para texturas y materiales para mejorar las capacidades de la base de datos. A medida que el campo de modelado de ciudades en 3D evoluciona, cjdb busca mantenerse al día con las necesidades de los usuarios y los avances tecnológicos, asegurando que siga siendo una herramienta valiosa para gestionar datos urbanos.