Quality checks rewritten from scratch for the third (and hopefully final) time

At the end of 2014 we introduced in Digi3D.NET the functionality Triggers.
They were quality controls were enabled in the code table and were executed in real time, that is: when storing a geometry was triggered (from
hence the name triggers) to analyze the rules assigned to the code.

It had the problem that it was a black box that only had a set of rules (programmed by us at Digi21) and the user was not free to add their own rules.

In 2016 we decided to change its name from Semantic Model and added a Boolean command named ANALIZAR_MODELO_SEMANTICO that basically enabled or disabled the analysis. In this way, we could disable it so that we were not being bothered by the program, but this was an evolution of what was presented in 2014: we still had a black box.

At the end of 2016 we added the [Semantic Model menu](http://(https://blog.digi21.net/2016/10/17/nuevo-menu-modelo-semantico/) that allowed (in addition to changing the value of the command ANALIZAR_MODELO_SEMANTICO), run semantic model tests on demand, analyzing all the geometries of the drawing file and showing the errors discovered in the task pane of the application.

We continued with the problem that the tests were a black box: If a user wanted to detect as an error a geometry with an odd number of vertices if the day on which the geometry was analyzed was Monday, he could not, because that test does not exist (nor do I think anyone would think of doing something like that).

Because our policy has always been to avoid black boxes, we decided to do a first erase and new account and change everything related to Semantic Model and make it user-programmable rules. To do this, we removed the semantic model selection dialog boxes and added to each code the ability to add a small script in any .NET language (in practice C#) that would run every time the user scans a geometry or every time the user forces an analysis on demand.

Thanks to this we were able to implement the model of MGCP in Digi3D.NET and for many years it is what they use in the Geographic Center of the Army to do their tests.

The problem of this model is that by disappearing the dialog boxes of selection of tests and requiring programming knowledge, in practice this
functionality was used in one or two companies.

On the other hand, in 2021 we added support for working with Python in Digi3D.NET.

Python is an introductory programming language that is very simple, and there are many more chances that advanced users of GIS and cartography will know it.

As Digi3D.NET is programmable in .NET since we put the surname .NET (previously called Digi3D dry), we used an implementation of Python from Microsoft called IronPython, and with very little effort we had the possibility to interpret Python scripts within the program exposing the entire .NET object model.

This solution was not very pythonic, because the exposed did not use lists or tuples, but .NET objects in Python, but it was completely functional and anyone could make scripts that interact with Digi3D.NET.No commands could be made, interactive, but scripts with logic.

The problem of this library is that it was anchored to the version Python 2.7 which is already outdated (curiously I just saw while looking for the link to IronPython to put it above that on December 12 of 2022 they have published a Python compatible version 3.x).

Precisely in December of 2022 we added to MDTopX the ability to run Python scripts. As MDTopX is a native 100% application, it makes no sense to use IronPython to use it as the engine of Python, so we have used CPython, which is the implementation of Python native.

Once finished the implementation of Python in MDTopX, as we had it fresh we decided rewrite from 0 also the Python engine of Digi3D.NET.

Due to this change, and seeing the possibilities that it had, we have again made another erase and count new, and we have started from scratch for the third time (hopefully this is the final one) and we have made it on the one hand super flexible, because anyone can add their quality controls (such as being able to detect as error geometries with an odd number of vertices if the test is run on a Monday), and on the other hand, we have dialog boxes to add and configure the quality controls graphically.

The trick is that we have added to the code tables editor a button that allows you to download the quality checks from the internet (from a GitHub repository).
You just have to press that button and you have them in your code table and you can assign them graphically to your codes.

If you know how to code in Python, you can modify these scripts, or start from scratch with your own system. If you create any quality controls that you think might be useful to the community, just forkear the repository add your quality controls and make us a pull-request that we will be happy to accept.

In addition, we have again changed the name of the concept that is now called Quality controls.

You can see this new functionality in the following video: