Today to represent two-dimensional data from a database on a screen, user is forced to overcome jungle of spacial data types (redundant objectively, and pretentious as a result), and than to brake head how to programme OpenGL (or DirectX - how it will not lucky to whom) to display obtained on a screen. Apparently, similar troubles wait users, when ISO JTC1 SC32 WG3 will create next, pretentious data types for three dimensional constructions.
What is needed? There exist function 'print' in all programming languages for output varianbles of a program on screen. Including textual variables. So let it require spacial data from database by this textual string before, and display obtained instead of textual string itself.
It will be enough for user to call one function, we shall name it as 'printg', in which user specify what 3D-objects from database must appear on a screen. This function being called first time, automatically forwards all mouse motion commands of objects and motion of camera into DBMS; all messages about updating coordinates of objects, obtained from DBMS, automatically forwarded into Window System. It will possible to apply the same function to send order to change coordinates on query language (change immediately is displayed on screen). And this function can be called on any programming language.
This is breakthrough in office technology. All earlier known 3D-interfaces (3DMLW, 3DXML, COLLADA / OpenGL, DirectX) are designed with target of some cognitive abilities, which as experiments show, average person cannot accomplish. Difficulties related to the usage of 3D-objects appear because of inferior quantity of interface, instead of difficulty of three-dimensional task. I propose to add function 'printg' into common input-output libraries to allow users finally drive its own work, which should make user more productive and as result more happy.
More detailed description is presented on p.209-271 of separate pdf-document. 3D-construction is presented in it as hierarchy of points, triangles, figures (groups of triangles), groups of figures, groups of groups, etc. Record, containing these objects, must be bound by foreign key. To extract all triangles of a figure or a group, it's necessary to select by operator 'SELECT' not only record, being this figure or group, but also all records, located below it in hierarchy - up to records, which present 3D-points. For this, tables of these records are listed through point - 'select * from group3.group2.group1.triangle.point' - as this is accepted in classical object-oriented languages [1]. Names of tables are not important, because points are always expected to be located on the most lower level of hierarchy of each branch of tree, triangles - on one level above, and records of other levels are not visualized [2]. Before transformation into format X11 (or into format of Microsoft Window System, if database client works in 'Microsoft Windows'), invisible triangles will be removed from result of query, and partly visible triangles will be cut to their visible parts. So any program displays contents of a database on screen by function 'printg("select * from group3.group2.group1.triangle.point")'.
Similarly it's also possible to specify whole hierarchy of records from figure or group to 3D-points in operator 'UPDATE' - 'update group3.group2.group1.triangle.point set ...'. So any program changes position of an object in database and on screen by function 'printg("update group3.group2.group1.triangle.point set ...")' [3].
Thus possibilities of OpenGL must be incapsulated inside DBMS.
After all, it is known long ago from science of science, that new point of growth, jump appears at creating of new type of instrument, instead of next product by old instruments. Read at least classicist Eugene Garfield.
P.Scarponcini. SQL Multimedia and Application Packages - Part 3: Spatial. Bentley Transportation, 2000-03-26. http://www.wiscorp.com/sqlspat.zip
Dima Turin, dmitryturin@yandex.ru