1. GeoServer and Open Standards: A Success Story Saul Farber MassGIS, EEA

2. Let Me Tell You a Story... This presentation is a story about a state agency making a system for serving maps and data to everyone else in the state/world. Technical details are present, but not necessarily important. There are two takeaway points: Custom Software (non-COTS, non-FOSS) = BAD Open Standards = SAVED US MONEY, TIME and EFFORT

3. Overview Statewide GIS agency decides to build a statewide WMS/WFS service with a flexible web-based viewer First try is a custom front-end to ArcIMS with an excellent Java Web Start viewer First try is expensive and not scalable Second try is to use GeoServer and stick with the same viewer Second try is faster, cheaper and bugs are fixed quickly

4. What is MassGIS? Funded by the Legislature to assimilate, store and disseminate geographic data We set standards (e.g. Parcel Standard) so that certain kinds of data are collected correctly and compatibly We host and maintain over 300 layers of GIS data We act as a 'Technical GIS Advisor' to many other state agencies

5. Our Story Begins (1999) 1999 Mass.GOV (e-gov) initiative  1. Security 2. Customer Management (Identity) 3. Payment and...  4. “Mapping” MassGIS (just recently formed) is tasked with the implementation of #4

6. MassGIS Moves Forward (2001) MassGIS asks for an analysis – result is choice of WMS/WFS services on server side, and Java Web Start 'rich client' for client side  Statewide focus on Open Standards and Open Source continued throughout this project Goal is to develop a service which is usable by anyone, plus a client which allows viewing/download of MassGIS data Note how remarkable it is that the solution wasn't just “plain-old ArcIMS” (!)

7. MassGIS Builds a Service (2002-3) SERVER SIDE MassGIS contracts the development of a WMS and partial WFS server implementation named 'MapAccess' Technology:  largely J2EE wrappers around  ArcIMS XML calls, mixed with  direct-to-ArcSDE code when necessary Developer was Syncline Inc. (now defunct), which was heavily involved in the OGC specification development process

8. The Plan

9. MassGIS Builds a Service (Cont.) CLIENT SIDE The other half of the “GIS Shared Services” solution was an on line map viewer: OLIVER OLIVER is a 'reference implementation' of WMS/WFS client that other agencies/users could look at and learn from It also solved some data-distribution problems and was a very public and demonstrable success from the $$$ invested in this work Try showing the state CIO a WFS cap doc:  “But it validates against the W3C XML Schema! You don't understand how cool that is!”

10. What We Got: OLIVER Pretty much everyone loves OLIVER It's the public face of the project

11. Living with MapAccess (2003-2005) Not long after delivering the last of the MapAccess WMS/WFS components Syncline was no more Turns out MapAccess was brittle and slow Code was available to MassGIS, but not really fix-able. No 'community' who understood it Year-over-year maintenance costs for the underlying software were expensive Solution wasn't scalable -- monetarily or technologically

12. Problem Areas

13. We needed a cheap, fast and scalable WMS/WFS implementation It needed to provide complete backend support for OLIVER  Shapefile download by a feature in another layer, a visible extent, a arbitrary polygon  Click-to-identify  SDE-based vector and raster data BONUS: We now had J2EE experience on the team, so something we could work to fix/improve/extend would be good... How Do We Fix This? Requirements for a Replacement:

14. Our Most Important Requirement: We are a small agency with limited staff:  NO CUSTOM SOFTWARE! It's hard to over-emphasize this point. I'll say it a few more times

15. The Switch to GeoServer (2005) We pretty quickly found GeoServer OLIVER SUPPORT:  It took me about 4 hours to get a rudimentary port of OLIVER to GeoServer. Hey, it was already a WMS/WFS client...just syntactic changes to fix up SCALABLE/FAST:  It took a bit longer to find 'balance' and to set up balance, squid and GeoServer in a proof-of-concept scalable load-balancing model CHEAP:  GeoServer was open-source and based on J2EE!

16. Success: A Viable Long-Term Solution We already had an infrastructure based on ArcGIS desktop + ArcSDE server, so those were sunk costs “Hybrid” model – SDE Java API / Oracle DB Extra costs for GeoServer deployment:  $4000 for 3 dual-2.8Ghz Xeon machines with 1.5Gb RAM each. We built them ourselves  $0 for a retired desktop machine to act as load- balancer for the back-end machines  $0 for software--debian, balance, squid, GeoServer

17. Solution Using GeoServer

18. Unexpected Successes Our GIS shared services were only ever intended to be used by state agencies, so we only planned capacity to support the limited state agency usage  We have so much capacity with 3 GeoServer machines that the shared services are now 100% publicly available The great documentation and toolkits growing up around GeoServer and GeoTools provide us and our state-agency clients with a great development support network

19. #1 Best Part of GeoServer: The Community Every day, someone I don't know fixes a bug in GeoServer for MassGIS, for free Bug reports are publicly available, prioritized and are often quickly fixed Developers answer emails! Working with large corporate support staff can be frustrating Being a “part of the conversation” as well as a “part of the team” around GeoServer

20. Reflections on the Experience LESSON #1: NO CUSTOM SOFTWARE! Don't tie yourself to technology that requires things you don't have! Small office in state government = unique limitations  Old tech still needs to be supported for old projects  Money arrives in fits and starts  We don't have much developer time We didn't have money or expert developers...so why did we have ArcIMS running on custom software?

21. Reflections (Cont.) LESSON #2: Open standards from the start gave us significant advantages down the road  We're on a track with lots of others  We were able to change our problem-spots (server- side for us) without much change to our performing spots  All our investment in WMS/WFS based viewers wasn't wasted when we changed our server platform  There's not (really) an open-source ArcIMS!

22. Service Statistics We serve many many maps.

23. Nerdy Details How did we set up our clustering? How did we symbolize all that data? All you ever wanted to know about our GeoServer installation:  http://lyceum.massgis.state.ma.us/ http://lyceum.massgis.state.ma.us/