Smallworld 4.0 and 4.1
From fmepedia
| Table of contents |
Q) What differences are there using FME with Smallworld v4 instead of v3.x?
A) Some differences are:
- The reader/writer for Smallworld v4 uses different technology (SWAF) which permits FME to access the data directly.
- Translations can now be run from within Workbench.
- Smallworld data can be viewed in the FME Viewer.
- For you mapping file types, the writer type name has changed from sworld to sworld400
- The Smallworld FME Interface is a different installation.
- It isn't necessary to set sworld_type within Workbench for v4 - presumably because you define the geometry name as an attribute and assign a type there.
- Datastore is now added to the feature type name; eg instead of rail_line you now have gis.rail_line
- The Smallworld SWAF 4 FME Translator shows significant performance improvements over the Smallworld 3 translator.
Q) Does FME support Smallworld 4.1?
A) Yes. This is now (from FME2010) the version that FME will expect by default.
Q) Can I revert this back to Smallworld 4.1?
A) Yes. If you look in your FME installation folder you will see we ship DLLs for both 4.0 and 4.1:
Notice there are 3 DLLs. swordswaf is the one we use. By default it is a copy of the 4.1. So, if you wish to get support for 4.0 you need to overwrite it with a copy of the 4.0 DLL.
Interestingly, although official support started with FME2007, because the FME components of the reader/writer are unchanged, you may (unofficially) find it works with FME versions back as far as FME2004-ICE, provided you copy the DLL into the right location.
Q) What changes do I need to make to a Smallworld 3.x mapping file to run it with a Smallworld 4.x installation?
A) Issue 1
Feature Type names will have changed.
In the SWORLD v3.x reader/writer datastore was not used, for example the Feature Type name would be...
rail_line
In the SWORLDSWAF reader/writer, the datastore is now added to the feature type name, for example...
gis.rail_line
So all existing mapping files will have to be changed to include the datastore name. This will occur in at least two places for each feature type, the DEF line & the correlation lines:
SWORLD_DEF gis.rail_line \ annotation sworld_text \ centre_line sworld_chain \ name char(30) \ type enum(rail_type)
and
DWG CAMBRIDGE_RAILWAY \
name %name \
type %type \
LabelRotation %LabelRotation
# autocad_entity autocad_line \
# Change the sworld_name from route to "centre_line"
SWORLD gis.rail_line \
name %name \
type %type \
@SupplyAttributes(sworld_geometry{0}.sworld_type,sworld_text) \
@SupplyAttributes(sworld_geometry{0}.sworld_name,annotation) \
... etc
One consideration is that we will add a keyword to define the datastore, for example...
SWORLDSWAF_DATASTORE_NAME gis
...so the SWORLDSWAF writer would take "rail_line" and make it "gis.rail_line". This hasn't been implemented at this time.
Issue 2
The reader or writer keyword will have changed, for example change...
WRITER_TYPE SWORLD
...to...
WRITER_TYPE SWORLD400 WRITER_KEYWORD SWORLD
