# Barra de herramientas y mediciones

## Resumen

FulcrumViewer usa el mismo `build/potree/potree.js` y la misma base visual de `build/potree/potree.css` para dos modos de uso distintos: inspeccion y visualizacion. La diferencia principal no esta en cargar otro visor, sino en que cada vista HTML monta una barra de herramientas distinta y decide que capacidades expone al usuario.

En estas vistas, la barra principal no depende de la toolbar estandar del sidebar de Potree. En su lugar, cada HTML crea su propio `#potree_toolbar` y conecta sus botones con la API publica del visor, sobre todo con `viewer.measuringTool` para crear mediciones y geotags.

## Archivos clave

- `build/potree/potree.js`: build consumido por las vistas. Contiene `Viewer`, `MeasuringTool` y las extensiones de geotags usadas por inspeccion.
- `src/utils/MeasuringTool.js`: implementacion fuente base del flujo de mediciones y de la insercion general de medidas.
- `src/viewer/sidebar.js`: toolbar estandar de Potree en el sidebar (`#tools`), util como referencia para ver que tipos de medicion soporta el visor aunque estas vistas usen una toolbar propia.
- `build/potree/potree.css`: estilos base del contenedor del visor, sidebar, render area y paneles.
- `src/viewer/potree.css`: origen editable de la hoja de estilos base del visor.
- `views/ArtxandaInspeccion.html`: vista de inspeccion. Expone mediciones, geotags, cambio de navegacion y ajustes de visualizacion.
- `views/ArtxandaVisualizacion.html`: vista de visualizacion. Reduce la interfaz a opciones de material y ajustes visuales, sin botones de medicion.

## Funcionamiento

### Base comun del visor

Ambas vistas cargan la misma cadena de dependencias: librerias de terceros, `build/potree/potree.js` y `build/potree/potree.css`. Despues crean el visor con `new Potree.Viewer(...)` sobre `#potree_render_area`.

La consecuencia practica es que el comportamiento base del visor es comun: escena, controles, herramientas de medicion y estado interno viven en el mismo `Viewer`. Lo que cambia entre modos es la interfaz HTML que decide que metodos del visor se llaman y cuales quedan fuera del flujo del usuario.

### Toolbar propia frente a toolbar estandar de Potree

Potree ya trae una toolbar en el sidebar. En `src/viewer/sidebar.js` el metodo `initToolbar()` crea iconos para angulo, punto, distancia, altura, circulo, azimut, area, volumen, perfil, anotacion y borrado completo. Todos esos botones acaban llamando a `measuringTool.startInsertion(...)`, `profileTool.startInsertion()` o `volumeTool.startInsertion()`.

Las vistas de Artxanda no usan esa toolbar como interfaz principal. En vez de ello dibujan un `div` propio con id `potree_toolbar` dentro de `#potree_render_area` y conectan eventos DOM manualmente. Esto desacopla la experiencia de usuario del sidebar general y permite mostrar solo las herramientas necesarias para cada modo.

### Rol de `potree.css`

`build/potree/potree.css` aporta la base del visor: contenedor lateral, `#potree_render_area`, mensajes, anotaciones y apariencia general. Esa hoja sigue siendo necesaria aunque la barra superior se redefina en cada vista.

En las vistas de Artxanda, la barra superior se personaliza encima de esa base:

- `ArtxandaInspeccion.html` aplica estilos inline directamente sobre `#potree_toolbar`.
- `ArtxandaVisualizacion.html` redefine `#potree_toolbar` con una apariencia mas compacta y flotante en un bloque `<style>` propio.

Esto significa que el CSS base del visor resuelve la estructura general, pero la forma final de la toolbar en estas dos vistas depende del HTML especifico de cada modo.

### Modo inspeccion

`views/ArtxandaInspeccion.html` expone una toolbar operativa. La barra incluye:

- selector de material (`#optMaterial`),
- medicion de punto,
- medicion de distancia,
- medicion de altura,
- alta manual de geotag,
- cambio entre navegacion en primera persona y orbita,
- menu de ajustes de numero de puntos, tamano y correcciones visuales,
- display de PK (`#valorDistanciaPk`).

La activacion es directa por boton:

- Punto: llama a `viewer.measuringTool.startInsertion(...)` con `showCoordinates: true`, `closed: true` y `maxMarkers: 1`.
- Distancia: llama a `startInsertion(...)` con `showDistances: true`.
- Altura: llama a `startInsertion(...)` con `showHeight: true`.
- Geotag: llama a `viewer.measuringTool.startGeotagInsertion()`.

Ademas, esta vista habilita funciones propias de inspeccion antes incluso de cargar la nube:

- `viewer.measuringTool.enableGeotags()` activa la logica asociada al listado lateral y a la gestion de geotags.
- `viewer.measuringTool.loadGeotagsFromAPI(8)` recupera geotags remotos y los pinta como medidas especiales de tipo `Geotag`.
- `viewer.setControls(viewer.orbitControls)` y `viewer.setControls(viewer.fpControls)` cambian el modo de navegacion desde la propia toolbar.

El indicador PK no es una pieza decorativa. El `MeasuringTool` personalizado del build actualiza `#valorDistanciaPk` en su `update()` calculando la distancia desde una referencia fija del tunel. Por tanto, ese elemento de UI depende de una personalizacion propia de FulcrumViewer presente en el build.

### Modo visualizacion

`views/ArtxandaVisualizacion.html` reutiliza el mismo visor, pero la toolbar queda reducida a funciones de visualizacion:

- selector de material,
- numero de puntos,
- tamano de punto,
- gamma,
- brillo,
- contraste.

No hay botones para crear medidas, ni para geotags, ni para alternar navegacion. La vista complementa esto con un tutorial visual de controles basicos y un overlay de carga. El resultado funcional es un modo mas guiado y menos editable: se prioriza explorar la nube y ajustar su aspecto, no anotar ni inspeccionar sobre ella.

### Flujo funcional de las mediciones

El punto de entrada comun es `viewer.measuringTool.startInsertion(args)`.

Ese metodo crea internamente un objeto `Measure`, dispara el evento `start_inserting_measurement` y marca configuraciones segun el tipo de medida:

- `showCoordinates` para punto,
- `showDistances` para distancia,
- `showHeight` para altura,
- `showAngles`, `showArea`, `showCircle` o `showAzimuth` para otros tipos soportados por Potree.

Despues inicia un flujo interactivo comun:

1. Inserta un primer marcador provisional.
2. Pone ese marcador en modo drag con `inputHandler.startDragging(...)`.
3. Escucha clicks de raton sobre el canvas del renderer.
4. Con click izquierdo confirma el punto actual y anade otro marcador si la medida admite mas vertices.
5. Con click derecho o al alcanzar `maxMarkers` cierra la insercion.

Desde la perspectiva funcional, cada boton de la toolbar no crea una herramienta distinta; solo llama al mismo motor de insercion con un conjunto diferente de flags.

### Geotags como extension de las mediciones

En el build actual, `MeasuringTool` esta extendido con una capa especifica de inspeccion:

- `enableGeotags()` activa la UI complementaria.
- `startGeotagInsertion()` crea una medida de un solo punto con nombre `Geotag`.
- `loadGeotagsFromAPI(idInspeccion)` autentica contra la API y genera geotags desde datos remotos.
- `createGeotagTab()`, `createGeotagList()` y la logica de filtros montan una UI lateral adicional fuera del sidebar estandar.

Esto es importante porque esa funcionalidad no aparece igual de completa en `src/utils/MeasuringTool.js`. La version usada realmente por las vistas es la del build, que incluye personalizaciones propias de FulcrumViewer para inspeccion y danos.

### Diferencia funcional entre inspeccion y visualizacion

La separacion entre modos se hace en la interfaz, no en el nucleo del visor:

- Inspeccion: expone acciones que modifican o enriquecen la escena del usuario, como medir, crear geotags, listar danos y cambiar de modo de navegacion.
- Visualizacion: expone solo ajustes de representacion y ayuda de uso, manteniendo ocultas las herramientas de edicion o inspeccion.

Esto permite reutilizar un mismo `potree.js` y el mismo modelo interno de escena sin ramificar el visor en dos builds distintos.

## Riesgos de cambio

- Si se cambia la firma o el comportamiento de `viewer.measuringTool.startInsertion(...)`, se rompen tanto la toolbar custom de inspeccion como la toolbar estandar del sidebar.
- Si se modifica `MeasuringTool` solo en `src/` pero no se regenera `build/potree/potree.js`, las vistas seguiran ejecutando la version antigua.
- La logica de geotags parece vivir de forma efectiva en el build consumido por las vistas. Cualquier refactor debe confirmar si esa personalizacion ya esta sincronizada con `src/utils/MeasuringTool.js` o si existe divergencia build-fuente.
- `#valorDistanciaPk` depende de ids concretos en el HTML y de una rutina especifica del `MeasuringTool` custom. Cambiar el id o mover el elemento sin adaptar el build rompe la actualizacion visual del PK.
- `ArtxandaVisualizacion.html` y `ArtxandaInspeccion.html` redefinen estilos de `#potree_toolbar` localmente. Un cambio global en `potree.css` no garantiza uniformidad si los estilos locales siguen sobrescribiendo la apariencia.

## Siguientes pasos

- Documentar en un archivo separado la funcionalidad de geotags y su relacion con la API externa, porque en inspeccion ya actua como subsistema propio.
- Revisar si conviene unificar la toolbar custom en un componente compartido para evitar duplicar wiring entre vistas.
- Confirmar con una revision dirigida si la implementacion fuente de `src/utils/MeasuringTool.js` esta desactualizada respecto al build usado en produccion.