A finales del 2014 presentamos en Digi3D.NET la funcionalidad Desencadenadores.
Eran controles de calidad se habilitaban en la tabla de códigos y se ejecutaban en tiempo real, es decir: al almacenar una geometría se desencadenaba (de
ahí el nombre de desencadenadores) que se analizasen las reglas asignadas al código.
Tenía el problema de que era una caja negra que únicamente disponía de una serie de reglas (programadas por nosotros en Digi21). El usuario no tenía libertad de añadir reglas propias.
En 2016 decidimos cambiarle el nombre que pasó de llamarse a Modelo semántico y se añadió una orden booleana denominada ANALIZAR_MODELO_SEMANTICO que básicamente habilitaba o deshabilitaba el análisis. De esta manera, podíamos deshabilitarlo para que no nos estuviera molestando el programa, pero esto era una evolución de lo presentado en 2014: seguíamos teniendo una caja negra.
A finales de 2016 añadimos el menú Modelo semántico que permitía (además de cambiar el valor de la orden ANALIZAR_MODELO_SEMANTICO), ejecutar tests de modelo semántico bajo demanda, analizando todas las geometrías del archivo de dibujo y mostrando los errores descubiertos en el panel de tareas de la aplicación.
Seguíamos con el problema de que los tests eran una caja negra: Si un usuario quería detectar como error una geometría con un número impar de vértices si el día en el que se analizaba la geometría era lunes, no podía, porque ese test no existe (ni creo que a nadie se le ocurra hacer algo así).
Debido a que nuestra política ha sido siempre evitar las cajas negras, decidimos hacer un primer borrón y cuenta nueva y cambiar todo lo relacionado con Modelo Semántico y hacer que sea el propio usuario el que pudiese programar a su antojo las reglas. Para ello eliminamos los cuadros de diálogo de selección de modelo semántico y añadimos a cada código la posibilidad de añadir un pequeño guion en cualquier lenguaje .NET (en la práctica C#) que se ejecutaría cada vez que el usuario digitaliza una geometría o cada vez que el usuario forzase un análisis bajo demanda.
Gracias a esto pudimos implementar el modelo de MGCP en Digi3D.NET y hace ya muchos años es lo que utilizan en el Centro Geográfico del Ejército para hacer sus tests.
El problema de este modelo es que al desaparecer los cuadros de diálogo de selección de tests y al requerir tener conocimientos de programación, en la práctica esta
funcionalidad la utilizaban en una o dos empresas.
Por otro lado, en 2021 añadimos el soporte para trabajar con Python en Digi3D.NET.
Python es un lenguaje de introducción a la programación que es muy sencillo, y hay muchas más posibilidades de que usuarios avanzados de GIS y cartografía lo conozcan.
Como Digi3D.NET es programable en .NET desde que le pusimos el apellido .NET (antes se llamaba Digi3D a secas), utilizamos una implementación de Python de Microsoft denominada IronPython, y con muy poco esfuerzo teníamos la posibilidad de interpretar guiones Python dentro del programa exponiendo todo el modelo de objetos de .NET.
Esta solución no era muy pythonic, pues lo expuesto no utilizaba a penas listas ni tuplas, sino objetos .NET en Python, pero era completamente funcional y cualquiera podía hacer guiones que interactuasen con Digi3D.NET. No se podían hacer órdenes, interactivas, pero sí guiones con lógica.
El problema de esta librería es que estaba anclada a la versión Python 2.7 que ya está anticuada (curiosamente acabo de ver mientras buscaba el enlace a IronPython para ponerlo más arriba que el 12 de diciembre de 2022 han publicado una versión compatible con Python 3.x).
Precisamente en diciembre de 2022 hemos añadido a MDTopX la posibilidad de ejecutar guiones Python. Como MDTopX es una aplicación 100% nativa, no tiene sentido utilizar IronPython para usarlo como motor de Python, de manera que hemos utilizado CPython, que es la implementación de Python nativa.
Una vez finalizada la implementación de Python en MDTopX, como lo teníamos fresco decidimos reescribir desde 0 también el motor de Python de Digi3D.NET.
Debido a este cambio, y viendo las posibilidades que tenía, hemos vuelto a hacer otro borrón y cuenta nueva, y hemos empezado de cero por tercera vez (esperemos que esta sea la definitiva) y hemos hecho que por un lado sea súper flexible, porque cualquiera puede añadir sus controles de calidad (como por ejemplo poder detectar como error geometrías con un número impar de vértices si el test lo ejecutamos un lunes), y por otro lado, tenemos cuadros de diálogo para añadir y configurar los controles de calidad gráficamente.
El truco consiste en que hemos añadido al editor de tablas de códigos un botón que permite descargar los controles de calidad de internet (de un repositorio GitHub).
Tan solo tienes que pulsar ese botón y los tienes en tu tabla de códigos y ya puedes asignarlos gráficamente a tus códigos.
Si sabes programar en Python, puedes modificar esos guiones, o comenzar de cero con tu propio sistema. Si creas algún control de calidad que crees que pueda ser útil para la comunidad, tan solo tienes que forkear el repositorio añadir tus controles de calidad y hacernos un pull-request que estaremos encantados de aceptar.
Además, le hemos vuelto a cambiar de nombre al concepto que pasa a denominarse Controles de Calidad.
Puedes ver esta nueva funcionalidad en el siguiente vídeo:
Blog de Digi21 