Integrating OSM, Navteq and ArcGIS Online with Smallworld

Here are some demo videos showing how you can integrate OpenStreetMap, Navteq and ArcGIS Online (or ESRI Data Appliance) data with Smallworld. The videos only show capabilities. It is up to the user to secure appropriate licensing from the relevant data vendors.

How to write a delimited list in Magik

Over the years I have seen lots of approaches to writing a delimited string. They usually involved creating a loop, writing a delimiter after each element in the collection and then finally removing the last delimiter that was added in the loop.

For example, if you have a list of voltages and you want to concatenate them all in a string that is delimited with a comma and a space ", " you could write something like this...

voltage_string << "  "
_for i_volt _over voltages.fast_elements()
_loop
 voltage_string +<< i_volt+", "
_finally
 voltage_string << voltage_string.subseq(1,voltage_string.size-2)+"."
_endloop

... or you could use the core write_string_with_separator() procedure and write equivalent code like this...

voltage_string << write("  ",
                        write_string_with_separator(voltages,", "),
                        ".")

I like the latter approach because it is more concise and it very clearly indicates what you are trying to do... write a string with delimiter.

A call for identifying your custom changes

Reviewing code changes is difficult at best, but when reviewing a "basic_change" in Magik, it would be very helpful if the changes were very clearly bracketed with private comments.

For example, you might have an #EMQ like this...

_method some_class.some_method()
## some_method() : some_return_value
##
## does something crazy

_global a

(a.b[c], a.b[d]) << (a.b[d], a.b[c])
_endmethod
$

... which you might want to refactor to be more robust. It would be really, really helpful to future code reviewers if you very explicitly indicated which lines of code you changed. Like this...

_method some_class.some_method()
## some_method() : some_return_value
##
## does something crazy

_global a

# BEGIN CHANGES
#(a.b[c], a.b[d]) << (a.b[d], a.b[c])
_try _with cond
(a.b[c], a.b[d]) << (a.b[d], a.b[c])
_when error
write("!!! EMQ !!!",cond.report_string)
_endtry
# END CHANGES
_endmethod
$

You can see that I actually commented out the original line and then put a copy of the line back in the _try block. This makes it very easy for a reviewer (and text diff tools) to see what has changed. I would not recommend using this approach for your own product code. Source Code control systems can identify these changes for you. What I am more concerned about is cases where you have redefined a core Smallworld method to address some business requirement. Once compiled into the image, it is very difficult to find the original version of the method, so the more that you can document as a customizer, the better it will be for future code readers.

Igor over at MagikEmacs pointed out to me that Alt-c in his extended version of Emacs does exactly this "changed code block" highlighting for you. You can see an example in his Screen-cast #3 at 3:50 where he uses exactly this technique.