BioSIRT - A national system using Open GIS components Ian Miller

1. BioSIRT - A national system using Open GIS components Ian Miller

2. Biosecurity, Surveillance, Incident Response and Tracing “To enable national coordination of the management of information and resources in response to emergency incidents of animal or plant disease, pests or incursions” National decision makers need access to information accurately & quickly States/Territories were working to develop similar systems to meet similar requirements Issues with the existing national emergency animal disease management system

3. Features

4. Design Goals • Must operate in a stand-alone or fully integrated mode • Must utilise jurisdictional property and party data if available or work without it if not • Must integrate with all jurisdictional spatial infrastructures • Must fit in with jurisdictional Standard Operating Environments • Will be hosted and supported by each separate jurisdiction • Must support data aggregation within and between jurisdictions • Must have little or no per deployment licensing costs

5. Information Relationships

6. BioSIRT Mapping Screen

7. BioSIRT AOI Screen

8. BioSIRT Event Details Screen

9. Spatial Architecture

10. Open GIS and Open Source BioSIRT uses: • Mapserver as its Web Map Server • Geoserver as its Web Feature Server with transactional capability • Oracle XE RDBMS for it’s textual and spatial data storage • Extensively customised Moxi Media Internet Mapping Framework – Open Web Services (IMF-OWS) for the map interface Jurisdictions may use any OGC compliant servers which meet the functional requirements

11. Spatial RDBMS Issues Jurisdictions chose Oracle (including Express) over PostGIS/PostgreSQL Jurisdictions need to import/export spatial data to/from their own GIS systems which include ESRI, Geomedia, MapInfo and Oracle Locator Jurisdictions chose shapefile as the interchange format rather than GML for usability (3 years ago) Tools include Custom written Java utility, shapefile to Oracle Custom written import/export routines using GeoTools FME Other custom solutions Main problem/issue is efficient incremental update process

12. Spatial Servers Use MapServer for broad spatial data format support and superior symbology but need to compile for multiple platforms is costly Use GeoServer for WFS including Transactional - 3 years later, GeoServer may be sufficient for both Jurisdictions using IWS, ArcIMS, SLIP (WA), Google Maps Enterprise (NT) and The List (Tas) for context layers Attribute queries and updates all done via JDBC/SQL rather than WFS for performance and flexibility (Distinct, Sorting, Functions, PK management etc)

13. Mapping Interface IMF-OWS (commercial) used to build mapping because: 3 years ago, OpenLayers etc less mature Server-based rather than browser-based – enables far more flexibility and functionality (eg SQL) Enables more integrated solution as mapping and textual "state" maintained in a common environment IMF-OWS however lacks much of the modern web interface richness On balance, cost to benefit was right

14. OGC skills and tools All jurisdictional IT/GIS staff positive about use of open standards Only Tas (and to a lesser extent WA) had an existing open standards-based implementation WA best placed since GeoMedia also based on Oracle Locator Very few GIS staff involved had much OGC knowledge or experience Tool support in this area is generally poor (FME expensive for Oracle Locator)

15. Where to Next? • BioSIRT is in production with v2.0 about to be released • Most jurisdictions have a "basic" deployment of BioSIRT but in many cases a greater level of integration is to come • BioSIRT is now being used "in anger" in smaller incidents • Standards and technology are just one aspect of interoperability – skills, data structures and governance are also critical issues