Previous exercises have involved translating the Community Mapping dataset, used by the planning department for various community mapping tasks.

However, as time has moved on the Community Mapping dataset has become out of date. The planning department therefore wants to start building a new community map dataset. The dataset will have new data, but use the existing schema where possible. They also – in order to use an open standard – want a format change to GML.

At the moment two source datasets have been identified as being required in the new community mapping "database". They are fire halls (source format: GML) and city parks (source format: MapInfo TAB).

So, let's create a new workspace to handle that scenario.

1) Inspect Data
Inspect the two source datasets in the FME Data Inspector, to become familiar with them.

There was already parks data in the community mapping, but this time it is polygons, not points. The FireHalls data is entirely new for community mapping.

2) Start Workbench
Let's get started by generating a workspace as follows:

The dynamic option is chosen so that we can use a schema other than that of the dataset being translated.

3) Add Reader
So far, so good. Now let’s add a reader for the new parks data by selecting Readers > Add Reader and using the following details:

Connect the new reader feature type up to the existing writer feature type, and label the feature types for easier recognition.

4) Add Resource Reader
One of the requirements was to use the existing community mapping schema where possible. With the firehalls it isn’t possible, since that never existed in the Community Mapping Geodatabase. However, the parks dataset did exist in that Geodatabase, so we’ll need to use that schema.

So, select Readers > Add Reader as Resource and, when prompted, enter the following details:

NB: If you see the parameter for "Individual Feature Types/Single Merged Feature Types" then you chose "Add Reader" not "Add Reader as Resource". Click Cancel and pick the correct menu entry this time!

Click OK and the reader is added as a Resource:

5) Adjust Dynamic Parameters
Now we need to make sure that resource is being used.

Inspect the properties for the writer feature type either in its parameters dialog or the Parameter Editor window. Click the Schema Sources browse button.

Put a checkmark against CommunityMap. Ensure Parks is NOT checked but that FireHalls is:

Check the other dynamic parameters. Since we are writing both points and polygons, for some formats we might have to change a Geometry setting. But since GML can cope with both geometry types we won't have to take any action; in fact there will not even be a parameter for geometry type! Accept the parameter changes to close the dialog.

6) Save and Run Workspace
Save the workspace and then run it.

Inspect the output. There should be two layers: one for fire halls, the other for parks. The parks dataset should have the schema from the Geodatabase (not the MapInfo parks), including attributes for ParkName, ParkAddress, and ParkURL (even if there is no data to fill some fields yet):

Notice that it also has OBJECTID, which came from the Geodatabase and we don’t really need.

7) Delete Attribute
Revisit the writer feature type parameters. Under Attributes to Remove type OBJECTID into the first row. You won’t be able to select it from the drop-down list because it comes from a resource reader, not a real reader:

But don't accept the changes yet...

8) Add Attribute
A last-minute request is to add an attribute – LastUpdatedBy – to all tables in the output.

So, click on the User Attributes tab and add this new attribute. Make it a 30 character string.

As you can see, there is no need to change the attribute definition mode - it should stay as dynamic.

9) Re-Run Workspace
Save the workspace and run it again.

Inspect the output. Notice that OBJECTID will not appear as an attribute. LastUpdatedBy does appear, albeit that it doesn’t have a value yet.