Define overloading of operators

The operator "+" can be used to add two numbers of the same type, or to append two pieces of text, or to join a piece of text with a number.

The suggestion is that operator overloading should be strictly defined as to the arguments they can handle. Too many times, GeoMedia complains that you cannot add a short to a long integer or a real to an integer. A possibility is to create the definition so that reals added to integers return reals, and short integers added to long integers return long integers, and then use the destination of the result to determine if the operation makes sense. This will reduce hair-pulling frustration when it is not possible to determine why GeoMedia does not like an operation between what looks like 2 valid data types.

The plus operator "+" should also be used to add vectors together.

Define a more formal Geomedia language

Each Geomedia interactive command translates into the underlying instructions for the Geomedia runtime system. Rather than define a large number of internal routines, I would like to suggest the formal definition of a GeoMedia Language with its own constructs and ability to specify macros, subroutines and functions.

Whenever an instruction is executed through the user interface, there should be an underlying statement or sequence of underlying statements that correspond to the instruction. Furthermore, the statements or execution should be captured on a log file for the session, so that it is possible to go back later on to see exactly what happened or transpired and provide a means of repeating the sequence of statements.

In general, it should specify different data types and operations among them, control sequences (such as a series of statements, a decision control sequence, and iterative sequences), arrays, assignments and the ability to define functions and subroutines that take parameters. The language should be oriented to geospatial concepts rather than to database or general data processing concepts.

The language definition should be based either on an existing language, or on a brand new language, but deal with the language of spatial concepts, and keep operations such as database queries hidden in the runtime system.

More data types

The current data types include various precision and range of integers, real numbers, point, line and polygon types with restrictive operations between them.

I would like the ability to specify orientations and vectors as data types. The Vector data type should take 3 fields for X, Y, Z and the orientation data type should be the amount of rotation about an axis or as a 3x3 rotation matrix, or as a combination of roll, pitch and yaw. A more general data type should be the transform, which is a 4x4 matrix including both the 3x3 rotation matrix and the vector.

The mathematics of transformations, and operations on vectors and transforms and fixed and moving coordinate systems, is well understood in the literature of robotics which deals with motion in space, and well defined in many languages for controlling robot motions.

The purpose of these additional types is to provide a level of abstraction to simplify the conceptual computation. Instead of specifying the x,y,z components of translation in 3-d space, we could easily ask that a point, line or area be moved by a vector specified by the 3 components. This is particularly useful when all three components are specified and used in multiple places.

Automatic Save of Workspace definitions

Many times, GeoMedia appears to be stuck in a loop, and does not respond to any mouse gestures or keyboard input. In that situation, there is no choice but to kill the GeoMedia process. This means that all the work since the time of login, or the time of last save of the workspace is lost.

At other times, after some lengthy number crunching, there is a Windows error, and the GeoMedia process is killed by Windows, with the same unhappy result that anything done until the time of the last save of the workspace is lost.

I suggest that a means of automatically saving the current workspace would save a lot of time, grief, bad temper and cuss words. The ability to specify that the geoworkspace be saved every so many minutes, or every so many GeoMedia operations would provide a solution to this situation.

The backups should include a version number the keeps increasing. If the geoworkspace is relatively small, it should not occupy much CPU or storage space, but it would definitely be a great time saving productivity improvement, and deleting the additional versions, while it may appear to be a chore, is certainly less annoying than having to redo all the work that was lost.