Exercise 4 Dynamic Community Map Translation (Schema Handling)
Data Community Mapping (Esri File Geodatabase)
Overall Goal Create a workspace to generate a new Community Mapping dataset using an existing schema
Demonstrates Dynamic Schemas
Start Workspace None
End Workspace C:\FMEData2018\Workspaces\DesktopAdvanced\ReadWrite-Ex4-Complete.fmw

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.

Format GML (Geography Markup Language)
Dataset C:\FMEData2018\Data\Emergency\FireHalls.gml
Format MapInfo TAB (MITAB)
Dataset C:\FMEData2018\Data\Parks\Parks.tab

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:

Reader Format GML (Geography Markup Language)
Reader Dataset C:\FMEData2018\Data\Emergency\FireHalls.gml
Writer Format GML (Geography Markup Language)
Writer Dataset C:\FMEData2018\Output\Training\NewCommunityMap.gml
Workflow Options Dynamic Schema

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:

Reader Format MapInfo TAB (MITAB)
Reader Dataset C:\FMEData2018\Data\Parks\Parks.tab
Workflow Options Single Merged Feature Type

Connect the new reader feature type up to the existing writer feature type, and add bookmarks for 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 fire halls, 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:

Reader Format Esri Geodatabase (File Geodb Open API)
Reader Dataset C:\FMEData2018\Data\CommunityMapping\CommunityMap.gdb

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 the resource schema is being used.

Inspect the properties for the writer feature type. 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 rerun it.

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

By completing this exercise you have learned how to:
  • Create a dynamic workspace with multiple readers
  • Add a Resource Reader
  • Change the source of a dynamic workspace schema
  • Add and remove hard-coded attributes in a dynamic workspace

results matching ""

    No results matching ""