Brent Porter presented on using FME Server and custom applications to create a spatial viewer for Water Utility District data. The previous manual process of editing, extracting, and sharing this spatial data was replaced with centralized versioned geodatabase and self-service extraction services. Spatial and non-spatial data were integrated through loose coupling. The number of requests to the water utility program has decreased since deploying the new FME Server solution in 2009 which extracts and transforms the spatial data.

1. Features Made Easy
Brent Porter
Java, GIS/SDE and Interface programmer

2. Outline
 Introduction
 Domain Problem Breakdown
 Solution
 Detailed Discussion
 Demo!

3. Introduction
 Brent Porter
 Java, GIS/SDE and Interface Programmer at TCEQ
 Masters degree, Geography & Oceanography specializations
 “Lots” of ESRI experience
 12 years with ArcGIS
 10 Years with ArcIMS
 6 years with ArcSDE
 4 years with ArcGIS Server
 First started working with FME Spatial Direct in 2003-2004.
Installed FME Server at TCEQ in early 2009.
 11 years experience with Java & Javascript
 Sun/Oracle Certified Programmer
 4 years experience with C Sharp

4. Outline
 Introduction
 Domain Problem Breakdown
 Solution
 Detailed Discussion
 Demo!

5. Domain Problem
 Water Utility District (WUD) Spatial Viewer
 WUD program at TCEQ handles requests for data
about Water Utility Districts.
 Districts digitized off of old paper maps originally
or handed down in a semi secret ritual. :)
 Data was shared on a large file server and
individual copies were created by each analyst
that needed to edit, create or amend the data.
 New data was also manually reconciled when
discrepancies occurred between different
editors.

6. Domain Problem – cont.
 Water Utility District (WUD) Spatial Viewer
 Data requests required the team to extract out
the area of interest, manually.
 If the data type was an available export format, the
staff would manually translate the data into the new
format.
 This manual process wasn't speedy. Although it
satisfied the mandate of the team, it was not providing
the best return on investment for the effort. Not only
were the data updates and new data creation being
done in a silo, but only a manual process was available
for extracting the data.

7. Domain Problem – cont.
 Water Utility District (WUD) Spatial Viewer
 Just for fun – the spatial viewer needed to
integrate with a legacy web application that
displayed non spatial data in a typical/
traditional form view.

8. Outline
 Introduction
 Domain Problem Breakdown
 Solution
 Detailed Discussion
 Demo!

9. Solution
 Water Utility District (WUD) Spatial Viewer
 The solution consisted of a complete rework of
the entire business process for creating,
editing and warehousing of the WUD data.

10. Solution – cont.
 At the end of the process, to achieve success
we would do several things:
 #1- On the persistence tier, we would be
providing a centralized, versioned geodatabase
through which multiple clients, both desktop
and web based would be able to access the
most timely data possible.
 #2- At the business tier we would be
integrating the spatial viewer into the
traditional legacy web application through a
'loose-coupling' process.

11. Solution – cont.
 Success Benchmarks, continued
 #3 - At the presentation tier we would be
actually creating a set of self service processes
which would completely remove the need to
contact WUD team members except in cases of
errors or exceptional items.
 In conjunction with this final goal, the
application needed to:
 Print cartographic quality products
 Export data from one of four spatially defined
units and into one of three spatial formats

12. Outline
 Introduction
 Domain Problem Breakdown
 Solution
 Detailed Discussion
 Demo!

13. Detailed Discussion
 In the details…
 For the extract services we needed to provide
access to each of the different extract formats
for the self service data store.
 FME Desktop Workbench and Visualizer were
used to create the processes that were then
uploaded to FME Server 2009.

14. Detailed Discussion
 In the details…
• To create the extraction, we needed data for
spatial 'cookie-cutters'
• We chose several ‘base’ or core layers
• City, State and County boundaries Layers, preloaded
into ArcSDE and Oracle as our spatial for clipping the
WUD layers (4 different layers).

15. Detailed Discussion – cont.
 In the details…
 We also needed a fourth spatial layer - a
dynamic rectangle based on the extent of the
map 'window' in the map application.
 The presentation tier for this application was a
custom ajax-based ArcIMS application, using
javascript extensively. By using a proxy pattern, I
created a java application with a Java Servlet for
handling http requests. Then by capturing the user
requirements for their custom data extraction (city or
county, map view, etc. and download format) we
could post or get the results to the servlet.

16. Detailed Discussion – cont.
 In the details…
 A JSON Emitter module that would take the
extent values from the HTTP requests and
generate JSON that would be used as a data
source for FME Server for clipping the WUD
datasets.

17. Detailed Discussion – cont.

18. Detailed Discussion – cont.

19. Outline
 Introduction
 Domain Problem Breakdown
 Solution
 Detailed Discussion
 Demo!

20. Demo
 Demo
 WUD Spatial Viewer

21. Summary
 WUD Spatial Application was first deployed in
November of 2008
 Phase 2 which enabled the spatial ETL functions
with FME Server were deployed June 2009
 The number of calls to the WUD program has
decreased dramatically
 The data, now centralized has begun to be
integrated with other areas who need timely
access to WUD data
 All of the stakeholders have declared it a success!

22. Thank You!
 Questions?
 For more information:
 Brent Porter – brent@c4geo.com
 Texas Commission on Environmental Quality