Editor 3D de tejados en un CRM fotovoltaico con Google Solar API

Un presupuesto fotovoltaico con una tabla de números y una foto de satélite plana convence poco. El cliente quiere ver su tejado con los paneles encima. Las plataformas líderes del sector, como Reonic 360h, lo resuelven con un planificador 3D: dibujas el tejado, colocas módulos, simulas el sombreado y generas la propuesta en menos de quince minutos.

Para el CRM que desarrollamos para una instaladora fotovoltaica nos marcamos un objetivo más modesto pero muy concreto: conseguir el 70 % de ese "efecto wow" sin construir un motor de geometría propio ni pagar una plataforma externa por cada presupuesto. La sorpresa fue descubrir que Google Solar API regala buena parte del trabajo pesado… y que el mayor obstáculo no sería técnico, sino geopolítico.

Lo que Google Solar regala

El módulo se apoya en dos APIs complementarias:

• Building Insights devuelve la geometría "vectorial" del tejado: cada falda con su inclinación, orientación, área y bounding box, más una lista de paneles candidatos con la producción estimada de cada uno. Con una sola llamada, el formulario de presupuesto ya puede sugerir exposición, inclinación y producción reales del edificio del cliente.
• Data Layers devuelve los datos "raster" en formato GeoTIFF: un modelo digital de superficie (DSM) donde cada píxel es una altura en metros, la ortofoto del entorno y el flujo solar anual (kWh/kW/año) por píxel, que ya incorpora el sombreado real calculado por Google. La feature estrella de los planificadores comerciales, servida como un raster más.

Un detalle importante para la arquitectura: los URLs de Data Layers caducan en una hora. No se pueden guardar los enlaces, así que descargamos y procesamos los GeoTIFF en el servidor al momento (con geotiff.js y pngjs, dentro de Server Actions de Next.js — la clave de API nunca llega al navegador) y cacheamos el resultado ya elaborado en Postgres con un TTL largo. El coste de Google queda amortizado a "una vez por dirección".

El intento fotorrealista y el 403

La primera versión del editor 3D usaba los Photorealistic 3D Tiles de Google Maps: la misma malla fotogramétrica que ves en Google Earth, con edificios, calles y árboles texturizados. Funcionaba, y era espectacular.

Hasta que un día, al abrir el editor: 403 PERMISSION_DENIED. Desde el 8 de julio de 2025, Google bloquea los 3D Tiles fotorrealistas (y las imágenes de satélite 2D de Map Tiles) para las cuentas de facturación del Espacio Económico Europeo, sin proceso de solicitud de acceso. El mismo bloqueo aplica si intentas acceder vía Cesium ion, porque la fuente es la misma.

Aquí hay un insight que vale la pena subrayar: esas plataformas de diseño solar tan pulidas usan exactamente la misma API de Google que a nosotros nos acaban de cerrar. La "limpieza" de sus escenas 3D no es mérito de su motor: es fotogrametría de Google.

El pivote: reconstruir el relieve desde el DSM

En lugar de abandonar el 3D, cambiamos de fuente: el DSM de Data Layers es, literalmente, un mapa de alturas. Desplazando los vértices de un plano según el valor de cada píxel obtenemos una malla del terreno y los edificios, y sobre ella drapeamos la ortofoto. Todo con React Three Fiber y three.js, y con datos que ya estábamos usando.

Perdemos el fotorrealismo y el barrio nítido; ganamos independencia de una API bloqueada, control total del pipeline y un coste previsible. Y hay un premio extra: como el flujo solar anual llega en el mismo raster, un toggle cambia la textura del terreno por un heatmap de producción de azul a rojo, con su leyenda. El mismo gesto que ofrecen las herramientas comerciales para "ver dónde rinde el tejado".

Colocación de módulos por falda

Sobre ese relieve, el instalador elige una falda y un módulo real del catálogo del CRM — no specs genéricas — y añade un grupo: una rejilla de filas × columnas que se ajusta con controles de separación, inclinación y rotación. Los kWp y la producción estimada se recalculan en vivo, y el diseño se guarda en el propio presupuesto.

Al terminar, una captura de la escena 3D se inserta como página en el PDF del presupuesto: el cliente recibe su tejado, con sus paneles, en su propuesta.

Honestidad técnica: lo que aún no está pulido

El relieve DSM tiene un defecto visible: al drapear una foto cenital sobre paredes casi verticales (diez metros de caída en medio metro de píxeles), la textura se estira y los bordes de los edificios parecen "derretirse"; los árboles salen como púas. Lo estamos atacando por tres frentes: detectar las caras muy inclinadas por su normal y pintarlas de un color sólido (los edificios se leen como bloques limpios), suavizar el ruido del DSM preservando bordes, y subir la resolución del heightmap en la zona del tejado.

Lo que nos llevamos

• La disponibilidad geopolítica de una API es un riesgo de arquitectura tan real como el precio o los límites de uso. Nos pilló a mitad de proyecto y con la integración funcionando.
• Diseñar con degradación elegante salva el producto: si no hay cobertura de Data Layers, el editor cae a una vista ligera estilizada que siempre está disponible.
• Cachear el payload procesado, no los enlaces: con URLs que caducan en una hora, la caché útil es la del resultado.
• No hace falta un motor propio para dar una experiencia de planificación 3D creíble: los datos ya existen; el valor está en integrarlos donde trabaja el equipo, dentro del CRM.

¿Tienes un CRM o una herramienta interna que podría dar mucho más de sí? En Digital Consulting Agüita integramos APIs, datos y visualización para convertir procesos comerciales en experiencias que venden. Cuéntanos tu caso.