Some time ago I posted about the Magik Dialog Designer and that it would be made freely available soon. Well I am happy to say that that day has come (actually was a couple of weeks ago) and it is now available on the Magik Components SourceForge page. Thank you to Graham Garlick for putting together such a useful tool!
This tool essentially lets you create GUIs in SWAF using drag-and-drop and then creates all the relevant Magik code (including module structures and XML files) to include that GUI in your product. It also stubs out any of the action methods associated with buttons.
For now you will have to browse the Magik Components source code tree yourself and find the module. You can follow the CVS connection instructions to setup CVS on your machine to check out the latest Magik Components code. If you are not interested in installing CVS you could e-mail Graham at graham [at] ifactorconsulting [dot] com and ask him for the Dialog Designer zip file. Tell him Alfred sent you :)
(The module should eventually make its way into the Download Magik Components section.)
Since our time together at Navigant/Smallworld/GE, I have always been a fan of Graham and his creative innovations with Magik. In my opinion, this Magik Dialog Designer is one of his greatest Magik achievements. Although his Raster Calculator was pretty cool too. But I ramble on... so please go download the Dialog Designer yourself and have fun.
Tuesday, July 31, 2007
Magik plugin for Eclipse
If you are a Magik developer that prefers to use Eclipse over Emacs you should know that ASTEC today released version 0.5.1 of their free Magik Development Tools (MDT). To read more, visit http://www.mdt-project.com. There is also a white paper that gives a good overview of what MDT together with Eclipse can do for you.
Monday, July 30, 2007
FME 4.1 Translator DLL problem
[Update: 07Sep2007 - see the comments below about additional information about where to find sworldswaf.dll files and which one to use where.]
I tried to use the FME 4.1 SWAF interface today and ran into a problem where the FME clients (eg., Universal Viewer) could not recognize any of the data dictionary information queued up in Smallworld for export to FME. I contacted GE Help Desk and they were very quick (on the order of minutes) to send me a new sworldswaf.dll file that must be copied into the FME root folder (eg., c:\program files\fme). This fixed the problem with the FME 4.1 interface but then introduced the problem for the FME 4.0 SWAF interface. Not that big a deal unless you are running two versions of SWAF with the same FME clients.
Interesting notes about the DLL versions. The FME 4.1 documentation says that you need to be running FME 2006 GB build 2651 at a minimum with version 1.1.0.0 of sworldswaf.dll. The version of the DLL that shipped with my version of FME build 2651 was 1.0.1.0. Either the documentation has a typo or Safe Software does not have the latest version of the DLL. Anyways, the version of the DLL that the GE Help Desk sent me was 1.0.0.11 (that's right, it seems like an earlier version number). Apparently this DLL is still too new to have made it onto either GE or Safe Software's web sites. You will need to log a case with the GE Help Desk to get the correct DLL.
On a related note: One of my Smallworld-FME presentations was accepted to the 2007 Americas Smallworld Users Conference in Colorado this year. I hope to see alot of you there. More about that later.
I tried to use the FME 4.1 SWAF interface today and ran into a problem where the FME clients (eg., Universal Viewer) could not recognize any of the data dictionary information queued up in Smallworld for export to FME. I contacted GE Help Desk and they were very quick (on the order of minutes) to send me a new sworldswaf.dll file that must be copied into the FME root folder (eg., c:\program files\fme). This fixed the problem with the FME 4.1 interface but then introduced the problem for the FME 4.0 SWAF interface. Not that big a deal unless you are running two versions of SWAF with the same FME clients.
Interesting notes about the DLL versions. The FME 4.1 documentation says that you need to be running FME 2006 GB build 2651 at a minimum with version 1.1.0.0 of sworldswaf.dll. The version of the DLL that shipped with my version of FME build 2651 was 1.0.1.0. Either the documentation has a typo or Safe Software does not have the latest version of the DLL. Anyways, the version of the DLL that the GE Help Desk sent me was 1.0.0.11 (that's right, it seems like an earlier version number). Apparently this DLL is still too new to have made it onto either GE or Safe Software's web sites. You will need to log a case with the GE Help Desk to get the correct DLL.
On a related note: One of my Smallworld-FME presentations was accepted to the 2007 Americas Smallworld Users Conference in Colorado this year. I hope to see alot of you there. More about that later.
Friday, July 20, 2007
Where did Geography go?
One thing I regret about my undergraduate studies is that I took no geography courses. I only discovered GIS after I graduated. I enjoy the technical nature of GIS very much but have always been intrigued by the geographic questions that the GIS technologies strive to address.
So you might ask: "if you are intrigued by Geography and GIS why are you working with Smallworld?". Good question... GE seems to have made a decision not to market the Smallworld Core Technology as a GIS but rather to present it as a network management suite of tools. I know that Smallworld can be used for GIS analysis but the product development has not emphasized that at all. (I would be interested to read how you are using the Smallworld tools to understand non-utility geographic issues.)
So because I am still interested in GIS and Geography, Jerome E. Dobson's article "Bring Back Geography!" resonated with me. If you are at all interested in Geography (or wonder what it is) this article is definitely worth reading. (Yes, it is an ESRI site. But if you are interested in Geography and GIS in general, you go to where the information is)
Dobson writes of the role of Geography largely in the United States of America. He writes about how during the 1st and 2nd World Wars, geographers were an important part of preparing for peace after the war. And then he points out that Geography was purged from the major USA Universities after World War II. His call is for geographers to reassert themselves into the public consciousness so that they can make important contributions for the common good.
Because of my daily work with GIS technologies, I always fancied myself a bit of a geographer. Dobson writing about GIS says...
I do actually seem myself as a bit of a clerk (or consultant to clerks) that manages data for others. Not that being a clerk is a bad thing... it puts food on my family's table and is something that is also technically challenging and rewarding. But this article has got me thinking about how I can take the next step beyond technology and start learning more about Geography to understand my world better and then also contribute to its common good.
So you might ask: "if you are intrigued by Geography and GIS why are you working with Smallworld?". Good question... GE seems to have made a decision not to market the Smallworld Core Technology as a GIS but rather to present it as a network management suite of tools. I know that Smallworld can be used for GIS analysis but the product development has not emphasized that at all. (I would be interested to read how you are using the Smallworld tools to understand non-utility geographic issues.)
So because I am still interested in GIS and Geography, Jerome E. Dobson's article "Bring Back Geography!" resonated with me. If you are at all interested in Geography (or wonder what it is) this article is definitely worth reading. (Yes, it is an ESRI site. But if you are interested in Geography and GIS in general, you go to where the information is)
Dobson writes of the role of Geography largely in the United States of America. He writes about how during the 1st and 2nd World Wars, geographers were an important part of preparing for peace after the war. And then he points out that Geography was purged from the major USA Universities after World War II. His call is for geographers to reassert themselves into the public consciousness so that they can make important contributions for the common good.
Because of my daily work with GIS technologies, I always fancied myself a bit of a geographer. Dobson writing about GIS says...
In contrast, advances in GIS alone are likely to cast us as clerks handling data for the ecologists, political scientists, economists, and other current leaders in these topics
I do actually seem myself as a bit of a clerk (or consultant to clerks) that manages data for others. Not that being a clerk is a bad thing... it puts food on my family's table and is something that is also technically challenging and rewarding. But this article has got me thinking about how I can take the next step beyond technology and start learning more about Geography to understand my world better and then also contribute to its common good.
Wednesday, July 11, 2007
how to exhaust your UVAs without knowing it
Unique Value Allocators (UVAs) in Smallworld are special objects that return a unique integer value for system IDs only once. Theoretically you could exhaust your UVA bucket at some point and then you will not be able to insert any more RWOs, geometries, links, nodes and other system objects.
There are a number of ways to exhaust your UVAs but one that came to my attention recently is the method :copy_transform() on various geometry classes. I have used this method in the past for exporting geometries to some other file format. What was strange at the time was that when I used this method I received a "database not writable" error. That raised some red flags in my mind: why does the database need to be writable if all I intend to do is read data from it and export it to another file format?
It turns out in that case that I was using :copy_transform() to convert the coordinates of geometries from one coordinate system to another. Unbeknown to me, the :copy_transform() method actually makes a copy of your geometry before transforming it. So you are left with two copies of the same geometry in the database after the transform. And creating a copy of the geometry uses UVAs (which cannot be recovered) and involves more system resources than you would likely need for your intended purpose -- simply to transform the coordinates of a geometry from one coordinate system to another.
I am writing all this because we have come across a situation where an installation used export code from another vendor that apparently makes frequent use of the :copy_transform() method to export geometry data into a 3rd party format. Recently that installation's main UVA was exhausted. There is nothing wrong with transforming your coordinates before exporting to a 3rd party but there are simpler ways of doing transforms using !current_coordinate_system! that do not gobble up UVA resources (maybe I will post about that some day).
I would recommend that you run the following command at the Magik prompt:
MagikSF> print_users_of(:copy_transform|()|)
$
The output of this procedure will list all methods that call :copy_transform(). Scan the list and if any of the method names (or classes that they are written on) look as though they are not core Smallworld methods/classes, please confirm that that code cannot be done some other way without using up your precious UVAs.
(There are other ways to exhaust your UVAs prematurely, but I wanted to focus on this one approach today)
There are a number of ways to exhaust your UVAs but one that came to my attention recently is the method :copy_transform() on various geometry classes. I have used this method in the past for exporting geometries to some other file format. What was strange at the time was that when I used this method I received a "database not writable" error. That raised some red flags in my mind: why does the database need to be writable if all I intend to do is read data from it and export it to another file format?
It turns out in that case that I was using :copy_transform() to convert the coordinates of geometries from one coordinate system to another. Unbeknown to me, the :copy_transform() method actually makes a copy of your geometry before transforming it. So you are left with two copies of the same geometry in the database after the transform. And creating a copy of the geometry uses UVAs (which cannot be recovered) and involves more system resources than you would likely need for your intended purpose -- simply to transform the coordinates of a geometry from one coordinate system to another.
I am writing all this because we have come across a situation where an installation used export code from another vendor that apparently makes frequent use of the :copy_transform() method to export geometry data into a 3rd party format. Recently that installation's main UVA was exhausted. There is nothing wrong with transforming your coordinates before exporting to a 3rd party but there are simpler ways of doing transforms using !current_coordinate_system! that do not gobble up UVA resources (maybe I will post about that some day).
I would recommend that you run the following command at the Magik prompt:
MagikSF> print_users_of(:copy_transform|()|)
$
The output of this procedure will list all methods that call :copy_transform(). Scan the list and if any of the method names (or classes that they are written on) look as though they are not core Smallworld methods/classes, please confirm that that code cannot be done some other way without using up your precious UVAs.
(There are other ways to exhaust your UVAs prematurely, but I wanted to focus on this one approach today)
Subscribe to:
Posts (Atom)
Posts
