Here we continue on with a project to redefine garbage collection schedules.

In the first exercise we used various transformers to divide addresses into five separate groups. Now the task is to refine that work by estimating the number of residents per address based on the zone type it falls within:

• Single-family residences: 2 adults
• Two-family residences: 4 adults
• Multi-family residences: 12 adults
• Comprehensive development zone: 8 adults
• Commercial properties: 1 adult

1) Open Workspace
Open your workspace from the previous exercise.

If you gave that workspace a version number in its name, then you should make a copy of the workspace with a new version number. For example, if you saved it to GarbageCollection-v1.fmw then make a copy named GarbageCollection-v2.fmw and open that for editing.

Alternatively you can open the workspace C:\FMEData2018\Workspaces\DesktopBasic\Design-Ex2-Begin.fmw:

The remaining transformers in the "Transformers" bookmark are these:

2) Add Reader
The first task here is to identify which planning zone each address falls inside. For this we need to read the zoning data and carry out a spatial join. To read a new dataset of data in a different format requires a new reader.

So, select Readers > Add Reader from the menubar. When prompted enter the following parameters:

A reader is added to the Navigator window and a feature type to the canvas. Move the feature type into the Zoning bookmark:

3) Create Spatial Join
To carry out a spatial join we'll use a PointOnAreaOverlayer transformer; this is a type of join called Point-in-Polygon.

So, move the PointOnAreaOverlayer transformer from the "Transformers" bookmark to the "Spatial Join" bookmark. Connect the newly added Zoning data to the Area port and the output from the Sampler to the Point port:

Inspect the parameters and put a check mark against Merge Attributes:

This is the first transformer we've used that has a live <Rejected> port. For now we'll leave it to terminate the translation, since during testing we want to know about anything that causes a failure of the transformer.

Attach an Inspector to the Point output port and run the translation. The overlay and attribute merging should cause each address to be given a zone name and category.

4) Calculate Residents
The next step is to set how many residents live at a certain address according to its zoning type.

We know that:

For example, zones RS-1, RS-2, RS-3 are all single-family zones and we assume a total of two adults per address. This makes it slightly more complex because we need to match a zone type using a "begins with" string comparison.

This can be done using an AttributeManager with Conditional Values.

This is a slightly complex function, but luckily the AttributeManager inside the "Transformers" bookmark is already set up for this purpose. So move the AttributeManager into the "Calculate Residents" bookmark and connect it to the PointOnAreaOverlayer:Point output port:

If you are interested in what Conditional Values look like, open the parameters dialog for the AttributeManager and click the drop-down arrow in the Attribute Value field for the Persons attribute. Choose Conditional Value:

This opens a Tester-like dialog with multiple conditions that test for each zone type, and an attribute value to set them to:

5) Create Residents
We now know (or have approximated) the number of residents per address. However, we must apply that number in a way that will affect the output. The simplest way to do this is to create multiple copies of each address, one for each resident.

For example, for an address with eight residents, we'll create eight address points.

This can be done very simply with a Cloner transformer. So add a Cloner transformer into the Calculate Residents bookmark. Connect the AttributeManager to its input and its output to the StatisticsCalculator:

Inspect the Cloner parameters. For the Number of Copies parameter, click the drop-down arrow and choose Attribute Value > Persons:

This will create <Persons> copies of the original addresses (note that the transformer doesn't output the original as well, so the output is <Persons> features, not <Persons>+1).

6) Run Translation
Make sure an Inspector is still attached to the Aggregator transformer and run the translation. The translation will fail with the error message:

This is because addresses without a resident (e.g. Industrial) have no Persons attribute and are being rejected by the Cloner transformer. The <Rejected> port is still set up to terminate the translation and so we get this error.

There are various choices to handle this. We could:

1. Change the Workspace parameter Rejected Feature Handling to Continue Translation
2. Add a transformer to handle the Cloner's rejected features
3. Set the Conditional Values to give a value of zero, instead of not including a value at all

Setting the Conditional Values would be the best solution to deal with the problem directly. But there might be other causes for rejected data, and we want to deal with that without having a terminated translation.

Setting the Rejected Feature Handling parameter means all <Rejected> ports would ignore rejected output. This might be useful in a production workspace, but in testing we would probably want to terminate the translation, so we can be aware of issues immediately.

So for us the better solution is to add a transformer to the Cloner <Rejected> port. We don't really need to inspect or log these features because we know that they will exist. So simply connect the <Rejected> port to a small transformer called a Junction:

This will handle the rejected output, but quietly drop it without further fuss.

Re-run the translation. The output should be five groups of point feature again, but in a different pattern to the end of the previous exercise:

7) Write Output
Now to write some output. The simplest method is to connect the Aggregator output to the PostalAddress output feature type and re-run the workspace.

However, it would also be useful to rename the output feature type and remove all of its attributes, since they are from the reader dataset and don't really apply here. So open the writer feature type parameters dialog. In the Parameters tab rename the feature type to GarbageZones. In the User Attributes tab, remove all of the attributes that are being written:

Also change the GeoPackage writer parameter Overwrite Database to overwrite the database each time we run the workspace:

That way we don't accumulate more and more results in the same dataset.

8) Version Workspace
If you are versioning your workspace, this is probably a good point at which to save a new version. Then if the FeatureWriter doesn't work, we can easily revert to a simple writer.

9) Add FeatureWriter
Add a FeatureWriter transformer in place of the writer feature type and connect the Aggregator to it:

This will cause an Aggregate port to be added. This becomes the default feature type name in the output.

10) Set Up FeatureWriter
Inspect the FeatureWriter parameters. Set the Writer format and dataset parameters to the GeoPackage output dataset already defined:

Click the Parameters button and be sure to set the parameter to Overwrite Database:

Under the Feature Type definition, rename the output table to GarbageZones:

Then click on the User Attributes tab, change the Definition to Manual, and remove all of the attribute definitions (they won't be required):

Accept the changes. Now the FeatureWriter is set up to write the data, and you can locate the GeoPackage writer in the Navigator window and delete it.

11) Add Integration
If you wish, and if you have an account available, add an Integrations transformer such as the Emailer or the DropboxConnector to the Summary output port of the FeatureWriter.

Notice that the Summary feature has an attribute called _dataset that defines the dataset written. It can be used in the Emailer (for example) to define a file to be attached to the email:

Now when you run the workspace, the data will be written and then emailed to someone.