Showing posts with label swaf. Show all posts
Showing posts with label swaf. Show all posts

Friday, July 9, 2010

FME Import Zoom to Smallworld Map

In the SWAF version of the Smallworld-FME plugin, it would be nice to have the current Smallworld map "goto" the bounds after the FME import has completed. This comes in handy when you want to easily find your just-imported data for subsequent review.

Apparently this functionality used to exist in the pre-SWAF version of the FME plugin.

I have uploaded a sample of some tweaks you can make that will enable this functionality at Smallworld version 4.x (SWAF).

The basic steps are:
  1. in fme_tics_client.private_run(), determine if there are any smallworld_product.applications that might be interested in knowing where the FME-imported geometry bounding box is
  2. if there are any such applications, then create a dynamic variable geometry_set that fme_tics_client.int!received_feature() can add newly-created geometries to
  3. back in fme_tics_client.private_run(), send a :goto_request databus message to all the relevant applications with the geometry_set populated in fme_tics_client.int!received_feature()

Have a look at this file (fme_goto_import_geometry_set.magik) to see the details of how it is done.

Friday, October 23, 2009

Dialog Designer 1.9.5 now available

Graham Garlick at iFactor Consulting has uploaded v1.9.5 of the open source Dialog Designer. You can get the latest version by browsing to http://www.ifactorconsulting.com and clicking on the "Download Version 1.9.5 Now..." link.



Here are the release notes for 1.9.5:
- create additions/changes sub-source directories for core code modifications
- bug fix (statusbar progress indicator element XML generation/parsing)
- exposed :allow_filtering? attribute for a tabular_list
- fixed statusbar rendering of multiple springy panes
- fixed window_pane rendering

I did not do a post for 1.9 so here are those release notes as well:
- added messages tab (define messages to support user-written code)
- fix issue where module.def 'requires' section was not updating
- various bug fixes, all minor.
- added recordset_gui_component widget
- added numeric input widget
- added 6th example dialog to the Help Document

If you have not used this tool, I would highly recommend it. You can create your GUIs without using this tool, but there are so many parameters to be aware of. Using this tool essentially allows you to incorporate known (and sometimes unknown) tips, tricks, workarounds and best practices from one of the best Magik coders around and put it into your own application.

Tuesday, October 20, 2009

Smallworld High Definition (part 2)

(My apologies to those who get their blog post comments on an RSS feed. This is a repeat of a comment from last night)

At the Users Conference in Glendale this week, John Eason was very excited to take me to see the "Smallworld HD" demo. All I can say is that there was some really cool stuff. With mostly only Magik changes, the developer (a Magikian in my mind) created a new interface that out-Microsofted Microsoft. The new GUI has all the standard Microsoft UI design elements but with a few iPhone-like tricks thrown in. The graphics are clear and crisp (a la the comments from "Anonymous"). The widget classes (as well as the geometry classes) now all inherit from a common set of ancestor classes to take advantage of new canvas rendering functionality and geometry caching.

As far as I am concerned, the new GUI will be the cool kid on every user's Desktop. I expect that non-GIS users will want a copy of the GUI on their desktop just to play with it and show off its cool functionality. The feature that I think is most like the iPhone is the one where you can grab the map with your pan cursor and "flick" it in a particular direction. When you are scrolling down the object list (think combination of Smallworld Explorer result list and Google Maps search result list) you can grab an object in the list and "flick" it up or down to scroll the map. While those of us who have worked with Smallworld for a long time have know of the software's power, I think these GUI changes will make the software more attractive and inviting for first-time users to interact with. There is definitely an initial "wow" factor that is combined with functionality that gives this GUI a type of "stickiness" as well. "Good job" to the team that is working this and I wish you much success in seeing it through to delivery.

If you are at conference this week, it is worth checking out this demo at the GE booth.

(According to new US Federal Trade Commission rules, bloggers are now supposed to reveal any freebies or payments they get for reviewing a product. Unfortunately for me, no freebie was provided. I can only hope that the beta version comes out soon.)

Wednesday, April 22, 2009

Determining map_view Pixel DPI

The other day I was trying to figure out the pixel DPI on my map_view so that I could size a raster_image on the map. I had always thought that !window_system!.screen_resolution() would do that for me. It seemed to work as long as I put in some additional empirical fudge factor. I discovered later that if I am working with map_view, I can use map_view.pixel_size to calculate DPI. map_view.pixel_size returns the size of a pixel in millimetres so to convert that to DPI...

_method map_view.if!dpi
## if!dpi : integer
##
## returns _self's DPI

_return (1/_self.pixel_size) * 25.4
_endmethod

Thursday, April 16, 2009

Exposing hidden data from Smallworld to FME

A member of the sw-gis group recently posted a question asking how to export join attribute information from Smallworld via FME. I responded to the group but thought the answer might be worth sharing here as well.

Question:

I'm using FME with Smallworld 4.0. How can I export join attributes (e.g., export transformer bank id with the transformer)? I coudn't find it in the FME workbench.


Answer:

I think the easiest way to do this is to use the fme_pseudo_field_factory.

For example...

If you’re your record exemplar is :transformer and the transformer_bank ID attribute is called :transformer_bank_id, then you can define a new FME Pseudo Field...

_pragma(classify_level=basic, usage={redefinable})
## used by FME SWAF interface to allow a customizer to add
## pseudo fields to the schema for Smallworld tables to be
## passed to FME.
transformer.define_shared_constant(:fme_pseudo_fields,
{fme_pseudo_field_factory.new_derived_field(:transformer_bank_id,:extdb_string)},
_false)
$

You can actually define more than one fme_pseudo_field for a given record exemplar if you want to.

Declaring :transformer_bank_id as a new derived field will make this "field" available to the FME feature. When FME asks a "transformer" for its :transformer_bank_id, it will simply call transformer_bank_id and use that value in the workspace.

There is nothing special about the naming convention of the pseudo field. The only thing to keep in mind is that the class on which you define :fme_pseudo_fields must respond (either as a method or field call) to the name of the derived field.

So you could actually accomplish the same thing as above with...

_pragma(classify_level=basic, usage={redefinable})
## used by FME SWAF interface to allow a customizer to add
## pseudo fields to the schema for Smallworld tables to be
## passed to FME.
transformer.define_shared_constant(:fme_pseudo_fields,
{fme_pseudo_field_factory.new_derived_field(:bank_id,:extdb_string)},
_false)
$


As long as you also have defined a method...

_method transformer.bank_id
## bank_id : integer
##
## returns self’s transformer_bank_id

_return _self.transformer_bank_id
_endmethod
$

The FME fme_pseudo_fields concept is very powerful because it allows you to send data to FME that is not stored in a single attribute in Smallworld.

I have used it in the past for exporting data from Physical Network Inventory (PNI). If you are familiar with that datamodel you will know that there are many layers of relationships. Some of the records have geometries and some do not. A customer wanted to export all underground and aerial routes (these are the features with geometry) but wanted to label the features in the exported format with data from a related non-RWO record. Using the fme_pseudo_fields approach made it very easy to create a Magik method that created a suitable labelling string based on the related records but expose the results to FME as a feature attribute.

Tuesday, November 11, 2008

Dialog Designer v1.8 now available

Graham Garlick over at iFactor Consulting has uploaded v1.8 of the open source Dialog Designer. You can get the latest version from the SourceForge Magik Components community or from a zip file at iFactor Consulting.

Here are the release notes:
  • autosave a copy of current XML dialog description to the generated module.
  • dt_dt language added (thank you Frank Wolff @ GE)
  • added button to refresh of icon list, to capture newly loaded modules
  • expose the double_click_notifier attribute for tabular_list and tree_list

Friday, May 16, 2008

Dialog Designer v1.6 now available

Graham Garlick over at iFactor Consulting has uploaded v1.6 of the open source Dialog Designer. You can get the latest version from the SourceForge Magik Components community or from a zip file at iFactor Consulting.

Here are the release notes:
  • added outlookbar widget
  • support progress_bar pane type in statusbar
  • support dropdown image button groups within a toolbar
  • click on rendered menubar or statusbar to jump to its editing tab

Tuesday, March 4, 2008

Smallworld FME 4.1 Interface takes data Back to the Future

I had a colleague point out to me yesterday that if you are using the Smallworld FME interface for CST 4.1 you need to verify that your date (and date_time I suppose) attributes are being exported correctly. After further analysis both I and he discovered that dates prior to 01Jan1970 and after 07Feb2106 will not be copied across correctly. The 07Feb2106 threshold may not be problematic for most Smallworld users but the 01Jan1970 threshold definitely is.

For example, if you have an "installed date" attribute of 04Dec1969 and you extracted it using the Smallworld FME 4.1 interface you would notice that FME recognizes it as 10Jan2106. So your feature ends up going back to the future but your users of the exported data come back to you.

I have raised a case with GE Help Desk on this issue and they are looking into it.

(I have not tested this on the Smallworld FME interface for CST 4.0.)

Wednesday, February 6, 2008

Dialog Designer v1.5 now available

Graham Garlick over at iFactor Consulting has uploaded v1.5 of the open source Dialog Designer. You can get the latest version from the SourceForge Magik Components community or from a zip file at iFactor Consulting.

Here are the release notes:
  • updated Documentation file.
  • fixed issue with hanging plugin action selection gui when a raster image was missing in CORE.
  • fixed issue with non-refresh of Magik/XML code when first going to the Magik/XML tab
  • added input mechanism to add extra slots to dialog Base Class
  • added input mechanism for setting pragma statement code settings
  • added input mechanism for adding additional slots to the base gui class
  • added input mechanism for setting the package for the dialog
  • es_es language edited (thank you Alejandro CaƱas [alexcaas at gmail dot com])
  • added unit_text_item widget
  • fixed :select_directory (open_file_dir widget) incompatibility with SW4.
  • fixed internationalization issue with the :top_dock,:bottom_dock (etc.) messages
  • added date_time_input widget

Friday, October 12, 2007

discovering which SWAF config.xml file to change

Have you ever wondered exactly where in the XML config hierarchy a particular plugin is defined? With XML file inheritance in SWAF, it can sometimes get very complicated.

I have created some enhancements to the XML parsing and plugin creation methods that allow you to track the one or many XML FILENAMES where a plugin is defined.

Usage:
  1. load this file
  2. start the application whose configurations you want to trace.
  3. get a handle on some plugin and then ask it for its debug!source_files. It will return a rope of XML file names that contain that plugin's definition in the order that they were encountered. I.E., the last XML file in the rope is the one that the plugin used for its definition.
For example:
MagikSF> smallworld_product.applications.an_element().plugin(:map_plugin).debug!source_files
$
sw:rope:[1-2]
MagikSF> print(!)
$
rope(1,2):
1 ".....\sw_user_custom\pni_gui\resources\base\data\config.xml"
2 ".....\sw_user_custom\custom_application\resources\base\data\config.xml"


so, this tells you that the "custom_application" config.xml file overrides the same plugin settings in PNI_GUI config.xml. If you want to make a change to the :map_plugin you will need to make it in CUSTOM_APPLICATION for the changes to take hold.

DISCLAIMER: DO NOT PUT THIS IN YOUR PRODUCTION CODE. This script is intended only for debugging your XML configuration files and should not be in any image that is writing data to a production database.