You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, the formula calculation is a function that can be executed afterwards a resulting geometry is processed.
These calculations also happend when the 'processing' was done. So maybe it is a speed enhancement to keep all information while processing to collect the information for the brdr_formula?
The text was updated successfully, but these errors were encountered:
I feel these should be kept separate. The act of realigning and the act of comparing the resulting geometry with the source geometries from which it is derived are conceptually different. We could apply the same comparison on geometries that are not realigned, and the API should ideally reflect this. Also, we could now "easily" represent the provenance of the resulting geometry (i.e. the realignment) in PROV-O standard and the comparison (which is a type of observation) in SSNO. Integrating both in the same functions and code base will couple the implementation of both aspects, making it harder to afterwards change them or use them with different alignement procedures/observations.
At the moment, the formula calculation is a function that can be executed afterwards a resulting geometry is processed.
These calculations also happend when the 'processing' was done. So maybe it is a speed enhancement to keep all information while processing to collect the information for the brdr_formula?
The text was updated successfully, but these errors were encountered: